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."

Comments

Great!

[Short Circuit]

As I recall, AMD's Athlon beat out the competing Intel processor in per-clock performance, partially as a result of having a more superscalar architecture. It's nice to see that, with the NetBurst architecture dead, Intel's finally taking an approach that's expandable and extensible.

The CPU wars have finally gotten interesting again. I'm going to go grab some popcorn.

Re:Great!

[JordanL]

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.

Re:Great!

[nuzak]

Intel doesn't go around telling us that their design will push 17 hojillion gigazoxels, with more computing power than Deep Blue, HAL, and I AM put together, in order to render better-than-real detail in realtime while simultaneouslly giving you a handjob and ordering flowers for your gf.

Re:Great!

[Short Circuit]

I thought Sony's processor design was awesome, and I still do.

Re:Great!

[JordanL]

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.

Re:Great!

[strstrep]

It's a good design, it just doesn't seem like a good design for a video game system. It's a general purpose CPU attached to several CPUs that essentially are DSPs. DSP programming is very weird, and you need to at least understand how the device works on the instruction level for optimal performance. A lot of DSP code is still written in assembly (or at the very least hand-optimized after compilation).

It's very expensive to have DSP code written, when compared to normal CPU code, and video game manufacturers have been complaining that the cost of making a game is too high. Also, most of the complexity in a video game nowadays is handled by the GPU, not the CPU. Now the cell would be great for lots of parallel signal processing, or some other similar task, and I bet it could be used to create a great video game, it would just be prohibitively expensive.

The cell is a great solution to a problem. However, that problem isn't video games. A fast traditional CPU, possibly with multiple cores, attached to a massively pipelined GPU would probably work better for video games.

Re:Great!

[Thomas the Doubter]

I'm not so good with acronyms - what is the difference between a DSP/SPU and a GPU? Why would programming against a GPU be any (much?) easier than programming against a DSP (SPU)?

Re:Great!

[jmorris42]

> So when Intel decides that it's time to implement new architectures and force new methods of coding it's an awesome thing, ....

Except when it ain't. Lemme see, entire new programming model..... haven't we heard this song before? Something about HP & Intel going down on the Itanic? Ok, Intel survived the experience but HP is pretty much out of the processor game and barely hanging in otherwise.

Yes it would be great if we could finally escape the legacy baggage of x86, but it ain't going to happen anytime soon. The pain isn't there yet that would convince people to migrate.

Re:Great!

[InvalidError]

The Cell would have been nice were it not for the surprisingly slow DMA read problem.

Since Sony announced the oddity last June (verbatim: "~16MB/s (no, this is not a typo)"), I presume it means all PS3 Cell CPUs past and present will carry it on... or at the very least, game developers will not be allowed to use the extra bandwidth should DMA reads be fixed to maintain compatibility with first-gen PS3s.

Re:Great!

[Wesley Felter]

The point of the presentation was that Intel's proposal is not that different from today's x86; it's a cache-coherent SMP. Really the only new feature is 16-wide SIMD rather than 4-wide in SSE today, so you just unroll your inner loops four times as much. But Cell is totally different from traditional architectures because the SPUs have no caches.

Re:Great!

[heinousjay]

Oh, bullshit. Stop acting persecuted because the chip you like was developed by a corporation who can't get good PR when people hand it to them. A martyr complex isn't witty or persuasive, it just rallies the people who already agree in the first place. It's also excessively irritating to read.

Re:Great!

[rbanffy]

It's not easier.

The Cell advantage lies in having one and only one kind of SPU (or über DSP) in the architecture instead of the myriad of different GPUs on the market.

That's an advantage Both Intel and AMD will try to get by making the GPU instruction set a standard much like the 80486 incorporated the 80387 instruction set in a single standard.

Re:Great!

[strstrep]

You typically write code that runs on the main CPU. This program supplies the GPU with data such as vertices, triangles, textures, etc.. For special effects, you can write shader programs for the GPU that modify how the GPU renders specific things. However, most of the code that's running on the GPU is already written for you... at the transistor level.

All a DSP does is do lots of arithmetic operations and memory moves quickly. For example, in a single instruction, the DSP could run an addition and shift operation, move some data from memory to registers, and move some data from registers to memory. Also, DSPs (and the SPU in the cell) tend to perform (relatively) terribly when they run into a conditional statement. Thus, the type of programs that you end up writing for DSPs don't just need special attention when programming; you have to write a whole different kind of program for them than you're used to.

Re:Great!

[Bodrius]

Did 'people' really cry about the Cell that much?

I think some programmers have suggested that perhaps, as a possibility, changing the programming model to something far more difficult to exploit was not the smartest choice in a competitive console market.

But I don't think anyone really 'cried' about it. They just chose not to invest on it, yet.

Even the skeptics seemed to think Cell was pretty cool by itself (me included).

What people 'cried about' was the price tag, the misleading trailers / screenshots, the lack of game titles, lackluster online experience, and the sheer arrogance of the company throughout the process (i.e.: anyone should be eager to work overtime to buy our revolutionary new luxury console).

Personally, I was skeptical of the Cell on the PS3, but hopeful for a myriad of other Cell applications.

