Maybe Intel et. al. should develp better RAD and compiler tools that assist modularising code ready for multi-threads and compiler that can evaluate serial code and generates optimised multi-thread code.

Ding, ding, ding. We have a winner, folks.

Assembly might be making a comeback.

With the exception of games and HPC what mainstream computing program class needs more than 4 cores?

Use RapidMind API? Supports lots of multi-core CPUs, ATI/Nvidia GPUs, and Cell processors.

Here's the official list of supported hardware/software.

Hardware
* AMD, Intel Multi-core x86 CPUs
* NVIDIA GeForce 6000, 7000 or 8000 series cards
* NVIDIA Quadro card with Shader Model 3.0 support (e.g. Quadro FX5500)
* AMD FireStream 9170
* ATI x1X00, 2x00 and HD Radeon 3870 families of cards
* IBM QS20 Blade server with Cell BE processor with Cell SDK 2.0/2.1
* Cell BE on Sony PlayStation 3 using Yellow Dog Linux with Cell SDK 2.0
* Cell BE simulator found in Cell SDK 2.0/2.1

OSs
* Mac OS X 10.5
* Windows XP Pro, Vista, Server 2003
* Red Hat Enterprise Linux 5
* Fedora Core 6, 7, 8 Linux
* Ubuntu 7.04, 7.10
* Yellow Dog Linux 5 on Sony PlayStation 3

Compilers
* MS Visual C++ 7 or 8 under Windows
* GCC 4 under Linux
* Xcode under Mac OS X

Official site
http://www.rapidmind.net

Developer site
https://developer.rapidmind.net/

You need to contact their sales dept to get access the the "Developer Edition". (which is free to use for "Research purposes").

Intel has MULTIPLE compilers for multicore systems. Apple, Microsoft and Intel all have multiple dev tools for multicore programming. It's a function of time and money -- not everyone has the time to get the kind of necessary benefit out of it.

Which is why game console engine developers are going to be in higher demand for other computing soon: they already have built an engine that works on different systems with multiple cores.

I think it's great what Intel is suggesting. But it won't be an easy transition. Look at the Cell processor for the PS3. Game developers are having a difficult time writing code for it because it's 7 cores. We're so used to writing in sequential. I'd like to think that our best is to create a new programming language that can assign or divide instructions or task per core and/or cycle. But that's a lot of work and I'm not sure if it's great as a long-term solution. But what do we do in the meanwhile for the next 3 or 4 years? Create computational intelligent algorithm!! But don't ask me what it means. I just loving making concepts. *l* In all seriousness, I think we need to move away from our current state of mind and start working on a parallel algorithm.

These hardware guys need to read about amdahl's law I think.

i sort of see this differently i guess. i see it more as:

"it doesn't matter how many cores you program for because down the road we'll have 10's, 100's even 1000's of cores. so if you think you and every other parallel-software that might be running on the chip is going to eat up the all resources, you won't"

two obvious places to look would be procedural data generation for static elements (reduces disk access)
also (and i've mentioned it before) pulling 3d graphics processing back on cpu due to the insane number of cores

So what happened to these things Intel and AMD were talking about years ago which would automatically multi-thread single-threaded applications in hardware on the fly?

But once we get hyperthreading back with quad-cores, then executing 8 threads at once is a a real possibility.

Not exactly. Remember that SMT doesn't provide additional execution units.

Developers to Intel: "for reals?"

I'm not sure about other fields but in the area I work in - data mining - adapting to manycore designs is certainly not that big a problem; very often the same operations are performed on a large number of informational units and that's easy to parallelize. What we'll have to be smart about will be task ordering in order to minimize waiting for theads to complete...

Developers to Intel: We're having a lot of trouble with 2 and 4 cores.

"Maybe Intel et. al. should develp better RAD and compiler tools that assist modularising code ready for multi-threads and compiler that can evaluate serial code and generates optimised multi-thread code."

Many times it's not just compilers/etc 'detecting' areas of paralell instructions, but that you need a COMPLETELY different algorithm to make something multithreaded. Which is how you get Intel saying:

"...writing code for many-core CPUs takes a little more effort than updating software to take advantage of a couple of extra cores"

Programmers have to change the way they 'think', not just recognize for loop patterns/etc.

Although, not to say better compilers/RAD tools won't help a ton.

Ghuloum wants it, he does *cough*Ghuluom, Ghuluom*cough*

At least "Intel to Developers" is better than "Microsoft to Developers".
http://www.youtube.com/watch?v=KMU0tzLwhbE

Funny, I just posted in another thread about how it's important to be polite. But I feel no remorse about being rude to people who blather on topics about which they know nothing, and it's only forum rules that prevent me from being harsher.

Oh the irony!

I also wonder if this person has been banned from this forum before.

So, because Intel had to add multiple cores they say it's the developers restricting performance gains. It was Intel in the first place that promoted crazy sinlge threaded performance bu found adding transistors and increasing clockspeed wasn't feasible compared to adding cores (ie. P4 failure).
Some software spends more time waiting for user input so it's pointless to multi-thread.
Maybe Intel and Microsoft should reduce the load of context switching and thread scheduling.
Maybe Intel et. al. should develp better RAD and compiler tools that assist modularising code ready for multi-threads and compiler that can evaluate serial code and generates optimised multi-thread code. Intel compiler for SPEC CPU benchmarks already does this at a basic level.

This seems to contradict the earlier statement about how CUDA is going to be too hard for programers to program in compaired to the X86 that they already know.

Sounds like Intel is saying we have hit the limit on single core speed.

Having so many threads can only go so far as the locking algo can permit. Not all applications scale well with many cores. And it is always not possible to write applications that keep scaling as more cores are shoved into the box.

I heard a talk during the spring from a designer in one of Intel's research labs; he basically said that Intel is going to be shipping scalable-core chips within 10 years (possibly less) and nobody's going to know how to use them, but the people who figure it out are gonna be hella rich.

The problem is most people are probably not taught coding for multiple cores. Sure they could probably learn but until the education base is there it will be hard to push things like this into general applications.