Slashdot Mirror
Inside Intel's $20M Multicore Research Program
An anonymous reader writes "You may have heard about Intel's and Microsoft's efforts to finally get multi-core programming into gear so that there actually will be a developer who can program all those fancy new multicore processors, which may have dozens of core on one chip within a few years. TG Daily has an interesting article about the project, written by one of the researchers. It looks like there is a lot of excitement around the opportunity to create a new generation of development tools. Let's hope that we will soon see software that can exploit those 16+core babies. 'The problem of multi-core programming is staring at us right now. I am not sure what Intel's and Microsoft's expectations are, but it is quite possible that they are in fact looking at fundamental results from the academic centers to leverage their large work force to polish and realize the ideas that come forth. It calls for a much closer collaboration between the centers and the companies than it appears at first sight.'"
You mean something like parallel_sort in libstdc++, since GCC 4.3.0?
One of several parallelised standard algorithms.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
The NT kernel has supported SMP for 10 years. So what?
It's all about the applications. Sure, there's some development tools in *nix for multicore. I doubt they are efficient and accessible though. Can y'all tell me how great GCC is with 16 cores and thread level parallelism? I'm sure some academic and or low level solutions exist everywhere. However, it's undoubtedly a PITA whatever platform you work with. Everyone could use better tools for the future. Especially for making desktop apps.
mpeg4 decompression is far more complex than voice recognition. The processing involved is simply not that great, even for "more advanced voice and language recognition". The difficulty lies in better algorithms to do it. Turns out dynamic voice control and interpretation is not something that can be brute forced.
Game physics needs computational power. but I'm not considering game systems.
Scientific and Engineering projects need computational power and benefit from cost reduction in high performance processing.
The home user differs. I suspect dual core cpus is just a way for Intel to sell us twice as many cpus as we really need.
“Common sense is not so common.” — Voltaire
Intel's been doing that (to some degree) since the Pentium, and they increased it a lot in the Pentium Pro/Pentium II. It works reasonably well up to a point (modern chips typically execute an average of two instructions per clock cycle) but definitely has limits.
Compilers to automatically detect when instructions can be executed in parallel have been around for years. Cray had vectorizing compilers by the late 1970's, and within rather specific limits, they worked perfectly well. Just for example, if you wrote a loop like:
they'd break the loop down into four actual executions of a loop, each of which worked on 64 items in parallel. It had independent execution units, so at a given time it'd normally be loading one set of 64 items into one set of registers, executing multiplications on a second set of 64 items, and storing results from a third set of 64 registers.
That has a couple of problems though. First of all, if you're not careful, it's pretty easy to create loops with (apparent) dependencies from one iteration to the next, so the compiler can't parallelize the code. Second, this works well for vector processors, but probably not nearly so well for a large number of completely independent processors (which have higher communication overhead, meaning that starting up things to happen in parallel is more expensive).
If you're willing to provide the compiler with a little help, it can do quite a bit more, such as with MPI. The standard MPI interface is pretty low-level, but if you want to do the job in C++, Boost.MPI helps out quite a bit (cheap plug: if you want to know more, consider attending Boostcon '08).
The universe is a figment of its own imagination.
Outlook I can understand. It needs to flush the emails to disk before replying back to the server.
However, there's no reason why the web browser needs to ensure that the data hits the disk cache right away, so it should be just fine sitting in RAM until the disk frees up. Similarly, intellij, maven, and ant should be slow the first time but faster later on since they should be reading from the page cache.
There's no reason for your disk I/O light to be on unless you don't have enough RAM or the disk algorithm in windows blows chunks.
I do linux kernel development, and once I do an initial pass through the source tree the whole thing generally stays in RAM and I rarely have to hit the disk. I have 3GB of RAM, but this isn't excessive nowadays.
Actually the drag increases as the square of velocity: F = Cd.A.1/2.rho.V^2