But none of the things I saw people crying about (and none of the reasons I won't buy a PS3) have anything to do with the Cell. They all seem to be things Sony could have avoided / handled very differently.

Re:Great!

[Anonymous Coward]

You mean ken kutaragi?

Re:Great!

[trimbo]

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.

No one's crying about Sony trying to be different. It's far worse for them than that: no one is willing to spend $600 on their pet project. Intel, on the other hand, will probably make things cheaper by merging these on the desktop.

Re:Great!

[amorsen]

The Cell would have been nice were it not for the surprisingly slow DMA read problem.

I still don't see why it's a problem. Let the SPU do a DMA write and fetch the data when they're written. PCI is pretty much the same; you want the hard drive controller to do DMA write instead of the CPU fetching across the bus.

Re:Great!

[Yev000]

Sony? I think you mean jointly developed by a Sony, Toshiba, and IBM, an alliance known as "STI." Sony bashing is just that, Sony bashing.

Re:Great!

[Fred_A]

I know people will cry about the console market being different, but the principals of the decisions are the same.

No, it's quite different, the console market is indeed different since it's more like high school. In the PC market we don't have principals, we have managers.

Re:Great!

[rbanffy]

One of the reasons there are 8 über DSPs in Cell is that it allows programmers to write sloppy code for them.

If it would run real fast with hand-optimized or machine code and one SPU it sure can run very well with 8 SPUs and a decent optimizing compiler.

Re:Great!

[squizzar]

Surely two things should happen: Someone somewhere should write a highly capable graphics library, capable of supporting the vast majority of requirements for 3D games. Maybe several depending on application. Licenses should be a reasonable price (with the intention of nearly everyone using it). Secondly, games manufacturers, since they do not have to worry as much about the graphics coding anymore, will be able to focus on making, y'know, good games? I was expecting this to happen with the cell. Someone provides a library or a few highly extensible game engines (look at how the Quake engines have been used), and licenses them, with source, as a high performance building block for games. Could even have a form of open source model, requiring producers to return any performance enhancing modifications to the engine back to the community, and allowing them to keep their own game code secret (don't ask how this could be done, I don't know). It would encourage a rapid development pace whilst allowing games to be judged on their playability as opposed to technical superiority.

Re:Great!

[faragon]

I was skeptic about the Cell chip, but after some homebrewed tests (explicit unrolling, some SPU handmade optimizations, etc.), I have to admit that, despite that both PPE and SPEs have to be programmed with its limitations in mind to avoid in-order CPU with pipeline stalls with a heavy branch penalties -not trivial if you want to get top performance-, it is still a *monster*, a *true* supercomputer on a chip (the PS2's "Emotion Engine" was similar in concept but much limited for interprocess communication). As example, on a given SPU, you can order DMA transfers while working in parallel (working like explicit prefetch or automatic DMA), and that is true for the other SPU's. Such grade of paralelism and throughput is overkill.

P.S. I complain Sony's decission of hiding the graphics chip from the Linux environment: too bad! (Cell + GPGPU == state of the art computing luxury!)

Re:Great!

[GoatMonkey2112]

Itanic. That's all I have to say about that.

Re:Great!

[Anonymous Coward]

The other major problem with The Cell was the J-LO component. I don't quite know why producers are so keen on adding a J-LO to virtually everything, as the results are inevitably flat. Very popular perhaps, but bland and unimaginative.

Re:Great!

[dumb_jedi]

I don't agree. Yes, DSP code should be very optimized, but you can do it in any language as long the compiler knows how to optimize that. Or IBM can simply create a library of OpenGL functions to the Cell, everything written in assembly with wrappers to higher level languages. You only have to do it once. Or You can simply create a library of OpenGL functions to the Cell, everything written in assembly with wrappers to higher level languages and sell it.
Game engines are quite complex, but most of the work in a game is done my artists amd modellers, not programmers. Games with HUGE environments, real looking trees/facilities/rocks/whatever take time to be created. And game engines can and should be licensed, so companies can concentrate on what they do best, be that game engines or the content.

Re:Great!

[init100]

I'm in faggo-Euroland and these two flamers come up to me with their faggot accents talking about

Fred Phelps, is that you?

Re:Great!

[coolGuyZak]

Note: I have not developed on the Cell Processor, my knowledge is, at this point, theoretical.

I think that the best use of the Cell in the PS3 is not for outbound image & physics processing (as it was hyped), because that support is already provided by the on-board graphics and physics chips. IMHO, the best uses for the SPUs are for inbound image processing and outbound sound processing (albeit that may be best for the physics card as well. I'm not too familiar with its capabilities).

My reasoning for this stems from my understanding of present stream processing in sound cards, which operate using a similar DSP model. I imagine that you could design an algorithm that computes volume as a factor of distance, then send sound and distance data through the SPEs. With so many of them available, and a properly designed algorithm, you may be able to actually reproduce the "cocktail party" effect... taking immersion in multiplayer games to the next level. (Think a MMORPG that doesn't require text chat). You could also use the SPEs to create voice masks, allowing (say) a female playing a male character to actually sound male (or vice versa).

On the inbound image processing aspects, you could use the SPEs to "pre-parse" the image. Essentially, create an algorithm that generates an image with "candidate object" outlines, then use the general purpose CPU to identify which "candidate objects" are useful and/or real. (This boils down to using the SPEs to reduce the search space).

These ideas are somewhat half-baked and likely hard to implement. However, if the PS3 is to take off, this is where I see it going.

Re:Great!

[Anonymous Coward]

Is it really clear that the "In Order" processors won't be full fledged (albeit slow) x86 instruction processors? I read this article as saying: "Look, we're spending a lot of silicon and power trying to sniff out parallelism and predicting branches, which also wastes cache hits. How about simplifying the core, make it cooler and smaller and fit in lots of them?" If that's the case, it's a lot easier for software developers, as they can use the same compilers (with different optimizers perhaps) and just need to start threading more.

I'm a Quant Developer on Wall Street, and we do lots of computation on server farms, and constantly want more power. But spending a lot of effort writing special codes for an array processor doesn't really pay. The models will last at least 1.5 to 4 years, which will clearly make the current hardware obsolete.

So, I'm hoping Intel will let me keep writing code as I do now, just with more threads.

Re:Great!

[Dun Malg]

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. Oh please. The "Sony=Satan" crowd is hardly well organized enough, nor forward thinking enough, nor fervently interested enough in disliking Sony to have ever sat down and said "hey guys, let's pretend to be Sony loving faggots and over-hype the Cell so when the PS3 comes out everyone will be disappointed when it isn't as good as we said". Seriously, you're way into conspiracy theory territory there. The hype came from where hype always does for any product: the hyper-loyal sycophants.

yay

[Anonymous Coward]

Maybe they will ditch the shiatty 950 graphics chip, that is all too common in notebook computers

Re:yay

[phalse phace]

But not everyone needs to have a GeForce Go 7900 or whatever GPU in their notebooks. The GMA 950 is perfectly suitable for those who just use their notebooks to browse the web, send emails, etc.

Re:yay

[Joe The Dragon]

But not for vista users why can't intel have a on board video chip with it's own ram?

Re:yay

[ewhac]

The 945/950 GMCH is common in notebooks because it's easy to implement (Intel's already done almost all the work for you), it's fairly low-power and, most important of all, it's cheap.

Schwab

Re:yay

[Anonymous Coward]

Funny, I wouldn't consider a mobo without because Intel are working towards an open source driver. I'm sick of binary drivers and unfathomable nvidia error messages. At least Nvidia expend some effort, ATI are a complete joke. Even on windows ATI palm you off with some sub-standard media player and some ridiculous .NET application that runs in the taskbar (What fucking planet are those morons on?)

So you can bash intel graphics all you like but for F/OSS users they could end up as the only game in town. We're not usually playing the latest first person shooters, performance only need be "good enough".

Re:yay

[negative3]

Exactly my thought - I have never had problems with any of the laptops with Intel graphics chipsets and Linux. In fact, Fedora pretty much kicks ass with the GMA950 on my Macbook as opposed to my desktop with an ATI card that has 2 DVI outputs (can never get both outputs to work at the same time in Fedora, but I freely admint I am probably screwing up the video configuration).

Re:yay

[Ajehals]

ahem, mail me your X configuration and I'll sort it for you if you want (or have a damn good go) - what you describe has become something of a regular occurrence in my part of the world, my email is shown but replace the domain with gmail.com as I'm out and about at the moment.

As for intel graphics on notebooks, I agree, there is nothing like having a component in a notebook where you don't have to worry about it being some bizarre non standard randomly hacked (or firmware crippled), especially when you are talking about the graphics card.

Re:yay

[Anonymous Coward]

But not for vista users why can't intel have a on board video chip with it's own ram?

GMA 950 works great for Mac OS X, though. Vista sucks.

Re:yay

[Anonymous Coward]

Onboard 950 works just fine with Beryl/Compiz. And Mac OSX. Looks to me like Microsoft's doing something wrong.

Re:yay

[CCFreak2K]

Well, the Intel i965G is one Intel GPU not targeted for the budget/low power market, if that's what you mean.

Re:yay

[jumperboy]

Actually, these are exactly the people who will most benefit from improvements in graphics subsystems (and displays). Sure, we can sit back and be amazed by the awesome rendering in the latest shoot-em-up or the crisp detail in an HD-DVD or Blue-ray movie, but it's readers whose needs aren't even close to being met by today's technology. Just take a look at the crappy fonts you're viewing right now on your monitor, and realize that we are probably decades away from anything remotely resembling print. Let's see, 1985: 640x480, 2007: 1280x1084. Yep, sounds about right.

Re:yay

[Anonymous Coward]

Actually, these are exactly the people who will most benefit from improvements in graphics subsystems (and displays).

It's mostly the problem of displays (and cheap OEMs).

Re:yay

[Chandon Seldon]

This isn't a graphics processor issue - even the crappiest embedded graphics cards that show up in mainstream consumer PCs can easily handle modes like 1600x1200. That's been true for years now.

The problem is twofold: Display technology, and user acceptance of crappy displays. This has just been made worse by the transition to LCD displays - that probably set us back 4 years on screen resolution gains by itself.

Re:yay

[Fred_A]

Funny, I wouldn't consider a mobo without because Intel are working towards an open source driver. I'm sick of binary drivers and unfathomable nvidia error messages.

Um, frankly I've never had any problems in all the years I've used them and over 3 cards (or maybe 4) with nVidia drivers (before that I had a lot of Matrox with the open source drivers). The very first time I had a little trouble installing them because the process required quite a bit of tinkering, reading stuff compiling and poking at stuff but nothing a little RTFM didn't solve. And it always worked flawlessly. Now the process has been fairly polished, mostly thanks to the distro packagers and/or the add-on packagers when the distro themselves stuck to the open source stuff.

I know one example doesn't make a rule but most of the people I've found with nVidia problems have done odd things to their configuration or were very new to the system. All in all, and considering the closed source restrictions they're stuck with (which I'm the first to admit we certainly could do without, but life isn't perfect) they're doing a pretty good job.

Regarding ATI, I've always had very mixed reports so I never bought stuff from them, even when it was a better deal, only because of the Linux issues.

Of course, at the end of the day, there isn't currently much point in having an über graphics card in one's workstation. There still haven't been many games published for Linux, Beryl (or Compiz, or whatever it's being called now) doesn't require that much muscle to run happily. And there still aren't that many real OpenGL apps either. The only real drive remains (as always) games.

Re:yay

[timeOday]

I can't even get 3d acceleration for my IBM T40 anymore because ATI dropped support for the chip from their radeon driver last year. It stinks.

Re:yay

[default luser]

"Target" and "Reality" are two different things.

The "Target" of the G965 is to raise performance above anything available today.

The "Reality" of the situation is: the drivers are terrible. Vertex shading is still done in-software, just like the G950. As-of March (six months after release), there are still no updates available, and the rumored "beta" drivers are still just that - a rumor.

The Reality of the situation is the X3000 gets trounced in mnay games by the 2-year old GeForce 6150, and to get respectable (> 20fps) framerates in recent games you have to pair it up with a beefy Core 2 Duo.

Sure there is

[Watson Ladd]

Abandon C and Fortran. Functional programing makes multithreading easy and programs can be written for parallel execution with ease. And as an added benefit, goodbye buffer overflows and double frees!

Re:Sure there is

[Anonymous Coward]

Hello memory hogging garbage collection and poor implementations of simple functions, C#

Re:Sure there is

[alphamugwump]

Good luck writing that game of yours in Haskell. For that matter, good luck writing a game in anything other than C/C++.

Re:Sure there is

[QuantumG]

Cool, with that kind of benefit, I'm sure you can point to some significant applications that have been written in a functional language which have been written for parallel execution.

This kind of pisses me off. People who are functional programming ethusists are always telling other people that they should be using functional languages but they never write anything significant in these languages.

Re:Sure there is

[Anonymous Coward]

And hello bloat!

Re:Sure there is

[bhtooefr]

There's quite a few games written in Python.

Anyway, you seriously expect someone to click on a TINYURL link in a Slashdot sig?

Re:Sure there is

[ewhac]

Cool! Show me an example of how to write a spinning OpenGL sphere with procedurally-generated textures and reacts interactively to keyboard/mouse input in Haskell, and I'll take a serious whack at making a go of it.

Extra credit if you can do transaction-level device control over USB.

Schwab

Re:Sure there is

[beelsebob]

Actually... Looking at Haskell, and clean in the debian language shootout, both are beating C# in terms of memory usage, and CPU usage.

Re:Sure there is

[beelsebob]

Okay then, I'll go write it with the Haskell OpenGL and OpenAL libraries, and I'll sit here smug in the knowledge that while it may run a little slower now, when these CPUs come along, it'll run 30 or 40 times faster than your C impementation.

Re:Sure there is

[Anonymous Coward]

LOL it's always funny to see you functional programming guys get all worked up each time around you see some hope that maybe now, this time there's a reason functional programming will catch on.

Sorry to say, it won't catch on this time either. The world's programmers have voted. You lost.

Now to hang out with the Amiga fan-boys, former Lisp-machine users, and bemoan your loss.

HTH.

Re:Sure there is

[beelsebob]

How about google search? That a big enough exmpe for you? It's written using a functional library called Map reduce.

Re:Sure there is

[CopaceticOpus]

Ah, so functional programming is the silver bullet! I knew we'd find it sooner or later.

Re:Sure there is

[QuantumG]

Proprietary software doesn't count.. why? Cause no-one can see the benefits of using a functional language except the priveleged few who have access to the source code. So.. can you please name a large open source program written in a functional language which benefits from this supposed ease of parrallelisation that is being claimed here. Or are we just supposed to take your word for it?

Re:Sure there is

[beelsebob]

How about perl 6's compiler -- pugs is written entirely in Haskell.

Re:Sure there is

[DragonWriter]

Cool, with that kind of benefit, I'm sure you can point to some significant applications that have been written in a functional language which have been written for parallel execution.

Would the telephone switching systems that Erlang was made for the express purpose of implementing count, or the air traffic control systems also implemented with it, or would it have to be something more of a significant application than that?

If games are more your thing, how about this.

This kind of pisses me off. People who are functional programming ethusists are always telling other people that they should be using functional languages but they never write anything significant in these languages.

Please share your definition of "significant".

Re:Sure there is

[Goalie_Ca]

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.

Re:Sure there is

[Anonymous Coward]

If you want to be serious, take a look at this C++/OCaml raytracer comparison and a random benchmark.

Functional languages will let us utilize multiple cores without the headaches and performance is acceptable, to claim otherwise is plain short-sighted. Programmers are not going to be doing manual memory management or thread handling in application level code.

Re:Sure there is

[QuantumG]

and the second part of my question? Is this multithreaded? Where's the benefits being claimed?

Re:Sure there is

[alphamugwump]

Not any serious games that push as many polygons as possible. A demanding game must get at the raw hardware, and you don't really want to do that with a scripting language. Sure, you can compile python, but good humans will still beat compilers, especially on exotic hardware.

When you're writing a game engine, you want to manage your own memory. For many games, calls to malloc and free are too expensive. You want to be able to shuffle game data around. You want to be able to use inline assembly, for floating point stuff. You want to be able to take a pointer and run it across a goddam buffer. You want actual for loops, not a for each.

Sure, python is pretty good for web programming. And it works OK for small, 2D games, too. But it's not like people avoid functional languages out of ignorance. Imperative programming is still popular for a reason.

Re:Sure there is

[Pseudonym]

Proprietary software doesn't count.. why? Cause no-one can see the benefits of using a functional language except the priveleged few who have access to the source code.

And just how many open source applications that rely on parallelisation (and we won't count any kind of parallelisation where there's mostly no coordination required between threads/processes, such as Apache) have been written recently?

Re:Sure there is

[beelsebob]

Can you show me any open source project where massive parallelism is being exploited? I'm not sure I can think of any.

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.

Re:Sure there is

[QuantumG]

No, dude, he's asking you to solve real problems using your functional language which you claim to be so much better at solving real problems. And, as usual, the response from the functional programming crowd is to point at supposed case studies that no-one can verify or to point at contrived benchmarks.

Re:Sure there is

[beelsebob]

Okay then... First you write a simple function that generates the points on the sphere, based on a stream of positions of the pokes, then you write a function that generates the textures, then you use the Open GL libraries to generate the output... Then you sit back and glot, because on these chips, that's gonna run a whole lot faster than your C code.

Re:Sure there is

[Bill Barth]

If you read the paper you linked to below, you'll find that Google's Mapreduce language is implemented as a C++ library. Specifically, check out Appendix A of thier paper.

Re:Sure there is

[beelsebob]

Actually, no... That's exactly the point here. These chips are so comlex to think about that a human can't possibly juggle it all in their head. A good human will *never* be as good as a compiler for these chips, and good functional languge compiler for these chips will almost always be better than a good procedural language compiler.

Re:Sure there is

[beelsebob]

Yes, indeed you will -- if you read up on any functional language you'll always discover that they re eventually based on procedural processes -- after all, our microprocessors are all procedural engines. The library itself is functional, and that, as the paper points out is where they get the speed -- not in the impementation detail that the library is written procedurally.

Re:Sure there is

[AstrumPreliator]

I couldn't find anything related to procedurally-generated textures, not that I really looked. I could find a few games written in Haskell though. I mean they're not as advanced as a spinning sphere or anything like that...

Frag which was done for an undergrad dissertation using yampa and haskell to make an FPS.
Haskell Doom which is pretty obvious.
A few more examples.

I dunno if that satisfies your requirements or not. Though I don't quite get how this is relevant to the GP's post. This seems like more of a gripe with Haskell than anything. But if I've missed something, please elaborate.

Re:Sure there is

[ewhac]

Functional languages will let us utilize multiple cores without the headaches and performance is acceptable, to claim otherwise is plain short-sighted.

I've done some rudimentary reading on functional programming languages -- mostly Haskell and LISP (which is sorta FP) -- and I believe you when cite all the claimed benefits. The architecture of the languages certainly enables it.

However, every time I've tried to get a handle on Haskell, all the examples presented tend to be abstract. In other words, they contrive a problem that Haskell is fairly well-suited to solving, and then write a solution in Haskell, using data structures and representations entirely internal to Haskell. "Poof! Elegance!" Well, um...

I'm a gaming, graphics, and device driver geek, and so my explorations of new stuff tend to lean heavily in that direction. I'm interested in more "concrete" expressions of software operation. Could Haskell offer new or interesting possibilities in network packet filtering? Perhaps, but first you have to read reams of text on how to bludgeon the language into reading and writing raw bits.

The other issue with FP is that they tend to treat all problems as a collection of simultaneous equations -- things that can be evaluated at any time in any order. There's a huge class of computing problems that can't be described that way. You can't unprint a page on the line printer. There are facilities for sequencing/synchronizing operations (Haskell's monads, for instance), but I get the impression that FP's elegance starts to fall apart when you start using them.

Understand that my exposure to FP in general and Haskell in particular is less than perfunctory, and am very likely misunderstanding a great deal. I'd like to learn and understand more about FP, but so far I haven't encountered the "Ah-hah!" example yet.

Schwab

Re:Sure there is

[Anonymous Coward]

Not any serious games that push as many polygons as possible.

"Serious games"? Games are entertainment, and there are vast numbers of entertaining games where performance is not a limiting factor. If you only want to talk about games where performance is critical, then fair enough. But when most people say "games", they mean, you know, anything designed for interactive entertainment. Christ, mobile phones typically have a bunch of games on them, it's one of the most profitable parts of the games industry, so performance clearly isn't universally important.

Sure, you can compile python, but good humans will still beat compilers

Completely and totally irrelevant. What matters when you are talking about performance is whether you can perform well enough to be entertaining. Whether one approach performs better than another only matters to language fanboys; in reality as long as you meet your constraints, absolute performance isn't important. For example, if a really slow implementation of sudoku runs a hundred times slower than something you cook up in assembly, it doesn't matter as long as the crappy implementation runs fast enough, and it's actually the best choice if you can write the stupid, slow version faster than the smart, fast version.

Re:Sure there is

[QuantumG]

A lot.. but not as many as I would expect have been written in functional languages.. seeing as they are so much easier to write multithreaded apps in.

Look, I don't think I'm asking something too unreasonable here. If functional languages are so much easier to write multithreaded apps using, then show me. Either point at something that already exists which demonstrates this claim or write something new that demonstrates this claim.

The claim has been made, back it up.

Re:Sure there is

[Bill Barth]

Yes, but if you look at the code in Appendix A, it's written in C++. Yes, it calls a the MapReduce library which is functional in style, but the user still must write their code in an essenitally procedure language. Yes, the library hides a lot from the user, but so what? They still have to write their code in C++! The OP exhorted us to "abandon C and Fortan," but you're touting a C++ class library as an example of a win for functional languages. I assume you can see why we might object!

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."

Re:Sure there is

[Fnord]

A perl6 *interpreter* was written in haskell, and it's considered a non-performance oriented reference implementation, purely for exploring the perl6 syntax. No one has ever doubted that interpreters and compilers are easier to do in functional languages. One of the things you learn first when you take a class in lisp is a recursive descent parser. But the version of perl6 that's expected to acutally perform? Parrot is written in C. The fact that its no where near done is a completely different matter...

Re:Sure there is

[beelsebob]

On the contrary -- this is a functional language -- the reason this can work so fast and be so parallel is that they have referentail transparency, and that they can do lots of things without them interfereing with each other. That's because they're writing functionally. It doesn't matter whether the translation happens into a high level language (like C++) or a low level one when the compiler transltes it into machine code.

The bottom line is that until we change architecture, we have to translate out functional programs into procedural code. That doesn't mean though that we can't get massive benefit by writing in a functional style (as google have done).

Re:Sure there is

[Anonymous Coward]

Do you even understand the problem?

Re:Sure there is

[Bill Barth]

There's no MapReduce compiler. The programmer writes C++. So, at best, the programmer is the functional language compiler, and he has to translate his MapReduce code into C++.

Again, no one disagrees with your idea that writing in a functional style is a good idea for parallel programming, but the OP said that we should give up on two specific languages and pick up a functional one. Clearly a program in a functional style can be written in C++ (which is a superset of C89, more or less, which is one of the two languages mentioned by the OP). The challege to the OP was to show the world a massively parallel program of significance written in a functional language, not one written directly in a procedural language but in a functioal style. You showed us the latter, we'd still like to see the former.

Re:Sure there is

[beelsebob]

I think we've come to a violent agreement then. In the mean time for your real world programs... see lower down for your telecoms systems being functional (erlang), your ATC systems being functional, nd your 3D games being made parallel in functional languages.

Re:Sure there is

[alphamugwump]

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.

Re:Sure there is

[bryxal]

Ya, certainly not a serious game like Civilization 4. Oh sure its not full out Python many of the part are written in C but it shows how it has its uses and its strenghts

Re:Sure there is

[Anonymous Coward]

If you actually read that paper, you will notice from the code snippet at the end that map reduce is a C++ library. So it kind of proves the exact opposite of what you intended: people are doing great stuff with the languages that you are saying should be dropped.

Re:Sure there is

[Watson Ladd]

Erlang is used for some massively parallel problems like telephone switches. SISAL outperformed Fortran on some supercomputers. Jane Street Capital uses O'caml for their transaction processing system. Lisp is used in CAD programs. So FP is being used.

Re:Sure there is

[slowtuna]

Abandon Fortran???? Never!!!

Re:Sure there is

[QuantumG]

None of that is verifiable. Show me the code.

Re:Sure there is

[Coryoth]

Abandon C and Fortran. Functional programing makes multithreading easy and programs can be written for parallel execution with ease. And as an added benefit, goodbye buffer overflows and double frees! Functional languages seem to regularly get trotted out when the subject of multi-cores and multi-threading comes up, but it really isn't a solution -- or, at least, it isn't a solution in and of itself. If you program in a completely pure functional manner with no state then, yes, things can be parallelised. The reality is that isn't really a viable option for a lot of applications. State is important. Functional languages realise this, and have ways to cope. With the ML family you get a little less purity as a tradeoff for a little more practicality. With truly pure languages like Haskell you just have to bind up state into monads, which is fine, except then you still have to reason about how to multithread the monadic portions of code.

This is not to say that functional programming isn't good. It is. It's great! It just doesn't magically make multi-threading problems go away -- at least not for the majority of applications. Functional programming is a fantastic way to go with many benefits, but it isn't a magic cure-all for multi-threading, and I wish people woul stop presenting it as if it were. If you want languages that are great for multi-threading then try languages designed with concurrency in mind like Erlang, or E, or Oz, or Scala. They won't magically make your problems go away either, but they will, at least, provide you with a paradigm that allows you to think and reason about your multi-threaded code much more easily.

Re:Sure there is

[bazald]

...a human can't possibly juggle it all in their head. A good human will *never* be as good as a compiler for these chips... Mel could... Mel could...

http://www.pbm.com/~lindahl/mel.html

Re:Sure there is

[Watson Ladd]

And Windows is written in C#? Ok:
Jane Street Capital.
A high performance Erlang webserver.

Re:Sure there is

[QuantumG]

Yep, and? Just looks like it is written in Erlang because the author liked Erlang.. other than this "elegance" concept, what's the value?

I'm actually a fan of functional languages.. in so far as they are part of formal software development.

Re:Sure there is

[slamb]

This kind of pisses me off. People who are functional programming ethusists are always telling other people that they should be using functional languages but they never write anything significant in these languages.

I think that's true of all people who claim to have a silver bullet. For example, I'll be impressed when the "eXtreme Programming 100% test coverage, no checkins without a new test passing" crowd actually manage to write a kernel like that, including tests demonstrating complex race conditions and hardware interactions. Until then, I'll achieve maybe 60% test coverage (maybe even integration tests, not unit tests! horror!), I'll consider it good, and I'll assume that people who say otherwise are bragging about writing toy systems.

Re:Sure there is

[poopdeville]

The other issue with FP is that they tend to treat all problems as a collection of simultaneous equations -- things that can be evaluated at any time in any order. There's a huge class of computing problems that can't be described that way. You can't unprint a page on the line printer.

This is what lazy evaluation is for. You actually can describe printing a page functionally. What'll happen, internally, is that the topmost print function won't terminate until it has satisfied all its "dependencies". Just like a procedural language, where a function returns when every function it called returns, recursively. But a functional language is just a little slicker.

Let's consider a plain old mathematics problem. Let's say we want to find the area under the line y = x on (0,1).

Now, obviously, we have to evaluate the integral $\integral x dx$. Note that this is an operator on functions. Given a function (of real numbers) f, we can find the anti-derivative $I(f) = \integral f(x) dx$.

To compute the area under the line, you have to evaluate a function A(f,a,b) defined by (I(f))(b) - (I(f))(a). (The value of the anti-derivative of f at b minus the value of the anti-derivative of f at a).

Here's the slick part. The definition of the function is in some sense the computation. I described the functions I and A in one order, but I could have described them in the other, just by using the same notation and implying that the other definition would come soon. And even if I defied A but didn't define I, you would still know that A(x^2, 0, 1) was (I(x^2))(1) - (I(x^2))(0). In a parallel system, that computation can be done at the same time as I(f), I(f)(0), and (I(f))(1), although all three have to be done before you know the actual area.

Also, check out: http://www.defmacro.org/ramblings/lisp.html

Re:Sure there is

[Bill Barth]

Again, as another noted, there's little evidence for parallelism in these programs. I'm not saying there isn't any, it's just that we can't see it.

I (as someone who works at a supercomputing center) am still waiting for a parallel weather forcasting code or hypersonic aerothermodynamics code or the like written in one of the many functional languages touted here. I deal with such codes on a daily basis, and they're all written in Fortran, C, and C++ (in that (decreasing) order or occurrence). These are the parallel programs that are meaningful (to me). This may largely be due to historical intertia (you code like you learn and engineers, chemists, and physicists learn procedural languages), but sometimes I'd like the advocates of functional languages to put up or shut up. If it's so easy to write a massively parallel program in Haskell, I'd like a Haskell maven to write a parellel incompressible Navier-Stokes finite element code with implicit time integration on unstructured hexahedral meshes and put mine (written in C++) to shame both in terms of computational speed and efficiency and in terms of lines of code (or whatever metric of code beauty is preferred)!

Re:Sure there is

[Doctor Memory]

What makes you think a compiler will be able to do it better than a human? Guess you missed the mention of "ultra-wide execution units" in the summary. Think Itanium, think of scheduling in terms of "bundles" of simultaneous instructions, ponder how to group the instructions in your multiple threads of execution so that if one thread branches, the code for the other threads is in the same bundle as the code the one thread branches to. I'm sure these chips will run fast, because they won't have to worry about coordinating "in flight" instructions, or keeping register scoreboards — that's all on the compiler writer's plate now. And good luck working it out by hand. I wouldn't bother writing an inner loop in assembler if it was more than a couple hundred lines today; on one of these chips, I wouldn't bother if it was more than twenty or thirty. Snag a copy of the Itanium architecture and instruction set manuals and try scheduling a few instructions for yourself.

I'm almost wondering if we'll finally see VMs starting to edge our statically-compiled code on these chips. Something that could cons up a dynamic instruction stream based on the current task mix might be able to edge out some frozen execution unit that had its code generated based on the idea that it was the only job on the box. If it's too difficult to write a good compiler, then compiled code loses its edge and interpreted code looks better. Of course, the interpreter still has to be compiled, so the performance gap may remain, but something with a sufficiently small run-time (Scheme or Smalltalk, maybe, forget JVMs and the CLR) might see an advantage. How big is the Erlang run time, I wonder...

Re:Sure there is

[toddestan]

Can you show me any open source project where massive parallelism is being exploited? I'm not sure I can think of any.

BOINC?

Re:Sure there is

[Pseudonym]

Look, I don't think I'm asking something too unreasonable here.

By limiting to open source only, I think you are.

Let's take the classic example of a difficult multi-threading problem: a DBMS. It's not completely separable, like an FTP server, and it's not effectively serialised, like an X11 server.

Have people written highly-threaded DBMSes in functional languages? Sure. Are they open source? Probably not. There are a few decent open source DBMSes, so there's really no itch to scratch. (So why was Mnesia written? For telecommunications applications, like telephone exchanges; not exactly a haven for open source.)

Re:Sure there is

[QuantumG]

Excuse me.. but you are trying to justify to me that it is better to write certain forms of software in functional languages, but you're not willing to show me the code that is written in that way so that I can personally evaluate whether or not the code is "better". So basically you're asking me to take it on faith. For all I know the program you are claiming is written in a functional language might not be.. or may be so convulted and unmaintainable that it doesn't matter how well it stacks up in benchmarks.

Re:Sure there is

[xenocide2]

How about Hadoop?

Seriously though, looking at the Debian compiler shootout, ocaml does fairly well at CPU intensive applications. In the past I've seen some applications claimed to be written in it (unison), but I can't find a decent list of them, and I don't remember any being parallel / distributed. Yahoo! stores was apparently written in Lisp, and Paul Graham won't shut up about it.

But the GGP is talking about extending such languages, already sparsely in use, to distributed computations. Erlang is the poster child for this. For those acquainted with functional languages the concept seems simple. But many a student I know has trouble wrapping their mind around functional languages. Whether we want to apply these students to distributed computation is one question, whether we'll have a choice in the future is another. There's numerous apps written in erlang that claim some advantage over a non-erlang oss competitor, like a webserver that handles far more open connections than apache (and likely supports far fewer features). Skepticism is healthy, but you've taken it into the unhealthy realm of being combative.

Re:Sure there is

[Pseudonym]

Excuse me.. but you are trying to justify to me that it is better to write certain forms of software in functional languages, but you're not willing to show me the code that is written in that way so that I can personally evaluate whether or not the code is "better".

First off, I didn't make the original claim.

Secondly, I agree with you that if you can't see the source code, it's not science.

But thirdly, I still think you're being unfair. You don't need to see the plans for a Boeing aircraft and a Tupolev aircraft to know that you're better off riding on Boeing. All you need to do is look at the crash record. Similarly, there are plenty of observables: Robustness, speed of fixing bugs, time-to-market etc, which, taken together, form a pretty good picture of how good code is.

[...] or may be so convulted and unmaintainable that it doesn't matter how well it stacks up in benchmarks.

If you want to know how maintainable code is, submit a problem report. If it's not fixed in a timely manner, that doesn't prove anything (it could be the code, or could be the team). If it is, then the code has to be at least pretty maintainable.

Re:Sure there is

[stephentyrone]

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.

Re:Sure there is

[Anonymous Coward]

Nah, extra credit if you can do anything RELIABLE over USB.

Re:Sure there is

[xenocide2]

Wouldn't Apache's server thread pool be an example? And surely there's some open source version of seti@home (possibly seti itself?)

Re:Sure there is

[xenocide2]

With respect to the topic, I don't think multithreaded apps are what's important here. Distributed apps are probably more important. The sub processors in Cell don't have shared memory, after all. I think your requirement for multithreadedness might be slightly bogus, and the technologies that are in use now for computational clusters may fare better when used in alternative GPU designs.

Re:Sure there is

[ChrisA90278]

"open Source" is not a factor here. No one would write open source software that takes advantage of hardware that no one owns. It you are witting software that is to runs one 100+ core machine you are likely getting paid by the people who own the huge room full of equipment.

Last I checked they were running software to compute aerodynamic loads on space lift boosters on the cluster. It's one of those jobs that just runs for days and weeks even on racks of dual CPU linux boxes. It was an optimization search type job that a fluid dynamics simulation in the inner loop.

Lots of people do stuff like this. At work I work on a kind of compiler for a parallel machine

Would be usless to put this kind of code out on the web as Open Source

Re:Sure there is

[Goalie_Ca]

No, the implementation is not purely functional.. but what allows the massive parallelism are the ideas and techniques from a functional programming language! In the paper google describes unprocessed chunks.. that's pretty much what a thunk is (unevaluated statement). But they also state the map and reduce functions themselves are written in c++. It's not pure, but it is functional... So we'll call it a tie.

Re:Sure there is

[Bill Barth]

As I keep saying, this whole argument came up b/c the OP told us to drop C and Fortan, but here we are with Google using C++ to do something cool! Doesn't look like there's a need to drop C or Fortran, just a need for some smarter-than-the-average-bear programmers to make some libraries to make everyone else's life easier. Sorry, you can't have your tie. Putting functional ideas in a procedural language is good learning, but it's not a functional language showing off it's ability to handle massive parallelism like the touters claim.

Re:Sure there is

[Tsagadai]

You underestimate me! Humans write compilers too. Most humans may not understand the complexity but that does not mean all can't. Remember a team of humans designed cell as well.

Re:Sure there is

[tgcid]

Let's see...

1. Abandon C for a functional language
2. Realize that C is a functional language and go back
3. ???
4. Profit!

Re:Sure there is

[Anonymous Coward]

Oh give it up. Ocaml is cool and all, but it doesn't even make use of multiple processors. It's got a single-threaded garbage collector, so if you want concurrency, you have to use multiple processes and have some other mechanism between them to communicate. Good luck getting your elegant Ocaml program to scale across a 4 processor x86 box or the 8 SPEs on the Cell much less anything massively parallel. If you split the task into separate processes you'll get concurrency, but you've given up the elegance that the functional approach was supposed to give you. Until someone makes multithreaded garbage collection easy, the FP guys are blowing smoke. The C++ raytracer could easily be 4X faster on a 4 processor machine with pthread_create()....

Re:Sure there is

[Goalie_Ca]

So why not call it a tie because C++ will need to/is currently plucking some of the more practical functional ideas just as C++ borrowed certain ideas of OOP from smalltalk et al. Python has borrowed some nice things such as haskell's list comprehensions but it also has generators etc (but no lazy evaluation).

Re:Sure there is

[ardor]

Which is absolutely irrelevant, because the most calculations are in 1. graphics, 2. sound, 3. networking, 4. physics, and the first three are *already* parallelized (sound and network usually run in their own threads, to minimize latency, but obviously multicores help). Physics calculations benefit from multicores, yes, but as someone else pointed out already, 95% of the Gflops sit in the graphics department, so we are talking about not much really.

Re:Sure there is

[ardor]

No. First, as soon as states are involved, your nice functional languages break down. Second, these chips vectorize, which is not the same as functional-style parallelization. You could write the same in C++ by having atomic tasks, which can gather, but not scatter, and one thread per core, each one with a list of tasks. This setup has no real side effects, but is NOT the same as as functional language. This also shows why GPUs cannot scatter (it would thrash the vectorization benefits, since pixel shader A would have to wait for pixel shader B to write on the pixel X; by disallowing scattering, pixel X can *only* be written by pixel shader A).

Re:Sure there is

[slamb]

Tim Sweeny of Epic has a pdf floating around.

The PDF in question is The Next Mainstream Programming Language: A Game Developer's Perspective. It's a good read, though I wish there were a paper version rather than just a PowerPoint presentation.

Re:Sure there is

[MemoryDragon]

Heck the problem even is, that functional programming means kicking out every knowledge of how to do good software design which was built up since the sixties. Most functional languages become barely usable in the domain of bigger than a few lines of code programs once they introduce methods, namespaces, objects, you name it and become normal procedural or OO programming languages. Sorry to say that functional guys, but you are stuck 40 years in the past from the software engineering side. As for parallelism, it is only kept simple as long as you are stuck in a certain small subset of problem domains, once you run into data sync problems (which is normal once you have more than a handful lines of code) you usually run into the usual synchronization problems, which means, critical regions, threading, semaphores etc... and then things becomes nasty, no programming language can help you out there.

Re:Sure there is

[chthon]

Parent should have been modded funny, not insightful (I love the smell of satire in the morning).

Re:Sure there is

[zippthorne]

MATLAB?

It's based on Fortran though...

Re:Sure there is

[gnalre]

You have a point that the reason functional languages are not popular is that they go against the standard language paradigms that most people are familiar with. However I contest your claim that function programs do not scale well. As mentioned previously Erlang has been used in projects consisting of million of lines. In fact one of the reasons that Erlang was developed was the total failure of a previous project to scale using C++ and OO techniques.

The problems with programming is despite 40 years of experience the same problems keep occurring in terms of developing projects. Many answers are put forward including new development methods such as Agile, XP, better design methodologies such as UML but we never seem to progress very far. Maybe the issue is that the most common languages still use a syntax that was developed when 20 lines of code was considered significant. One of the major advantages of functional programming is its runtime consistency. If it fails it will always fail in the same way. Compare this to C/C++. This makes testing large projects much easier. So when you talk about programming you must consider the whole package . Design, Developement, Testing, deployment and maintenance. In my experience functional programs are much better espicially in the Testing, deployment and maintenance phases.

When it comes to parallelism again the runtime consistency is a great advantage over non-functional languages where parallelism has to be shoe horned onto the language. It is very easy to write safe multi-task programs in a functional language without having to resort to such artificial mechanisms such as semaphores and critical regions.

Re:Sure there is

[MemoryDragon]

I dont talk C++ here which is the biggest failure of language design, even worse than Cobol, but at least Cobol could get the credits that they did not know better back then. C++ cannot be given the credits, OO languages have been in existence since the mid sixties.

Back to pure functional language, lets look at the paradigm, everything is a function, what do you get, nothing except a normal programming language which is stripped down to its core, with procedures removed, namespaces and objects. This screams for a mess in itself, because there are no ways to structure your code decently once a system becomes bigger.

The main reason for a system having failed in C++ and being successful in a functional language, can be credited to three factors, the removal of C++ which is inherently problematic, an introduction of a vm and garbage collection, not necessarily being contributable to the functional language, and probably a tigher project management which was necessary because the language itself does not force any order of the code. (Ok I do not know Erlang, I do not know if this language provides the basic structures for code organization, most academic functional languages do not have)

I personally am not convinced that a pure functional approach is any solution, except for basic scripting, there is so much lack of know how which was introduced in the last 40 years to solve the problems, while I have the gutsy feeling that the designers of functional languages simply either do not know them or they do not exist in their problem domains. Once those languages are tested against real world software systems, the constructs are readded again which are there in other languages in the first place (after all it is a small step from a pure function to a procedure, after that it is a rather small step to objects, and namespaces)

This is the same problematic most scripting languages (which often have overlapping domains) face, first they are small, often pure functions, then the problem domains they are applied become bigger, more and more constructs of existing languages are added, and then you end up with a normal programmling language, which has in its core the root language, and often some consctructs like closures, and integrated list handling etc... but in the end it is not really a scripting language anymore.

Re:Sure there is

[master_p]

Not only that, but FP programming has the exact same problem with imperative programming: deterministic synchronization of the IO monad (for the uninitiated, the IO monad turns your functional code into imperative, allowing assignment and a specific order of execution). For simple cases, it's dead easy: just synchronize using a mutex. But what about recursive data structures? not only simple imperative code becomes highly complex functional code (in order to process recursive data structures in a functional manner, you have to use patterns like the zipper, for example), but you have to put synchronization for the parts that are updated using the IO monad.

The solution to parallelism is not functional programming, but the Actor model applied on object level: each object should have its own thread, and computations for each object should be posted as jobs to each object. It's the only way that reveals the possible parallelism of a program.

Re:Sure there is

[TheRaven64]

Look at practically anything written in Erlang. There's a decent Jabber server (now used by jabber.org) a web server that scales better on a single CPU than Apache, and flies on multiple cores, and a decent ray-tracer, just off the top of my head. I've used it to write code that scales very happily to a 64-CPU machine, without much effort.

Of course, even though Erlang is functional, it is CSP and not not pi-calculus based, and so probably doesn't support the original poster's assertion. If you want something based on that, take a look at the Polytypic Grid project. They presented a paper at IEEE Visualisation last year where a few visualisation algorithms were written in (surprisingly small amounts of) Haskell, and exploited lazy evaluation to achieve quite surprising performance.

Re:Sure there is

[Anonymous Coward]

Why on earth would you write your data structures in the IO monad?

If you're going to argue against FP you shouldn't argue against C-style programming in an FP language. FP does help with parallellism since you DON'T ever update memory values (semantically, obviously the program does tons of it when running) so you never have to worry about things like semaphores etc.

So yeah, imperative low level code is still imperative low level code, but won't you rather have 1% of it than 100% of it?

Also, e.g. Haskell has transactional memory for the few bits where you really need mutable variables, which eliminates the need for complex locking etc. and provides a truly composable concurrency abstraction.

Re:Sure there is

[Anonymous Coward]

Wings3d is written in Erlang, I believe:

http://sourceforge.net/projects/wings
http://www.wings3d.com/index.php

Re:Sure there is

[yanagasawa]

Ericsson uses erlang to write massively parallel systems (e.g.):http://www.ericsson.com/products/hp/AXD_301 _305_MultiService_Switch_Rel_7_1_TAG_MSG_MGW_pos.s html/

Re:Sure there is

[TuringTest]

But games have always been married to the hardware, and I don't see how that could change any time soon.

What makes you think functional programming can't be married to the hardware? In fact, multicore computers are better programed through functional languages than with the glorified Von-Neumann architecture that is C++.

Also, there is nothing keeping you from controlling memory allocation for textures & poligons by using a functional dedicated library.

Re:Sure there is

[GooberToo]

a web server that scales better on a single CPU than Apache

I really wish people would stop using Apache as a performance metric. Apache's priority has always been scalability, security, and features, but not performance. The fact that it's historically faster than MS' effort is an embassessment for MS, but it does not mean it's the holy grail of web servers.

Simple fact is, it's common to find web servers which are much, much faster than Apache. Some web servers which are faster than apache are even written in languages like python.

Re:Sure there is

[GooberToo]

total failure of a previous project to scale using C++ and OO techniques.

But history shows that the reason most C++ projects fail is not because of the language, but because of low performance programmers that insist on using OO-idioms without regard for C++-implications.

I can't tell you how many times I've seen projects fail because of poor design, no design, poor requirements, poor programmers, bad managers, and horrible schedules, but ultimately blame the language because no one wants to accept where the finger really points.

Which do you think is more likely; managers and programmers step up to higher ups and say the project failed because we're idiots or, they step up and say, the language failed us?

Simple fact is, C++ is a hard language which often requires additional time in schedules. Sadly, schedules are usually one of the first things people attempt to compress and normally those schedules are based on years of experience with languages like C. The end result is bad programmers write bad code which is then not optimized and poorly debugged, to meet a bad schedule which is later compressed by bad management, which failed to properly estimate in the beginning.

Re:Sure there is

[Kupek]

Keep in mind that while MapReduce is a functional concept, it relies on an extraordinary amount of procedural or object-oriented code in order to function. Specificaly, the Linux kernel, the entire Linux system stack and the Google File System. I think functional programming is neat, and I particularly like it when people find practical applications for it (bonus if it's in a high performance context), but don't ignore the significant infrastructure that enables it to happen.

Re:Sure there is

[Communomancer]

I don't want to get all confrontational, since I'm hardly an expert in functional programming or Erlang, but if you want to check something non-completely-trivial out, look at this:

http://chi.valro.us/erlang/brain.erl

I did this as I was first learning Erlang...it's an implementation of the A-star pathfinding algorithm (used a lot in games). This was my first, non-trivial Erlang program, and also the first time I ever implemented A-star, so there are bound to be inefficiencies.

But what I do have here is a 176 line program that implements parallelizable & distributable time-bound A-star for any number of AIs that need pathfinding. There's some hard-coding in terms of the number of AIs right now and their goal destinations, but that's easily removed.

Re:Sure there is

[buck68]

How about this: http://conal.net/Vertigo/

I saw Conal give a talk on this, and I was very impressed. Pity it didn't seem to lead to anything since Conal has left Microsoft(?).

-- Buck

Re:Sure there is

[bob.appleyard]

I'm writing a monkey-typewriter simulator for a parallel computer. Two threads per monkey!

Re:Sure there is

[SlashSquatch]

Nice summary.

Re:Sure there is

[Anonymous Coward]

:: a web server that scales better on a single CPU than Apache
: Apache's priority has always been scalability, security, and features, but not performance.

I'd make a witty comment here but your reading comprehension probably isn't up to it. The metric is not performance or speed but number of simultaneous requests and Yaws scales much better than Apache2.

Re:Sure there is

[master_p]

You do update memory values. When you do:

f = do
      a - b
      x - a
      return x

g = do
        y - f
        return y

the compiler optimizes the code by using one memory location for all the computations.

If you observe Haskell programs, 90% of them use IO(), IORef() and *M functions. That's imperative programming.

Re:Sure there is

[The Raven]

15 years worth of phone switches and high performance networking equipment, written in erlang. In fact, most of the calls you make, and some of the Internet traffic you receive, has passed through high performance, 5 9s uptime, massively parallel data switches written in erlang.

Re:Sure there is

[CandyMan]

Tim Sweeney says that 90% of the CPU budget of Unreal Engine games is spent in functional code doing numerical computations: This functional code makes up 50% of the codebase, and he suggests that the next mainstream language should have more functional elements, learning "lessons from Haskell". According to slide 46, "80-90% of the CPU effort in Unreal can be parallellized" using "Haskell's HT, HTRef solution" which "enables encapsulating local heaps and mutability within referentially-transparent code".

More Tim Sweeny quotes from the presentation: "In the future, we will write these algorithms using referentially-transparent constructs.". "In a concurrent world, imperative is the wrong default!" That, to me, sounds like is using a functional language to write videogames, even if it is not a purely functional one and still has procedural parts. The only procedural code will be running the side effects, for about 10% of the total CPU time.

Re:Sure there is

[sbaker]

If by 'numerics' you mean 'collision detection and game physics' then please note that there are some convincing implementations of those things on the GPU too. When you are already using 500Gflops for shading - then adding 5 more Gflops makes negligable difference. But offloading 5Gflops from a machine that only needs 0.5 for game logic makes a spectacular difference. So if your figures are correct then logically the GPU should evolve to do physics...which is exactly what is happening. That leaves the CPU with very little left to do - except maybe AI.

Re:Sure there is

[BiggerIsBetter]

Can monkeys type with their feet? Better make it four threads.

Re:Sure there is

[gnalre]

Back to pure functional language, lets look at the paradigm, everything is a function, what do you get, nothing except a normal programming language which is stripped down to its core, with procedures removed, namespaces and objects. This screams for a mess in itself, because there are no ways to structure your code decently once a system becomes bigger. One of the advantages of functional languages is that a lot of the constructs which are inherent in C type languages are not required since the language itself maps more closely to the problem domain. You suggest that simplicity is some sort of disadvantage. However actually it is its strength since we can spend more time solving the application problem rather than dealing with the inconsistencies caused by the language itself. For example in most languages I have to concern myself with data types so I can tell the computer how to store my data. However the only reason I have to do that is because the language is requiring me to make design decisions due to the underlying platform(The computer). Functional languages abstract me from that, so allow me to be far more productive. As for scalability, experience has show that such languages are very scalable and because of the code simplicity it is is far easier to maintain.

Ok I do not know Erlang, I do not know if this language provides the basic structures for code organization, most academic functional languages do not have One of the reasons I like Erlang so much was that it was a language designed to adress real project issues and not academic niceties. In some ways it puts a lie to my arguments because it is not a "pure" functional language such as haskell. The reason for this is that the designers made comprimises when language "purity" got in the way of usefulness. However in doing so it makes it all the more powerful.

Re:Sure there is

[3.1415926535]

It's not really what you asked for, but I wrote this for a graphics class in college:
http://aaron.homeip.net/~aaron/lab4.tar.bz2

Run it with ./oglRenderer 500 500 vornoi.wrl

Super-wide?

[Toe, The]

As a highway gets wider and wider... it approaches a parking lot.

Re:Super-wide?

[Anonymous Coward]

No it doesn't. In a parking lot, cars stop. Nothing about widening a highway implies that cars stop (in fact, quite the opposite!).

Re:Super-wide?

[Short Circuit]

Unlike ultra-long pipelines, wide execution units don't add to instruction latency. Your analogy doesn't follow.

Re:Super-wide?

[Anonymous Coward]

That is one of the dumbest comments I have ever read on slashdot. And that's saying something.

Re:Super-wide?

[Anonymous Coward]

But what's even dumber is the fact that his comment was getting a (+4, Insightful) for a while.

It just boggles the mind.

Re:Super-wide?

[Broken scope]

Because of how people are while driving, after 6 lanes you stop getting increased traffic flow and you can actually have slow downs.

Re:Super-wide?

[Toe, The]

As the op, I was surprised as well... it was supposed to be a joke (and a lame attempt at an (obviously late) first post).

Very insightful of me, eh? :)

As to it being the dumbest thing ever... again... a joke, OK? Sheeze.

Cell

[Gary W. Longsine]

The direction looks similar to the direction the IBM Power-based Cell architecture is going.

Re:Cell

[peragrin]

That was my thought too. Multiple cores with a handful of specific cores.

IBM's cell processor would be a lot more useful in general if it was slightly modified. replace one or two aux cores with GPu cores. 2-4 as more general purpose cores, and one or two FPGA style cores, possibly with preset configuration options(ie audio processing, physics, video, etc).

Complicated, yes. But can you imagine what one could do. Your single computer could be switched on the fly to encode an audio and video stream far more efficiently. Using GPu, and PPU's, game play could be increased.

it is a pipe dream. There is a lot of work. Software would have to be modified, And the net gain may not be all that much. Of course long term gain on such a porject would be very useful.

Astroturf

[Anonymous Coward]

Arun Demeure writes "Beyond3D has once again obtained new information...

If you are going to submit your own articles to Slashdot, at least have the decency to admit this instead of talking about yourself in the third-person.

Re:Astroturf

[Anonymous Coward]

One of the wonders of text-based internet communication is that everyone can try guessing your age based on vastly insufficient information. But it gets scary when every year, it looks like people think you're growing younger, not older. One theory is that I'm getting cooler all the time. Another is that I'm just getting dumber. Either way, I think I'd rather not know the answer to this question.

What a prick.

Re:Astroturf

[Anonymous Coward]

Said the anonymous coward

Re:Astroturf

[fm6]

He is the third person! (Cue zither music.)

Re:Astroturf

[Anonymous Coward]

Said the anonymous coward...

future of computing?

[jcgf]

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.

Re:future of computing?

[EmotionToilet]

That's a really interesting idea. Processor, flash hd drive, ram, and power supply all on one board. That would definitely be sweet.

Re:future of computing?

[TerranFury]

When they put it all on one chip, they call it a Microcontroller. When they build it from a few chips, all soldered on a single board, it's called a Single Board Computer. So, this idea is quite widely baked.

(assuming you're not being sarcastic.)

Re:future of computing?

[EmotionToilet]

What about numerous different die connected together, in the way that AMD is looking to add graphics processors onto their pc processors? I don't really pay much attention to hardware anymore. It moves too fast for me to keep up with. I keep my eye out for things about quantum computers and carbon nanotubes, but that's about it. As far as I'm concerned, within the next 10 years we're going to have computers that will go way faster than anything your average user will ever need. I think the biggest change in computers will be in software and input devices, like touch screens or neural implants. Also in mobile devices. The only thing I know about the future of computing is that I know nothing.

Re:future of computing?

[Anonymous Coward]

It's been done before. The most integrated parts are SoC (system on a chip) and we've had various levels of integration. Just take FPU's as an example. My 386 didn't come with one. It was actually an extra chip. What Intel and AMD are planning to do is not much different. Using stream processors and multiple cores with different functions has been done before but only by a few people among the many who work in this domain. So the concepts are not very well known or even teached in schools. What Intel and AMD are doing is set standards, so programming techniques used by only a few people before will have to be learned by everyone else if they want to keep their jobs.

Re:future of computing?

[init100]

This is more or less what the individual compute nodes of the Blue Gene are. The nodes consist of dual Power-PC processors, 512 MB RAM, network interface and supporting circuits, all integrated on one chip that draws around 17 Watts of power. That's essentially why you can get 1024 nodes into one 19" rack, which is capable of about five TFLOPS.

Re:future of computing?

[jcgf]

I'm not an idiot I know what a microcontroller is. But I don't know of any microcontroller that has say 1gb ram, a semi decent gpu, and a couple of cpu cores. I wouldn't be surprised if someone goes for the easy mod points and googles up something that's close but not quite what I'm talking about.

We need a new architecture

[jhfry]

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?

Re:We need a new architecture

[Pharmboy]

Itanium?

Re:We need a new architecture

[Short Circuit]

We need that about as much as we need to switch to trinary. (It's obvious, after all, that binary is preventing us from making advances in the fields of logic and compression, isn't it?)

No, we'll get a new architecture as soon as we need one. That is to say, once advancing the x86 architecture becomes more expensive than is cost-effective, someone's going to come up with a cheaper replacement that still has room to grow.

Sure, it would be nice if assembler instructions allowed one to designate a destination register, but that isn't really important, or even an area of focus. Code size for desktops, laptops and many embedded applications has become largely irrelevant. Even code efficiency has taken a backseat everywhere but performance data processing applications. Hell, when you've got 3D games being written in managed code, it must be obvious that developers would rather focus on complexity over speed. (Though that might change if the focus continues to shift towards data-driven web applications. Those applications qualify as high performance, and maintaining racks upon racks of servers isn't cheap.)

Re:We need a new architecture

[chris_eineke]

Once you find something that works one magnitude (10x) better than the old technology, people will adapt it.

Re:We need a new architecture

[jstockdale]

Um ... it didn't ring a bell at first then I figured out you just mispelled Itanic ;-)

Re:We need a new architecture

[MOBE2001]

Why not do away with most of the legacy technology in one swoop and update the entire industry to a new standard.

I agree. However, one should design a new CPU architecture based on a software model, not the other way around as was done with the CELL cpu.

PS, I know why, money, too much investment in the old to be worth creating the new. But I can dream can't I?

Yes you can dream. But unless the new architecture is going to solve a big problem in the industry, it's not worth it. The biggest problem in the computer industry right now is not speed. It's software unreliability. Functional languages are more robust only because they use concurrency effectively and isolate faults as a result. But there is more to reliability than fault tolerance. There is a need for a non-algorithmic, synchronous software model.

Re:We need a new architecture

[Eli Gottlieb]

A System Programmer's 10 Feature Requests for a New Architecture:

1) Inherent support for parallelism in the instruction set. At the least, this should include increased numbers of atomic instructions and easier atomic memory access.
2) Replace segmentation and page-based protection with Mondriaan memory protection and a tagged TLB. This would be a godsend to microkernel systems and grant incremental security and speed boosts to macrokernels.
3) I know IA-32 already has them, but please give us precise interrupts. Imprecise ones are too much trouble with which to program.
4) Define a clear set of registers and memory locations that constitute the current continuation or thread state. Make these extra fast to manipulate as a whole, enabling faster thread switches and clearer thread definitions without making software do things like define which register is the stack register.
5) Make everything else RISC for speed.
6) Decreased reliance on caches.
7) A security model based on something other than concentric rings. Up-calls help form system features like scheduler activations that can increase speed, and the processor shouldn't make you part the Red Sea to write them.
8) Let programmers decide the destination register of instructions. Will it really slow things down that much or take up that much memory?
9) Decide which I/O model to use: a port I/O address space accessed via special instructions or memory-mapped I/O at special addresses. Then stick with it. Whatever you pick, the security mechanism controlling it should allow easy direct access to hardware from user space programs with the operating system's permission. And if you decide on memory-mapped, find some way to clean up the holes in physical address space that memory-mapped I/O currently causes.
10) Abandon support for legacy 16-bit modes.

