It looks like OpenACC supports Fortran Type Bound Procedures. So I took that code and translated the directives to OpenMP Offloading directives and that code bombs out (memory error, using nvhpc 22.x). So does the current version of OpenMP support Fortran Type Bound Procedures? I would provide the code, but then my question seems unpostable.
Related
What is the difference between compile time and run time?
I am learning the differnce between static languages and dynamic languages. I read thatin statically typed
languages the type checking is performed at "Compile time",whereas in case of dynamically typed languages
type checking is performed at "Run time".What exacly is compile time?Does the code gets compiled as we write
the code in an IDE?or it is compiled after we are done writing code.
I m speaking in context of modern ide like vscode where we have the code runner extension to write code.
I have learned basic python and C language.I have observed that in C we have to mention the datatype while
writing the code but not in python.
While reading a PLSQL book I have stumbled upon this piece of code :
ALTER PROCEDURE pls_test COMPILE PLSQL_CODE_TYPE=INTERPRETED;
Could you please explain how it differs from normal compilation? I was not able to find the answer in the book.
Thank you!
Oracle supports two different compilation modes : INTERPRETED and NATIVE.
INTERPRETED is the default mode, that was introduced at the same time as stored PL/SQL (Oracle 7) :
... each PL/SQL program unit is compiled into an intermediate form, machine-readable code (MCode). The MCode is stored in the database dictionary and interpreted at run time
In the code you showed, the INTERPRETED part is redundant, as it corresponds to the default compilation mode (unless the command is executed against a server whose default was changed).
NATIVE was introduced in Oracle 9, then enhanced and simplified in the following versions :
SQL modules (packages, triggers, procedures, function, and types) .. are compiled... into native code residing in shared libraries. The procedures are translated into C code, then compiled with a C compiler and dynamically linked into the Oracle process.
This results in faster execution times, as no interpretation is needed at runtime : improvement factor was forecasted from 1.04 to 2.4 in Oracle 10g.
As a conclusion : unless you have a good reason, you want to use NATIVE over INTERPRETED...
For more details and a possible migration path, read this Oracle 10g FAQ paper and this post on Oracle blog.
Below description summarizes Native vs Interpreted Compilation. Interpreted Compilation is default compilation on Oracle DB. Natively compiled code does not need to be interpreted at runtime thus it executes faster.
Native compilation is the process by which a stored PL/SQL program is
compiled into native code (Pro *C) that does not need to be
interpreted at runtime. In comparison, code that is not natively
compiled is stored in an intermediate form that must be interpreted at
runtime.
PL/SQL native compilation provides the greatest performance gains for
computation-intensive procedural operations.
Reference : [1] [2]
I trying to write some game, based on Love2d framework, compiled from moonscript. Every time when I make a mistake in my code, my application throws error and this error refers to compiled lua-code, but not a moonscript, so I have no idea where exactly this error happens. Tell me please, what a solution in this situation? Thanks.
Moonscript does support source-mapping/error-rewriting, but it is only supported when running in the moon interpreter: https://moonscript.org/reference/command_line.html#error_rewriting
I think it could be enabled in another lua environment but I am not completely sure what would be involved.
It would definetely require moonscript to hold on to the source-map tables that are created during compilation, so you couldn't use moonc; instead use the moonscript module to just-in-time compile require'd modules:
main.lua
-- attempt to require moonscript,
-- for development
pcall(require, 'moonscript')
-- load the main file
require 'init'
init.moon
love.draw = ->
print "test"
with this code and moonscript properly installed you can just run the project using love . as normal. The require 'moonscript' call will change require to compile moonscript modules on-the-fly. The performance penalty is negligible and after all modules have been loaded there is no difference.
Debugging is a problem for pretty much any source-to-source compilation system. The target language has no idea that the original language exists, so it can only talk about things in terms of the target language. The more divergent the target and original languages are, the more difficult debugging will be.
This is a big part of the reason why C++ compilers don't compile to C anymore.
The only real way to deal with this is to become intimately familiar with how the Moonscript compiler generates Lua from your Moonscript code. Learn Lua and carefully read the output Lua, comparing it to the given Moonscript. That will make it easier for you to map the given Lua error and source code to the actual Moonscript code that created it.
My knowledge of interpreter based languages is that for every time we change the code we don't need to compile it. Compilation will be done at the time of actual execution only. Then why does most of the scripting languages use interpreter's when we usually write script to automate something which we usually doesn't modify.
All the answers seems to be unrelevant of what i was expecting. So let me phrase my question in this way.
Pure interpreter based language : which compiles and executes the code line by line, everytime we execute the code(as of my knowledge).
Then why does scripting languages were developed interpreter based(NOT combination of compiler and interpreter), when we usually execute the same script file everytime(without changing the source code). It would be better if they make it compiler based(or even combination of compiler and interpreter) so that we can compile it once and execute any number of times.
Do not confuse unrelated things together. Firstly, distinguish between a language and its implememntation. A language is given by its syntax + its semantics. A "computer" language (actually, a formally defined language) can be used to express things, such as algorithms, even if there is no known implementation of the invented and described language.
But in practice, the syntax specification is usually done by writing a parser (eg. using yacc) that can be understood by a machine, and semantics specification is done by writing code to be executed upon encoutering particular keywords and other semantic signs. In this way, a typical language creator performs the language specification by writing its first implementation, which then becomes an implicit standard for the language. People do it this way because it's simple, and because if you invent a language and merely publish it as a theoretical paper in a computer science journal, it is not guaranteed that anyone will bother to write its implementation for you.
This doesn't mean that the implementation provided by the language author is the only possible. If the language is well liked, people will attempt to write other implementations including compilers for it. This was eg. the case of Ruby, which was originally written by Yukihiro Matsumoto, but was liked well enough that people wrote a compiler of Ruby for JVM -- JRuby.
In a compiled language the program, once compiled, is expressed in the instructions of the target machine.
In a interpreted language the program instructions are not directly executed by the the target machine, but instead read and executed by some other program (in java its called the JVM). This enables interpreted language to be "Write Once Execute Anywhere".
I think your question is based on a false premise. Most scripting-language interpreters of which I am aware will do some amount of "compilation" to an internal form to avoid having to re-parse the source for repeated code (function-calls or loops).
The strings that represent identifiers will usually be interned so that the internal form uses integers that index a string table. Constants will be converted to the machine format. Labels and function-names will be stored (in the internal form) as pointers.
At some point (but the line is very blurry) if the internal form is specified precisely, it can be considered a byte-code format, and the interpreter is then considered a virtual machine. But it is still an interpreter. The microprocessor is still an interpreter for its machine language.
I am working on lock free structure with g++ compiler. It seems that with -o1 switch, g++ will change the execution order of my code. How can I forbid g++'s optimization on certain part of my code while maintain the optimization to other part? I know I can split it to two files and link them, but it looks ugly.
If you find that gcc changes the order of execution in your code, you should consider using a memory barrier. Just don't assume that volatile variables will protect you from that issue. They will only make sure that in a single thread, the behavior is what the language guarantees, and will always read variables from their memory location to account for changes "invisible" to the executing code. (e.g changes to a variable done by a signal handler).
GCC supports OpenMP since version 4.2. You can use it to create a memory barrier with a special #pragma directive.
A very good insight about locking free code is this PDF by Herb Sutter and Andrei Alexandrescu: C++ and the Perils of Double-Checked Locking
You can use a function attribute "__attribute__ ((optimize 0))" to set the optimization for a single function, or "#pragma GCC optimize" for a block of code. These are only for GCC 4.4, though, I think - check your GCC manual. If they aren't supported, separation of the source is your only option.
I would also say, though, that if your code fails with optimization turned on, it is most likely that your code is just wrong, especially as you're trying to do something that is fundamentally very difficult. The processor will potentially perform reordering on your code (within the limits of sequential consistency) so any re-ordering that you're getting with GCC could potentially occur anyway.