I noticed that openmp can work with both posix-thread and win32-thread variants of mingw-64.
I would like to use posix-thread version with openmp in mingw. However, in the wiki page of Qt the following notice is written:
posix (built upon MinGW-w64’s winpthreads): Performance degradation in specific scenarios. C++11 functionality is significantly slower than native Win32 implementation or even MSVS2012’s implementation (http://qt-project.org/wiki/MinGW-64-bit)
My question is: Do the same performance problems exist with openmp implementation with winpthreads? Would it be better if chose win32threads in mingw to work with openmp?
Related
Well, I am going to do some deep learning stuff with opencv.
I have already installed scikit-image and scikit-learn.
No, but you could install some C++ compiler on MacOSX.
Visual C++ is a C++ compiler and IDE for Windows (don't confuse it with Visual Studio Code, which is a cross-platform IDE). You need some compiler for MacOSX, which is a Unix variant and nearly POSIX (it could be certified to some specific POSIX standard, but I don't know which).
Probably, both GCC and Clang are available on MacOSX (see this). You need to find some packaged version of them, perhaps with brew; both compilers work really well. Apple is partly funding Clang. GCC is funded by many other corporations. They both are open source compilers, but with a different license (GCC is mostly GPLv3+). GCC is probably producing some faster code (when optimizing, faster by a few percents only). Clang is probably giving better diagnostics. I actually recommend installing both of them (and using occasionally both of them too).
Take care to install recent versions of GCC & Clang. Both are very active projects, and are progressing quite well.
You probably need to install other things too. E.g. a build automation tool (like GNU make), a version control system (like git), a source code editor (like emacs or vim).
You might even install some fancy IDE like Clion, Code::Blocks, XCode, etc.. I recommend avoiding that, because you need to learn how to compile on the command line. These fancy tools are running the command line compiler under the hoods, and you really need to understand what they are doing (and hiding from you). Actually C and C++ are somehow not IDE friendly (you really need to understand what the compiler is doing). In both C11 specification (n1570) and in C++11 specification (n3337) the notion of translation unit and of preprocessing is important (and sadly, IDEs tend to hide these notions).
As remarked in comments, you could install the XCode package (which pulls useful packages like GCC or Clang, etc...), but avoid using the XCode IDE.
What are the (architectural) differences in implementing a programming language on the GraalVM architecture – in particular between Graal, Truffle, and LLVM using Sulong?
I plan to reimplement an existing statically typed programming language on the GraalVM architecture, so that I can use it from Java without much of a hassle.
There are at moment three options:
Emit JVM bytecode
Write a Truffle interpreter
Emit LLVM bitcode, use Sulong to run it on GraalVM
Emitting JVM bytecode is the traditional option. You will have to work at the bytecode level, and you'll have to optimise your code your before emitting bytecode as the options that the JVM has for optimising it after it has been emitted are limited. To get good performance you may have to use invokedynamic.
Using Truffle is I'd say the easy option. You only have to write an AST interpreter and then code generation is all done for you. It's also the high performance option - in all languages where there is a Truffle version and a bytecode version, the Truffle version confidently outperforms the bytecode version as well as being simpler due to no bytecode generation stage.
Emitting LLVM bitcode and running on Sulong is an option, but it's not one I would recommend unless you have other constraints that lead you towards that option. Again you have to do that bitcode generation yourself, and you'll have to optimise yourself before emitting the bitcode as optimisations are limited after the bitcode is set.
Ruby is good for comparing these options - because there is a version that emits JVM bytecode (JRuby), a version using Truffle (TruffleRuby) and a version that emits LLVM bitcode (Rubinius, but it doesn't then run that bitcode on Sulong). I'd say that TruffleRuby is both faster and simpler in implementation than Rubinius or JRuby. (I work on TruffleRuby.)
I wouldn't worry about the fact that your language is statically typed. Truffle can work with static types, and it can use profiling specialisation to detect more fine-grained types again at runtime than are expressed statically.
I know these technologies are all related but could someone please explain what each one is used for and how they fit together?
Oversimplification:
Graal - Java bytecode compiler. Can be used just in time (as part of a JVM) or ahead of time.
SubstrateVM - other things (runtime) needed to actually run ahead-of-time compiled Java bytecode without a JVM. This powers the "native-image" command of GraalVM.
Truffle - framework for implementing languages as AST interpreters which can be just-in-time compiled using graal. Some notable languages implemented are JavaScript, Ruby, R and LLVM bitcode.
GraalVM - most of these technologies packaged together in order to support different use cases, for example: running JVM programs (i.e. anything that compiles to Java bytecode) using Graal as the JIT compiler for better peak performance, ahead-of-time compiling JVM programs for fast startup and low memory footprint, running fast dynamic languages (JS, R, Ruby) that can interoperate without overhead, and so on.
I am having some trouble understanding my current situation due to the fact that I spend most of my time coding x86 software.
Apple have released a new requirement that apps must support 64 bit architecture from february 2015. From what I understand I can make a 'fat' binary with 32 bit and 64 bit code inside it.
The part that I am confused about is the fact that my project uses OpenMP and inline neon assembler code (hand tuned math libraries), this compiles fine on 32 bit ARM and runs perfectly.
I need some advice on how to get my project ready for Apples new requirement.
How can I enable OpenMP for GCC 4.9.2? There is not even a omp.h in the folder
Is the neon instruction set supported?
My SDK (Marmalade) says it supports armv8-a and simd, what does that say in terms of supporting neon?
How much of my inline arm assembly do I need to edit? I have LOTS of it and I am kind of panicking right now.
I hope someone can help me.
Links:
https://gcc.gnu.org/gcc-4.9/changes.html
http://docs.madewithmarmalade.com/display/MD750/Release+Notes#ReleaseNotes-7.5BetaReleaseNotes
I was wondering if there is any AOT compilation options for the mono for android platform (or anything planned?).
I am asking this because I will port a game using mono for android, and performance is really important, this is why I wanted to know if AOT compilation is available (or any other compilation option that can produce better performances)
I know that Monotouch uses AOT compilation, and that it can optionally use llvm as compiler in order to make some optimisations. So, I am wondering if the same options are available in mono for android.
Thanks in advance
AOT is not available in Mono for Android, I don't think it is on the road-map either.
As far as I understand JIT is not slower than AOT, rather the contrary, because JIT can use the information it knows about the environment it runs on to optimize code to it. An AOT compiler cannot know everything about the same environment.
This thread: Why is Java faster when using a JIT vs. compiling to machine code? has some answers that elaborates on this.
So I really doubt that you would get any performance improvements if there were an AOT compiler.