Re:We need a new architecture

[Animats]

However, one should design a new CPU architecture based on a software model, not the other way around as was done with the CELL cpu.

Agreed. The Cell "build it and they will come" attitude isn't working. Although if you had maybe 16MB per CPU, instead of 0.5MB, it might work.

The biggest problem in the computer industry right now is not speed. It's software unreliability.

If anybody cared about software reliability, C and C++ would have been fixed by now.

We know how to make reliable software. Tandem had that problem nailed by 1980. We even know how to make secure software. But users will pick animated cursors over mandatory security.

Re:We need a new architecture

[Anonymous Coward]

That's the point. The fact is that Intel has tried it - *lots* of companies have tried it, IBM, RISC, TI, Motorola to name just a few. But it all comes back to legacy support. Itanium was a chance to switch to a new architecture, but the market wouldn't budge. AMD came out with the Opteron, and everyone went back to x86.

Re:We need a new architecture

[Anonymous Coward]

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?

That is a very retarded statement to make. What is a cartridge if not an internal card designed to be removable and interchangeable? Do you feel any need to frequently remove your video card? What about your RAID controller? Obviously not.

For the purpose of interchangeable, removable portable hardware we already have standards like USB and Firewire. Heck, we even have a couple of wireless standards for those of us who do not even believe that plugging a device to a computer is reasonable.

