OSNews: http://www.osnews.com/story/18323/Intel_Open_Sources_Multicore_Programming_Tool Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Wed, 25 Nov 2009 09:11:29 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com nice http://osnews.com/thread?258093 http://osnews.com/thread?258093 intel just keeps making the right moves in my book. keep it up intel. open threaded aplications are teh future, lets get there together. Wed, 25 Jul 2007 14:21:00 GMT donotreply@osnews.com (poundsmack) Comments Intel compiler http://osnews.com/thread?258107 http://osnews.com/thread?258107 What would it mean for GNU/GPL3 if intel also released their compiler as open source under GPL2? gcc is the biggest hurdle to anyone not using the gnu tools. Wed, 25 Jul 2007 14:58:00 GMT donotreply@osnews.com (sappyvcv) Comments RE: nice http://osnews.com/thread?258130 http://osnews.com/thread?258130 Pervasive multithreading is a must if we are going to see significant performance improvements. And it's something very important for Intel to get it common because Intel is focusing on producing multicore chips obviously.

It's a wise move for Intel to help everyone to start writing multithreaded code. Wed, 25 Jul 2007 16:33:00 GMT donotreply@osnews.com (Radek) Comments RE: Intel compiler http://osnews.com/thread?258132 http://osnews.com/thread?258132 I'm not sure what you mean.

Intel currently sells their compiler for $$$. It's not a bad compiler. I'm not sure it would be to their advantage to open source.

Their compiler is optimized for their cpus and the x86 market isn't just a one horse race, although generally amd cpus also get a boost from the intel compiler.

From a cross platform/cross system standpoint gcc is still the best compiler out there, supporting generally well many different architectures and OS's.

One thing REALLY annoying about this library is that there's plenty of access to a bunch of marketing fluff, but you have to go through the mess of downloading the code in order to look at any examples. I'd like to see some hard core simple examples of how to use their stuff. Their marketing material almost implies that the library itself goes through the trouble of implementing yet another scheduler in addition to the one the OS already has.Edited 2007-07-25 16:39 UTC Wed, 25 Jul 2007 16:35:00 GMT donotreply@osnews.com (bnolsen) Comments Bravo Intel http://osnews.com/thread?258133 http://osnews.com/thread?258133 This is a great move on Intel's part. Clearly multicore processors are the way forward, and it's in Intel interest that software performs well on such systems (after all, benchmarks showing their latest and greatest processor not being any faster than a 3 year-old Pentium 4 aren't what they want). Happily, everyone else gets to benefit to.

What I do wonder though it where this fits in with other C++ parallel schemes. A lot of work has been done in this area by the Boost people, and I recall reading that "easy" thread-level parallelism was one of the major goals of the next C++ standard (though as ever, "easy" and the C++ standards committee are not words that sit well near one another!). And then there's OpenMP as well. It's all a bit confusing... Wed, 25 Jul 2007 16:43:00 GMT donotreply@osnews.com (tristan) Comments And don't forget http://osnews.com/thread?258141 http://osnews.com/thread?258141 Mirko's ThreadWeaver library, based on Qt4. It's also task-based and makes pervasive multithreading incredibly easy. I use it everywhere in Krita. Wed, 25 Jul 2007 17:13:00 GMT donotreply@osnews.com (boudewijn) Comments I'd perfer to see vtune http://osnews.com/thread?258151 http://osnews.com/thread?258151 Personally, I'd perfer to see Intel release their vtune code profiler for free to help developers write code that will run faster (see interview with Con Kolivas where he complains about hardware getting faster, but software getting slower). Amd already make their Code Analyst available for free... Wed, 25 Jul 2007 17:59:00 GMT donotreply@osnews.com (MikeW) Comments RE: Intel compiler http://osnews.com/thread?258161 http://osnews.com/thread?258161 First, you're OT.
Second unless GCC doesn't really matter for GPLv3, as it isn't usually redistributed, only binaries created by GCC are (usually) distributed.

As an aside, I've checked and TBB is compatible with GCC. Wed, 25 Jul 2007 18:56:00 GMT donotreply@osnews.com (renox) Comments RE: And don't forget http://osnews.com/thread?258163 http://osnews.com/thread?258163 If I understand correctly TBB also provides a STL-like library which is multi-threading "friendly/compatible", whereas ThreadWeaver is just a "threaded batch scheduler".

So they're not really the same thing..Edited 2007-07-25 19:11 Wed, 25 Jul 2007 19:10:00 GMT donotreply@osnews.com (renox) Comments RE: Intel compiler http://osnews.com/thread?258169 http://osnews.com/thread?258169 Intel will probably never release their compiler as free and/or open source software simply because they couldn't even if they wanted to. As with several other compilers (e.g. Comeau, Portland Group, etc.), the front-end is licensed from the Edison Design Group. I don't believe that it would be possible (in a reasonable time frame) to rewrite the backend to use an open-source front-end.

More info:
http://www.edg.com/
http://support.intel.com/support/performancetools/c/windows/sb/CS-0... Wed, 25 Jul 2007 20:06:00 GMT donotreply@osnews.com (Detlef Niehof) Comments RE[2]: Intel compiler http://osnews.com/thread?258196 http://osnews.com/thread?258196 Their marketing material almost implies that the library itself goes through the trouble of implementing yet another scheduler in addition to the one the OS already has.

Ohhh, another M:N threading model. When are they going to learn that userspace thread scheduling just doesn't perform very well? Why can't they just split the process into threads and let the kernel schedule them? Wed, 25 Jul 2007 23:09:00 GMT donotreply@osnews.com (butters) Comments RE[3]: Intel compiler http://osnews.com/thread?258230 http://osnews.com/thread?258230
Ohhh, another M:N threading model. When are they going to learn that userspace thread scheduling just doesn't perform very well? Why can't they just split the process into threads and let the kernel schedule them?


How so? M:N threading is complex to implement, but when done right, it can out perform the competition. Take Tru64 for instance, which uses M:N threading.

Its one of those things in the IT world, great on paper, a real bitch to implement in real life, but when done well, does perform well. Thu, 26 Jul 2007 02:17:00 GMT donotreply@osnews.com (kaiwai) Comments At confrence / party http://osnews.com/thread?258250 http://osnews.com/thread?258250 I was at the release party Monday where James Reinders announced the release (and I scored a complementary copy of his book as an attendee). I was going to write an article but the draft showed I had too long a day and too many cocktails.

First off about license Mr. Reinders addressed the subject of forking and stated that Intel had no objections and that the code base should run its course naturally. Second it is encouraged to port to different OS/CPU architectures (but I assume a bias toward Intel CPUs).

The code examples where impressive, from my notes: The original demonstration ray tracer single threaded was 182 lines, Pthreads version added 143 lines and TBB added 17 lines. There was a brief reference to Lamda functions but he never came out and said that TBB is a FUNCTIOAL language addition, I guess it was too obvious given the audience.

I spoke with one of the other Intel engineers after the conference and he confirmed that the library is a set of functional programming templates combined with an actual back ground library that allocates threads across cores implicitly optimizing at run time.

I hope I understood what I said (I know, it is some heavy stuff) But that is what I can report as an attendee of the release party.Edited 2007-07-26 04:14 Thu, 26 Jul 2007 04:13:00 GMT donotreply@osnews.com (ojh77) Comments