Slashdot Mirror
Intel Reveals the Future of the CPU-GPU War
Arun Demeure writes "Beyond3D has once again obtained new information on Intel's plans to compete against NVIDIA and AMD's graphics processors, in what the Chief Architect of the project presents as a 'battle for control of the computing platform.' He describes a new computing architecture based on the many-core paradigm with super-wide execution units, and the reasoning behind some of the design choices. Looks like computer scientists and software programmers everywhere will have to adapt to these new concepts, as there will be no silver bullet to achieve high efficiency on new and exotic architectures."
Maybe they will ditch the shiatty 950 graphics chip, that is all too common in notebook computers
I'm just waiting till they come out with a complete single chip PC (I know there are examples but they aren't spectacularly performing). Just enough PCB for some external connectors and some voltage regulation.
I don't know what it is, or how it will be different from x86, but progress can't keep continuing if we don't look for better methods of doing things.
It cannot be argued that x86 is best architecture ever made, we all know it's not... but it is the one with the most research. We need the top companies in the industry, Intel, AMD, MS, etc. to sit down and design an entirely new specification going forward.
New processor architecture, a new form factor, a new power supply, etc...
Google has demonstrated that a single voltage PSU is more efficient, and completely do able. There is little reason that we still use internal cards to add functionality to our systems, couldn't these be more like cartridges so you don't need to open the case?
Why not do away with most of the legacy technology in one swoop and update the entire industry to a new standard.
PS, I know why, money, too much investment in the old to be worth creating the new. But I can dream can't I?
Sometimes the best solution is to stop wasting time looking for an easy solution.
So when Intel decides that it's time to implement new architectures and force new methods of coding it's an awesome thing, but when Sony does it people tell them to stop trying to be different... I know people will cry about the console market being different, but the principals of the decisions are the same. If people cried about the Cell I expect them to cry about Intel's new direction. And this had to be said... I have Karma to burn.
FanFictionRecs.net
Basically put in dozens of slow low IPC, but area-efficient, processors per CPU. Later on, throw in some MMX/VLIW style instructions to optimize certain classes of algorthims.
The first Niagara CPUs were terrible at floating point math, so they were only good for web-servers. The next generation I hear are supposed to be better at FPU ops.
Actually... Looking at Haskell, and clean in the debian language shootout, both are beating C# in terms of memory usage, and CPU usage.
I thought Sony's processor design was awesome, and I still do.
tasks(723) drafts(105) languages(484) examples(29106)
Speaking as someone who wrote reports on the Cell as early as 2004, it was mostly the people who thought Sony was the devil himself who hyped it up.
Easiest way to make sure a product doesn't meet expectations is to raise expectations.
FanFictionRecs.net
How about google search? That a big enough exmpe for you? It's written using a functional library called Map reduce.
Tim Sweeny of Epic has a pdf floating around. Basically a game can be divided into 3 groups. Shading (using shader language), numeric computations (functional) and then game state/logic. He quoted 500 Gflops for shading, 5 gflops for numerics, and 0.5 for game state/logic. Shading is a solved problem as far as concurrency is concerned. THe numeric computation uses the most cpu, that is mostly small numerical jobs for things like checking collisions and can be parallelized and done functionally. The game static/logic and scripting were said to be best done in c++/scripting. That is the part you won't really thread but you could use STM if needed.
----
Go canucks, habs, and sens!
In the mean time, you were given a nice example -- ATC systems and telephone exchanges, and in the mean time, you can have a research paper about map reduce -- if you don't belive me, belive the peer reviewed research.
Of course Google's programmers can write cool parallel programs with this powerful library, but it's not a functional programming library! It's a C++ library that borrows some map and reduce ideas from functional languages.
I'd rephrase the objection to the OP as: "Show me the climate simulator in Haskell. Show me the ML hypersonic flow code for computing reentry flow over the shuttle."
Yes...I am a rocket scientist.
What makes you think a compiler will be able to do it better than a human?
When people write games, they do all kinds of crazy stunts to ensure they have as few multiplications as possible. Can you really trust a compiler to get the code right for that tight inner loop? Figuring out parallelism might be hard, but game programming has always been hard.
Also, you avoided mentioning memory. It doesn't matter if Haskell uses marginally less memory if it's in the wrong place when you need it. Is that texture in RAM, VRAM, or swap? That sort of thing makes a big difference in terms of performance. And games must maintain a certain framerate. Sometimes it's completely unacceptable to use swap, even if the time gets made up later.
I'm not against functional languages, it's just a question of using the right tool for the job. You use high level languages for high level tasks, and low level languages for low level tasks. If you're writing a compiler or an AI or a raytracer, where realtime performance it not an issue, sure, functional languages are great. But games have always been married to the hardware, and I don't see how that could change any time soon.
Craft Beer Programming T-shirts
Functional programming makes multithreading easy, but multithreading != vectorization, and vectorization is the bulk of what is needed to take advantage of this type of processsor. I'm yet to encounter a language as suited to talking about vector code as Fortran is, sad as that may be.