Re:We need a new architecture

[jozmala]

From EE student switching to CS...

1) Inherent support for parallelism in the instruction set. At the least, this should include increased numbers of atomic instructions and easier atomic memory access.

Reasonable request.

2) Replace segmentation and page-based protection with Mondriaan memory protection and a tagged TLB. This would be a godsend to microkernel systems and grant incremental security and speed boosts to macrokernels.

Mondrian memory protection looks like net loss. Complicates L1 cache access.

3) I know IA-32 already has them, but please give us precise interrupts. Imprecise ones are too much trouble with which to program.

Standard, no-one except me would consider the imprecise ones.

4) Define a clear set of registers and memory locations that constitute the current continuation or thread state. Make these extra fast to manipulate as a whole, enabling faster thread switches and clearer thread definitions without making software do things like define which register is the stack register.

Agreed.

5) Make everything else RISC for speed.

Well, or VLIW or vector or ...

6) Decreased reliance on caches.

How to do that. Mainmemory latencies are not instruction set dependant. If you mean adding lots of registers, then it starts to complicate things after a point.
You could allow relaxed memory ordering, buts thats pain in the ass for software developers after that.

7) A security model based on something other than concentric rings. Up-calls help form system features like scheduler activations that can increase speed, and the processor shouldn't make you part the Red Sea to write them.

