GCC can vectorize loops automatically when certain options are specified and given the right conditions. Are there other compilers widely available that can do the same?
ICC
llvm can also do it and vector pascal too and one that is not free VectorC. These are just some I remember.
Also PGI's compilers.
The Mono project, the Open Source alternative to Microsoft's Silverlight project, has added objects that use SIMD instructions. While not a compiler, the Mono CLR is the first managed code system to generate vector operations natively.
IBM's xlc can auto-vectorize C and C++ to some extent as well.
Actually, in many cases GCC used to be quite worse than ICC for automatic code vectorization, I don't know if it recently improved enough, but I doubt it.
VectorC can do this too. You can also specify all target CPU so that it takes advantage of different instruction sets (e.g. MMX, SIMD, SIMD2,...)
Visual C++ (I'm using VS2005) can be forced to use SSE instructions. It seems not to be as good as Intel's compiler, but if someone already uses VC++, there's no reason not to turn this option on.
Go to project's properties, Configuration properties, C/C++, Code Generation: Enable Enhanced Instruction Set. Set "Streaming SIMD Instructios" or "Streaming SIMD Instructios 2". You will have to set floating point model to fast. Some other options will have to be changed too, but compiler will tell you about that.
Even though this is an old thread, I though I'd add to this list - Visual Studio 11 will also have auto vectorisation.
Related
I get about 3-4x times difference in computation time of a same CUDA kernel compiled on two different machines. Both versions run on a same machine and GPU device. The direct conclusion explaining the difference is different compiler settings. Although there is no single perfect setting and the tuning should be customized depending on the kernel, I wonder if there is any clear guideline for helping to choose the right settings. I use Visual Studio 2010. Thank you.
Compile in release mode, not debug mode, if you want fastest performance. The -G switch passed to the nvcc compiler will usually have a negative effect on GPU code performance.
It's generally recommended to select the right architecture for the GPU you are compiling for. For example, if you have a cc 2.1 capability GPU, make sure that setting (sm_21, in GPU code settings) is being passed to the compiler. There are some counter examples to this (e.g. compiling for cc 2.0 seems to run faster, etc.) but as a general recommendation, it is best.
Use the latest version of CUDA (compiler). This is especially important when using GPU libraries (CUFFT, CUBLAS, etc.) (yes, this is not really a compiler setting)
Following link, I'm wondering if there're some side effects of enabling C++0x in GCC.
According to gcc: "GCC's support for C++0x is experimental".
What I'm afraid of is that for example compiler will generate some code differently or standard library uses some C++0x feature which is broken in gcc.
So if I don't explicitly use any of C++0x features, may it break my existing code?
The C++0x support has been, and is under heavy development. One thing this means is that bugs get fixed quickly, another thing it means is that there might be small bugs present. I say small, because of two reasons:
libstdc++ has not been rewritten from scratch, so all the old elements are just as stable as it was before any of this c++0x was available, if not more stable, because of several years of bug fixes.
There's corner cases in the new/old Standard that haven't yet been ironed out. Are these the runtime quirks you talk about? No. C++0x support has been under development for 4 releases now, don't worry.
Most of the impact from that flag will be felt in the new language features, the library features like move constructors and std::thread (on posix platforms) don't affect code not using them.
Bottom line, experimental is too strict a word in daily production. The standard has changed in the three/four years GCC has been working on support. Old revisions of c++0x will be broken in a newer GCC, but that's a good thing. C++0x is finished as far as the non-paying-for-a-pdf-world is concerned, so no breaking changes should be added. Decide if you want the new stuff or not beforehand, because you won't be able to jsut switch it off once you've gotten used to using it.
Usually, it won't break your source code, but you may include (even without noticing it or knowing it) C++0x idioms that will compile because of these features enabled, but won't compile in a strict C++ compiler (for instance, in C++0x you can use >> as a template of template terminator, but not in C++, so if you forget to separate it by a space, you will have problems when you try to compile this code in a C++ compiler).
R-Value references/moves is a feature which can have a huge impact on how the compiler does optimizations and such. Even if you don't use move in your own code, the STD includes will automatically switch to their new versions which include move ctors/assignment.
There are some circumstances which allow the compiler to create move constructors/assignment operators implicitly for user defined classes. These rules changed a few times during the standardization process (I don't even know what the current rules are). So, depending on the exact version of your compiler it could be using a set of rules for generating these implicit functions that isn't even in the latest version of the standard.
Most of the other major C++0x changes don't have big run-time impact, they are mostly compile time (constexpr, string literals, varadic templates) or syntax helpers (foreach, auto, initializer lists).
I originally wrote the question you link because of (in my opinion) a very big issue as described here. Basically, overloading a function with shared_ptr to a const type was not recognized by the compiler. That's a huge flaw in my opinion. It's been fixed from GCC 4.5 to GCC 4.6, but it serves as an example of a big bug that's still around in the default installation of GCC in ubuntu, for example. So while bugs are fixed quickly, there still might be bugs, and you may waste a weekend looking for the source and solution of those bugs.
My recommendation, based on this personal experience, is to avoid C++0x until the word "experimental" is removed from the description of GCC's support of C++0x or until you actually need any of the C++0x features to a degree that an alternative implementation would significantly sacrifice good design.
A VS solution consisting of C# and C++ projects built with VS2005 outperforms the same solution converted to VS2008 (release mode). I already double checked the optimization settings for the known bug where the settings are not converted correctly.
While the difference in performance is not big it is still notable. Any ideas what the reason could be for the difference in performance?
Thanks in advance for any replies!
Can’t answer completely without knowing what the code is and what switches are being sent to the compiler.
C# performance shouldn't have changed just by recompiling with a different version of VS. If you have both on the same machine, they'll use the same version of the .NET Framework to execute.
As far as C++ goes, the compiler changes between VS versions so perf won’t always be the same. It’s very possible they made a change to the optimizer that happens to perform worse on your code but better for most others. They could also have adjusted their compiler's instruction scheduler to account for a more modern "average" CPU. VS2008 also brought in a lot of C++ compliance fixes – there might be one that reduced the room the compiler has to optimize.
Unfortunately, my C app for PIC32 needs OO too much and I can't continue doing it in C.
Do you know any MIPS32 C++ compiler for PIC32?
Thanks
Microchip's XC32 tool chain now supports C++ since version 1.10
You might contact Comeau Computing; thier C++ compiler generates C code as an intermediate language so that it can then utilise a platform's existing native C compiler where only a C compiler is available, and therefore porting to new platforms is relatively quick and simple.
For various reasons the intermediate generation and compiler adaptation is not accessible to end users so you will still need Comeau to generate a PIC32/C32 port, but it probably won't take long and hopefully they would amortise the cost over sales to other users.
However if you use Commeau or any other C++ to C translator, you will suffer from the inability to use source-level debugging, and that is likley to be the killer to any attempt to use C++ sucessfully without native debugger support.
Although it is not always pretty, your best bet is probably to learn how to implement OO designs in C. Here's a whole book on the subject: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
According to this fairly recent thread on the microchip forums it looks like C++ support for PIC32 isn't available anywhere yet and isn't a high priority with Microchip. The wisdom of the respondents in that thread appears to be: don't hold your breath.
I'm a MPLAB user myself building small programs so I just take what Microchip gives me. I've never gotten to the point where I thought I needed C++, longed for yes, but never needed. As a next step you can either consider moving to another platform with C++ support or take another look at your design and ask why you need C++ that badly. Some features can be simulated in C with varying amounts of pain and suffering.
You might keep an eye on the proper GCC MIPS port. They have all the pieces, but I don't know if anyone's made C++ work with PIC32 in particular. I know it did work on sgimips.
I'm pretty sure this is possible but I'm not sure how to go about it. I'm very new to building with GCC in general and I have never used FreeRTOS, but I'd like to try getting the OS up and running on a TI ARM Cortex MCU but with a slight twist: I'd like to get it up and running with Pascal. I'm curious:
Is this even possible to get work? If not, the next issues are kind of moot points.
From my Delphi days, I vaguely recall the ability to access functions in C libraries. I'm wondering if I would have access to the C routines in FreeRTOS.
If I use the GCC version (preferable) would I be able to debug using OpenOCD on the target? I'm not quite sure how debug symbols work and if it's more or less language agnostic (hopefully, in this case).
As kind of a bonus question a bit outside the scope of the original query, can I simulate FreeRTOS on an x86 processor (e.g. my development PC) for easier debugging during development? (With a Pascal program, of course..)
I haven't found any documentation on achieving this, so hopefully someone here can shed some light! Any resources would be most helpful. Like I said, I'm very new to this kind of development. I'm also open to suggestions if you think there is a better alternative.
FYI, my preferred host configuration would be something similar to:
Linux (Ubuntu/Debian)
Eclipse IDE for development, unit testing, and hopefully simulation / debugging
OpenOCD for target debugging
GNU Pascal + FreeRTOS on target
FreeRTOS is C source code, so like you say you would have to have some mechanism for linking C with your Pascal programs. Also, FreeRTOS relies on certain registers to be used for things like passing a parameter into a task (as a hypothetical example, the task might always expect the parameter to be in register R0) so you would have to ensure the ABI for the C compiler and the Pascal compiler was the same - or have your task entry in C then have it call a Pascal function (very nasty). Then there is the issue of interrupts, calling inline macros, etc. I would say this would be extremely difficult to achieve.
Both GNU Pascal and Free Pascal support linking to C (gcc) and ARM, as well as calling pascal code from C etc. Writing a header and declaring the prototypes with cdecl is all there is to it.
Macros are a bit bigger problem. Usually I just rewrite them to inline functions (what they should have been anyway). Except for the macro/header issue, the problems are more compiler specific functionality (which you also would have a problem with when porting from one C compiler to the next)
If you prefer TP/Delphi dialect, Free Pascal is the better choice.
I run my old Delphi code fine on my sheevaplug.
There is already an example for FreeRTOS/GCC/OpenOCD on a TI Cortex-M3 (was Luminary Micro Cortex-M3). Be aware though that this is a really old example and both the Eclipse and OpenOCD versions used are out of date.
Although there is an Eclipse project provided, the project is configured as a standard make (as opposed to a managed make) project, so there is a standard makefile that can be just as easily executed from the command line as from within Eclipse.
http://www.freertos.org/portLM3Sxxxx_Eclipse.html