Intel shows Visual Studio multi-threaded way

Intel today released the long-awaited beta version of its Parallel Studio development tools, available as a free download. This set of plug-ins to Microsoft's Visual Studio integrated development environment (IDE) promises to help ease developers into the now-standard world of multi-threaded applications running on multi-core …

[Anonymous Coward]

FAQ too

"Pricing will be announced in early 2009"

Would that not have been worth mentioning prominently in the article?

And a couple I couldn't see asked or answered in the FAQ:

Is it 64bit capable?

Does it work on the IA64 (ie Itanium) edition of Studio?

Does it work with genuine AMD64 processors too or is it restricted to their Intel clones?

[Anonymous Coward]

This will make multithread problems worse

It's going to encourage those who can't multithread into thinking they can (and should, because everyone else is & that's what the market wants etc.), and the tools that help you track down problems will just find the obvious bugs and let the subtle ones slip through.

I'm sure the tools are great -- if used properly...

[jim]

if the price is right

If this product carries a typical $500 price tag, it will sink without a trace. If Intel wants to drive multi-core processor sales - and these plugins actually help - they should be free.

[Anonymous Coward]

Any C# versions available?

As the title says.

[Jared Vanderbilt]

Delphi 4 anyone?

I tried Intel's Thread Building Blocks kit many months ago and returned to Delphi because the overhead was too extreme. I like most Delphi developers have been using TThread's since the mid '90s to build WORKING multi-threaded applications. And yes, they scale across quad processors under WinXP.

Paris - she comes pre-threaded.

[Anonymous Coward]

@Jared Vanderbilt / TThread

IIRC TThread are just handy wrappers around the win32 API thread facilities, which I recommend you have a look at in the raw.

I like delphi but it's always worth knowing what's under the hood and how to get down & dirty in a pinch.

[Anonymous Coward]

Does the compiler output separate defective code for AMD CPU's?

http://www.betanews.com/article/Suit_Intel_Sabotaged_Compiler_for_AMD/1121274628

According to the FAQ, only x86 is supported for non-Intel CPU's. No X86_64, ARM or MIPS. I think I will stick with the Gnu tool chain.

[Dr Patrick J R Harkin]

Not for me

It takes all my concentration to write code for one processor.

[Anonymous Coward]

But what about the bugs!?

New libraries for parallel development are great, if it means we can all use threads easier, otherwise what is the point of all those cores? It still means more bugs.. not everything get picked up by race condition checkers in these tools - so we'll be running to Visual Studio's debugger, and finding it's really quite hard to debug threads.

There are some tools you can use to help, one is a plugin to VS2008 from Allinea - who normally are known for massive parallel debugging of Linux clusters - there's a write up about it here:

http://terboven.spaces.live.com/blog/cns!EA3D3C756483FECB!440.entry

but without that kind of help, you're on your own when there's a bug!

[Jolyon Smith]

Delphi's TThread

Was and Is great but also sucked some serious butt in many respects. The lack of any provided mechanisms for simple messaging between threads was one, the lack of a provided pooling mechanism or any flexibility in thread lifetime management, the fact that the app main thread wasn't actually represented by a TThread was another. etc.

Fortunately Delphi being what it is, and with full source provided, the VCL TThread class itself proved invaluable to me in gaining an understanding of the Windows thread related API's and gave me a great jumping off point to create my own far richer and more flexible threading support for my Delphi code, taking all the great things that TThread did and adding SOOO much more.

And yes, making hard jobs easier for those who don't fully understand the problems they are grappling with is a fundamental pillar on which the Law of Unintended Consequences rests.

Writing parallel code is easy.

Writing parallel code that works is not.

Unless of course you employ a (correct) implementation of the Active Object pattern, in which case massively parallel code can be written by pretty much anyone.