Don't know enough to comment this.

8) Let programmers decide the destination register of instructions. Will it really slow things down that much or take up that much memory?

It took too much memory in the 70's ;) There are few that are inherently separate in that manner for performance reasons. Float & integer do not mix, nor does the status registers, counters etc...

9) Decide which I/O model to use: a port I/O address space accessed via special instructions or memory-mapped I/O at special addresses. Then stick with it. Whatever you pick, the security mechanism controlling it should allow easy direct access to hardware from user space programs with the operating system's permission. And if you decide on memory-mapped, find some way to clean up the holes in physical address space that memory-mapped I/O currently causes.

Agreed.

10) Abandon support for legacy 16-bit modes.

No hardware designer wants to add legact models, it always comes from management or from software people.

Re:We need a new architecture

[TeknoHog]

PWRficient looks like a good contender and works with the existing Power/PPC codebase.

Re:We need a new architecture

[Deliveranc3]

http://en.wikipedia.org/wiki/Quantum_computer
Yes we are currently trying to bang more performance into a square hole, but moving to other physical architectures when something like this is right around the corner isn't productive.

If DWAVE has succeeded in solving a subset of NP problems then a LOT of vector and complex operations will start to be reprogrammed to take advantage of those solutions (Think bizzare sorting algorithms using checksum variants)

