Linked by Thom Holwerda on Thu 18th Aug 2005 16:46 UTC, submitted by Nicholas Blachford
Intel "At next week's Intel developer forum, the firm is due to announce a next generation x86 processor core. The current speculation is this new core is going too be based on one of the existing Pentium M cores. I think it's going to be something completely different."
Thread beginning with comment 20058
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Multi-threading hard?
by nimble on Fri 19th Aug 2005 16:17 UTC in reply to "Multi-threading hard?"
Member since:

Really the question I have to ask is, is writing your code to use large amounts of threads really that hard?

Well, it's usually quite a bit harder than the equivalent sequential version. Thread communication, the danger of deadlocks and more complex program state during debugging make it more difficult.

And of course there's the vexed question of how and into how many threads you should actually partition your application.

Too few and you might not fully utilise any given machine; too many and communication overhead overtakes gains in throughput.

So unless you're writing software for a particular machine with a fixed number of cores and known communication overhead, you end up having to guess.

I'm currently writing a video editing program in which I plan to use three seperate threads just for playback. One thread each for OpenGL displaying, decompression and disk reading. It's not that hard really

While that's very commendable it won't actually gain you much performance, because the decompression is the only CPU-intensive task there. OpenGL is handled by the GPU (unless you're using software emulation of course) while hard-disk reading is handled by the DMA controller.

The one way you could gain performance is by somehow splitting up and multi-threading the decompression algorithm, but only if it's actually the bottleneck in the system.

Reply Parent Score: 2