- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All,
Our application and build environment is rather large and it would be significant effort to get it to build under VS 2005 but we're looking to test specific aspects of ICC before we undertake the ultimate "apples V apples" test. Should we just choose some smaller components and just test those - for example, we have hash table lookup object that we know is responsible for significant CPU?
I know that the question is rather loaded...but I'm just wondering what experience people have had. For a typical CPU bound application that is built with GCC on windows, what would you expect the performance increase that ICC could give you?
Any thoughts or other suggestions before we attempt a full comparison?
Regards,
Blue.
Our application and build environment is rather large and it would be significant effort to get it to build under VS 2005 but we're looking to test specific aspects of ICC before we undertake the ultimate "apples V apples" test. Should we just choose some smaller components and just test those - for example, we have hash table lookup object that we know is responsible for significant CPU?
I know that the question is rather loaded...but I'm just wondering what experience people have had. For a typical CPU bound application that is built with GCC on windows, what would you expect the performance increase that ICC could give you?
Any thoughts or other suggestions before we attempt a full comparison?
Regards,
Blue.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's hardly an apples v apples test when you use an old version of gcc with no vectorization or OpenMP support. A newer version of gcc could give you significant vectorization, if that is relevant to your application. I haven't seen satisfactory OpenMP or auto-parallel threading with gcc on Windows. If those aren't relevant to your application, the performance opportunities may not be so large. If you have used only mingw, you may not have profiled your applications to get an idea where improvement may be needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply. Two of the reasons for looking at ICC are vectorization and the support for OpenMP - although this is a more longer term view.
In an ideal world we'd like to see some generic performance increases just by using ICC with comparable settings to mingw. For example, we know that some of the basic math functions and memory functions (such as memcpy) perform poorly in mingw.
In an ideal world we'd like to see some generic performance increases just by using ICC with comparable settings to mingw. For example, we know that some of the basic math functions and memory functions (such as memcpy) perform poorly in mingw.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have a read through this article on the Choice of Compilers. The difference depends on hardware, but compared to ICC on x86/x86-64 (including AMD chips), the performance of all other compilers tested, commercial or otherwise, is downright embarrasing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mingw uses basic Microsoft supplied math functions. ICL, with SSE options, would replace most of those with IA-optimized versions. gcc in-lined memcpy is supposed to perform fairly well on the latest Intel CPUs; the intel specific memcpy supplied by ICL is most advantageous for strings of hundreds of bytes.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page