Trying to get them to increase power by switching to a diffrent architecture (Even one as powerful as GPUs are for vectors) is meaningless and will just create more overhead.

We should continue to produce more parralel processors and continue with high level cpu specific instructions. Both of these elements will still be useful when/if quantum computing hits.

P.S. I don't know anything granted but the criticism that may follow will be insightful :P Mod Child up!

Re:We need a new architecture

[Eli Gottlieb]

Mondrian memory protection looks like net loss. Complicates L1 cache access. If only speed mattered, we'd all use segmentation. After all, it stores less data and therefore causes less main-memory lookups and therefore runs faster than page-based protection, right? Except that nobody *liked* segmentation and no compiler but Watcom C will emit segmented code.

Mondriaan will improve systems programming enough to make up for speed/storage losses. Fine-grained read/write/execute protection will enable all sorts of new OS features!

Also, I'd like to define a 4a.

4a) Separate activation frames (as register windows, on the stack, or wherever) should be denoted as separate. Specifically, it should be possible to tell the difference between data used for a function call (ie: return-addresses, arguments, and return-values) and the local function activations of the calling and called routines. If you're wondering "why?" this makes the implementation of call gates between privilege levels realistic, thus granting my request #7 without a separate up-calling feature. It also aids in the denotation of subcontinuations in processor state.

Well, or VLIW or vector or ... Whatever works, really.

How to do that. Mainmemory latencies are not instruction set dependant. If you mean adding lots of registers, then it starts to complicate things after a point.
You could allow relaxed memory ordering, buts thats pain in the ass for software developers after that. Ideally, make main-memory access faster. When operating-systems designers plan their systems around how many cache misses they'll generate per unit of time, you're relying too much on cache and main memory is too slow.

It took too much memory in the 70's ;) There are few that are inherently separate in that manner for performance reasons. Float & integer do not mix, nor does the status registers, counters etc... Fair enough.

No hardware designer wants to add legacy models, it always comes from management or from software people. Ahh... management and users. The banes of a programmer's (and apparently chip architect's) existence.

Overall, the time has come again for a processor architecture based more in the models of computation software finds it convenient to employ than in an engineer's performance estimations for specialized workloads.

Re:We need a new architecture

[GWBasic]

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...

I wonder if anyone will create an x86 emulator for this processor. I wonder how fast a parralelized x86 emulator would be?

Re:We need a new architecture

[jozmala]

If only speed mattered, we'd all use segmentation. After all, it stores less data and therefore causes less main-memory lookups and therefore runs faster than page-based protection, right? Except that nobody *liked* segmentation and no compiler but Watcom C will emit segmented code.

Mondriaan will improve systems programming enough to make up for speed/storage losses. Fine-grained read/write/execute protection will enable all sorts of new OS features!


Unfortunately you don't have an idea what it really costs. The end result would be too slow to sell to anyone.

In the great CPU-GPU War...

[Anonymous Coward]

The only winners were the power-supply industrial complex.

And the living envied the dead despite the real-time raytracing.

Similiar to what sun is doing with Niagara

[mozumder]

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.

Not a troll -- Meta-Mod unfair

[Anonymous Coward]

This is a valid criticism and comment.
The 950 is barely passable, especially with Vista.
Not really Intel's fault. Their target was the "barely passable" segment, leaving the real GPU makers the rest of the field. Probably Intel's main reason to offer this was a need by the OEMs for Intel to have a 1-stop shopping solution.

My Dell has the 950 and Vista Business and I wish I had upgraded to a more powerful GPU.

BTW, I am not the same AC as the original post.

Re:Not a troll -- Meta-Mod unfair

[Blahbooboo3]

Uh, turn off all the cutesy graphics and Vista would be fine. Windows classic theme removes all the GUI candy and the 950 is fine...

Re:Not a troll -- Meta-Mod unfair

[Anonymous Coward]

You decided to buy an OS that requires a high end video card to be usable, it's your fault, not Intels.

Re:Not a troll -- Meta-Mod unfair

[postmortem]

...must be even better if you run DOS on it.

Seriously, intel shitsets offer almost nothing. It is not just 3D that is lacking, but hardware decoding features that are perhaps more important.

But you can't expect more from $2 chip.

Most people are not willing to pay more, that is root of problem. Intel just delivers cheap solution. Then some users figure " oh integrated graphics sux and I can't do a thing"... then it is too late.

Re:Not a troll -- Meta-Mod unfair

[Anonymous Coward]

Yeah, I am not blaming Intel.
My comment said "I wish I". No blame at Intel there. Even included the "It isn't Intel's fault" language in the post. Yes, I made a poor choice. I still wish Intel's GPU was better, but I don't harbour horrid feelings towards them for it.

Re:Not a troll -- Meta-Mod unfair

[azureice]

Are you kidding me? The 950 series is leaps and bounds better than previous integrated graphics solutions. Not only does it handle Vista Aero perfectly, it also does a very commendable job on games. I use it to play WoW and usually get around 20fps. Obviously it's not for any serious gaming, but for an integrated graphics chip, it's really amain.

Re:Not a troll -- Meta-Mod unfair

[Anonymous Coward]

This is a valid criticism and comment. No, it's not.

The 950 is barely passable, especially with Vista. Vista is coded by donkeys. I have an integrated Intel 945GM and I am running Beryl with full effects and it flies. Consider that this "crappy" chipset uses shared memory and also that I only have 512MB RAM, a mere 48MB of these available to the GPU, and are running a multitude of servers in the background.

What makes this possible? The superb Xorg i810 driver that was *included* in Ubuntu. If you're interested, driver and documentation available are from http://intellinuxgraphics.org/

Re:Not a troll -- Meta-Mod unfair

[Fred_A]

...must be even better if you run DOS on it.

Seriously, intel shitsets offer almost nothing. It is not just 3D that is lacking, but hardware decoding features that are perhaps more important.

But you can't expect more from $2 chip.

You've got to be kidding, my CPU peaks each time the cursor blinks !

(runs away)

'battle for control of the computing platform'

[chris_eineke]

And around the world a million tinfoil hats rejoiced.

Heavens to Betsy NO!

[jddj]

Why do I think this means more gawdawful graphic controllers and drivers from Intel? Example: The chipset can do 1600x1200, the monitor can do 1600x1200, I can even see it flash on the screen for a half-second before I'm limited to 1024x768. Example: The Java applet is on monitor 2. Click on a drop-down box: WTF? The dropdown list appears on monitor 1!!! Avoid, avoid, avoid like the plague smart people....

Re:Heavens to Betsy NO!

[Anonymous Coward]

That's a bug in Java, which hopefully has been fixed by now. I filed it back in JRE 1.4.2; I don't think they fixed it JRE 1.5.0, and now I've stopped caring about Java.

In the constructor for JFrame, if you don't pass in a GraphicsConfiguration (basically, the representation of a display), it will use the default GC (primary display) rather than the one representing the actual display which the app is running on. So even though the window shows up on the right screen, all kinds of other problems happen, like the combo box on the wrong screen, or right-click popup menus on the wrong screen, etc.

Bottom line: it's Sun's bug; or, if you want to be evil, the app vendor's problem for not working around Sun's bug by passing the right GC into the JFrame constructor. Either way, it's not Intel's fault.

Doug Carmean?

[Anonymous Coward]

Heh, he's the guy behind the Netburst ultra-deep pipelines. If you read the paper, it proposes 60-70 stages.

Itanium

[Anonymous Coward]

"Looks like computer scientists and software programmers everywhere will have to adapt to these new concepts"

Is everyone on slashdot too young to remember the Itanium?

While the changes are need, just because intel says something doesn't meen the whole industry "has" to follow. Netburst was terrible. Itanium unsuccessful. Those that adapted to those new concepts also generally adapted to failure.

Re:Itanium

[Beefslaya]

ala RAMBUS, ala Vista, ala Newton...

sense of humor?

[Anonymous Coward]

Ummm... I think it's a joke, dude.

Re:sense of humor?

[Short Circuit]

I've been humorless all week. It just kinda dried up.

(kudos to anybody who gets that one...)

when will intel figure it out....

[Anonymous Coward]

They suck so badly at making GPUs it's like watching the special olympics...

They will just not be supported...

[bky1701]

It's a bad move on intel's part. Many common programs don't even make full use of multi-core, extended instruction sets and 64-bit. If they are relying on something exotic to put them ahead... it just isn't going to work out, unless they think up a method to run un-edited code optimized for their exotic architectures.

Re:They will just not be supported...

[triffid_98]

Exactly!

Writing code that's massively parallel isn't easy, and it's never going to be easy. The right languages/tools may make it less insane, but it's asking a lot for most dev teams to put out a single-core product that doesn't need multiple patch releases. Requiring them to design and test parallel systems with N cores will be hilarious.

Many common programs don't even make full use of multi-core, extended instruction sets and 64-bit. If they are relying on something exotic to put them ahead... it just isn't going to work out, unless they think up a method to run un-edited code optimized for their exotic architectures.

Re:They will just not be supported...

[TheRaven64]

Most applications don't make use of these extensions because they only use 2-5% of a single core anyway. There is no incentive for them to run on two cores, because they don't need to. Code that uses 100% of one core, however, is generally written to take advantage of multiple cores, SSE, etc.

Intel against NVIDIA/ATI/AMD? OSS?

[WhiteWolf666]

If intel keeps supporting its equipment with excellent OSS support, I'll happily switch to an all-intel platform, even at a significant premium.

NVIDIA's Linux drivers are pretty good, but ATI/AMD's are god awful, and both NVIDIA's & AMD/ATI's are much more difficult to use than Intels.

I'd love to see an Intel GPU/CPU platform that was performance competitive with ATI/AMD or NVIDIA's offerings.

Re:Intel against NVIDIA/ATI/AMD? OSS?

[Jeff DeMaagd]

I'm skeptical. The last time I saw this much hype about Intel graphics was when they tried to make their own card in conjunction with the introduction of AGP. Regarding that first chip, I seem to recall them saying that huge on-board memory for textures was a waste of memory chips. They quickly lost that round because that was a mistaken assumption. Even their integrated chips are sub-par compared to the integrated chips of other makers.

Re:Intel against NVIDIA/ATI/AMD? OSS?

[kiddygrinder]

Very true, however my guess is that there will be some more progress on the ati linux drivers pushed by the guys at amd, just call it a hunch.

Re:Intel against NVIDIA/ATI/AMD? OSS?

[dreamchaser]

Intel has shown that it can learn from it's many mistakes though. They bet on Netburst and it was Netbust, so they went back to the P6 architecture (Core). They didn't think 64 bit on the desktop would fly, and wanted Itanic to be the one to bring it there if and when it would fly. Itanic sunk and they pulled out EMT64.

I think Intel's best bet however would be to just buy Nvidia. They have some very cool tech and it would save Intel from having to totally reinvent the wheel. Imagine a future CPU that understood Cg instructions as well as x64 instructions?

Re:Intel against NVIDIA/ATI/AMD? OSS?

[level_headed_midwest]

I use an ATi x1900GT under 64-bit Linux and it works fine for me after the one bug it had, crashing X when using XVideo, was completely fixed in 8.35.5. The card runs two 1600x1200 LCDs and it does just fine with that and it wasn't hard to set up at all. A lot of people decry the lack of AIGLX and Compiz, but since that never worked on dual-head setups with ANY GPU, it doesn't matter much to me. ATi's drivers used to be pretty poor but since the x1k series came out and forced ATi to write a driver as the Xorg "radeon" driver didn't do R500, the quality has been much improved.

Yaaaay!

[Rocky]

Easy research!

Good for linux

[cwraig]

If Intel start making graphics card with more power to compete with nvidia and ati there they will find a lot of Linux support as they are the only ones which currently have open source drivers http://intellinuxgraphics.org/ I'm all for supporting Intel move into graphics cards as long as they continue to help produce good linux drivers

News at 11:Sometimes specialized hardware is fast

[iamacat]

We have been hearing about digital convergence forever, but most people want a separate computer from cellphone or TV. Processors from Intel itself still have completely separate sets of instructions for integers and for floating point. In the same vein, even if Intel's architecture is possible, it will be less upgradable, more difficult to program for and have less backward compatibility overtime than a set of components with well defined functions.

Great expectations!

[Anonymous Coward]

"Easiest way to make sure a product doesn't meet expectations is to raise expectations."

Sex with geeks is great!

It's an old argument

[Bozdune]

Functional languages are nicely parallelizable because they don't have side effects. Unfortunately, real life is full of side effects. So, a pure functional language has to "hack" the side effect by passing it around everywhere as a closure. That gets old really, really quickly. Which is why useful functional languages contain constructs with side-effects (not without accompanying hand-wringing from purists).

Back in the 70's, people like Jack Dennis used to promise the DARPA that they could parallelize the old Fortran code used to do complex military simulations by converting the Fortran code to a pure functional language. It would be wonderful! Well, they couldn't, and it wasn't.

The above notwithstanding, IF you can coerce a problem into a form in which a functional language can be effectively employed, the benefits can be huge. The code tends to be more elegant and more readable; algorithms that would be difficult to write in an applicative language like C become easy; data structure manipulation is trivial; and so on. Arguments that functional languages are "slow" have been debunked. Arguments that functional languages must be interpreted are wrong.

And, all the syntactic nonsense of C++ and the rest of the "object oriented" languages can be (mercifully) shed. Pure functional languages are object oriented by nature. However, functional languages do have their own idiosyncracies, such as the infamous Lisp "quote", and implementation-dependent funarg problems. So there are cobwebs still.

To sum up: If you have a hard algorithmic problem to solve, a functional language will probably be a better choice, even if you end up re-coding the algorithm in an applicative language later. If you have a device driver to write, though, roll up your sleeves and get out the C manual. But first: make sure to put a debug wrapper around your mallocs (and pad your malloc blocks with patterns on both sides) so you can trap double-frees, underwrites, and overwrites. It will pay many dividends.

Not quite

[fm6]

Dude, you think C and Fortran are the main alternatives to functional languages? You're about 20 years out of date! Nowadays, the Big Thing is OOP languages. Everybody programs in C++, Java, or C# these days.

You do have a point. I wrote the Concurrency chapter in The Java Tutorial (yeah, yeah, it wasn't my idea to assign a bunch of tech writers to write what's essentially a CS textbook), struggled for 15 pages just to discuss the basics of the topic, and ran out of time to cover more than half of what I should have. Most of what I wrote was about keeping your threads consistent, statewise. All of which is irrelevant to functional programming, because functional programs don't have state! If Java were a functional language, the whole chapter would have been a paragraph. A short one.

But getting programmers to give up stateful programming is not gonna happen. Because most programmers are just not Mr. Spock enough to create whole programs that all logic and no variables. Yes, I know, functional languages have variables too. But those variables are just fancy semantic shortcuts for the lambda of whatever. To most programmers, a "variable" isn't a symbol, it's a place where you store information. Doing without all the cubbyholes of information that are used in procedural programming is just too difficult for most of us.

(Somebody's going to reply, "It's not that hard! You just..." Dude, you have the Abstract Math gene. Most of us don't. Go away.)

Also, buffer overflows and double frees are a symptom of languages where the application programmer is responsible for managing their own memory. That's the case in C++ (and yes, C and Fortran) but not in more recent languages.

Re:Not quite

[Coryoth]

You do have a point. I wrote the Concurrency chapter in The Java Tutorial, struggled for 15 pages just to discuss the basics of the topic, and ran out of time to cover more than half of what I should have. Most of what I wrote was about keeping your threads consistent, statewise. Ideally I would like to see Java take up something like this as a means to handle concurrency. It is simple, easy to understand, easy to reason about concurrent code, and doesn't require stepping very far outside standard stateful OO programming methods. Whether that will actually happen is, of course, another question, but something along those lines does offer a good way forward.

Re:Not quite

[Chandon Seldon]

Dude, you have the Abstract Math gene. Most of us don't.

An "abstract math gene" probably isn't the issue. It's just an issue of practice - most good programmers today have many years of experience working with object oriented and procedural programming languages. Functional programming is different, and it takes practice to get used to - years of practice to be as comfortable as what you're used to.

Further, a pure functional system is utterly useless since IO is a side effect. This doesn't change the fact that those areas of a program that can be written purely functionally are likely to be much easier to deal with that way - and that a lot of the other stuff that is generally associated with functional languages (i.e. closures) would be amazingly useful even in IO-heavy components.

Re:Not quite

[chudnall]

Dude, you think C and Fortran are the main alternatives to functional languages?
Dude, you have the Abstract Math gene.

Dude, you have the dude gene. Help is available. The first step is to admit you have a problem...

Re:Not quite

[fm6]

Let's get this straight: I don't have the dude gene, I have the cliche gene. Like everyone else at slashdot!

Re:Not quite

[fm6]

You remind me of the guy who tried to convince me that anybody who could drive could learn to fly. Hello! Three dimensions versus two! Absence of road signs! And where are the little dotted lines?

There's more here than "practice". I taught myself to program in language like Fortran and BASIC pretty much by reading the language manuals. In that realm, coding was just a matter of thinking of data as bits and figuring out the right way to use code to tweak the bits. Not that different from doing it yourself with a pencil and paper, just a lot faster.

OOP was a little harder, because it required more abstract thinking. I didn't really get it until I studied C++, because that language allowed me to think of an object as a kind of data structure. Which is precisely why most OOP programming is done in "mixed" languages like C++, Java, and C#, not "pure" OOP languages like Smalltalk.

With functional programming there's yet another level of abstraction, and I've studied it off and on for years. I've never achieved, never even begun to achieve, the skill level I have with procedural and OOP languages. My skill level in languages like Java and Visual Basic is not high (that's why I'm a technical writer instead of a programmer) but at least I can hack out simple utilities and examples. In functional languages, I can't even make change

Every applied science has its scientists (who dream up the basic science), engineers (who turn the abstract science into concrete technology) and mechanics (who tinker with the technology, fix stuff that's not quite working right, and deal with all the low level shit that scientists and engineers are bored by). That's kind of a simplification, especially in computer science, where most people fall into more than one category, and often all three. But in my case, I'm a mechanic, pure and simple. It's taken me a long time to learn my limitations, so don't pretend you understand them better than I do!

It's an old/new again argument

[Anonymous Coward]

"If you have a device driver to write, though, roll up your sleeves and get out the C manual. "

Or the Forth manual. There are different paradigms, e.g. data-directed programming that can simplify a particular task. A promising one is IP

Bigger not be better?

[Anonymous Coward]

There's an adage that environmentalists like to throw about:

"Trying to cure traffic congestion by adding more capacity is like trying to cure obesity by loosening your belt."

Huuu There is high parallel fortran

[aepervius]

I can remmember using it 10 years ago for application which needed a good parallelism (quantum physics) on how much processor as I wished (I went up as much as 8). Fortran for the application it is used today is highly parralelisable.

...Or will they?

[Rocketship Underpant]

I'll bet you Apple's regular upgrades to OS X will use all Intel's extensions as they come out. Core Image, Core Data, and the like will all put Intel's architecture to use, and since most apps use those frameworks, they'll also be using it.

Remember, Apple is Intel's show pony. That's why they get stuff like the 3 GHz quad-core processor first.

Re:...Or will they?

[bky1701]

And we all know that a small, (what is it, 4%?) of the computer users in the world is going to force a total adoption of that hardware. Like I said, both AMD and Intel make 64 bit and dual core, but how many programs are optimized for ether? Not many. Apple changes nothing.

And the reason they get it first is because they have a deal and Macs are a smaller target for testing and demand. Intel could easily fill much of the demand for a CPU on macs, but not so easily on PCs, so they just wait until they can fill demand, to avoid having a fissile due to lack of units.

Broadcom :P Re:yay

[NuShrike]

Oh let's not start on Broadcom and their crappy wireless chips. It's a damn crime they're pushing it on the new laptops as the "cheaper" option.

Done 30 years ago

[Anonymous Coward]

The Z80 chip did that. In fact, the only reason why that chip is still going is because you put the CPU on a breadboard, give it some ROM and RAM and poof, you're done.

Don? Don Imus, is that YOU ?

[Anonymous Coward]

You schmuck! Let's go kill muls^H^H^H^terrorists.

Not so great

[Dolda2000]

I agree that the CPU wars have gotten interesting again, but does there really need to be so much in-fighting? Does Intel truly think that AMD's new platform is so horrible that they, too, really just cannot use it? I haven't read that very much about these new architectures, but from what I have read (mostly Wikipedia), it seems that Torrenza is a pretty generic platform, with HyperTransport interconnects and everything.

Then I read that Intel is going to come up with their own, competing and completely incompatible platform. Do they really have to, or is it just a case of extreme NIH syndrome? It would be so nice if we could buy motherboards that would be compatible with both AMD and Intel CPUs, but that prospect isn't all that they seem hellbent on destroying. Doesn't this integration of GPUs into the architecture also mean that I'll have to choose between a GPU for AMD or a GPU from Intel, and won't be able to move it between AMD and Intel computers?

Sure, the CPU wars have gotten interesting, but can't they just fight over the CPUs? Do they have to fight over the platform as well?

Re:Not so great

[Short Circuit]

It's not about whether or not Intel thinks AMD's platform is awful, it's about Intel and AMD wanting to set the standard for the next-gen PC architecture.

For years, AMD was an "also available" company. Even with the start of their Athlon series, they were the second choice for PC manufacturers. When they developed and released AMD64-based processors (the first of which being the Sledgehammer and Clawhammer cores), they jumped ahead of Intel and set the standard. Intel lost out on performance markets for a long time after that.

For the past few years, AMD has been the go-to company for performance machines. With Intel's Core Duo line, Intel managed to steal back the performance crown. But the Core Duo was simply an application of AMD's performance design items to the processor line derived from the Pentium Pro. At this point, AMD and Intel are both trying to come up with the next AMD64, the next product enhancement that will blow their competition out of the water for a few years.

And when you're pumping as much money into research as Intel and AMD are, the results will be interesting and profound.

Run it in hardware

[Colin Smith]

http://en.wikipedia.org/wiki/FPGA

Every system board should have one.

Re:Sure there is: Java

[Anonymous Coward]

Ok, I can't resist...
Couldn't java make be a solution?
The JVM can hide the details of multiple CPU's. And since it knows the flow of the program, it can optimize the code automagically for the amount of processors / threads available.

http://www.cs.cmu.edu/~jch/java/speed.html/

My only problem with on-board is the SMA

[Anonymous Coward]

Make a card that uses separate memory (even if it's 32MB of fast memory for framebuffer/vertex work and shared memory for textures/etc that would be better.

Best would be the possibility of getting the chip as a separate card.

Even if in today's market it only matches a GF6300 it would be enough to play most games purchased.

Ken Kutaragi thinks Sony is the devil?

[*weasel]

it was mostly the people who thought Sony was the devil himself who hyped it up

No, mostly, it was Ken Kutaragi.

Having an extensive history of reporting on Sony, I'm sure you remember he did the exact same thing when hyping the PS2's emotion engine.