Slashdot Mirror

You should really read the Open Source Definition if that is what you're implying.

Perhaps I should be clearer. My problem with equating open source with free software is that the words "open source," on their face, do not disclose anything about the underlying intellectual property. When I hear open source, I think of a developer allowing customers and competitors to see what's "under the hood." Customers are able to evaluate the vendor's products at a much more intimate level. Researchers can test and develop the ideas embedded inside the code. I can hardly blame a software company for using a different definition of "open source" than the one proposed at opensource.org; it's not dishonest - just an honest difference in opinion about what the term means.

I also want to emphasize that the need for the "non-free, open source" distinction is meaningful on a practical level. Let me give a concrete example. I once applied (unsuccessfully) to a company called RapidMind that produces middleware for multiprocessing systems. The company came out of the University of Waterloo. In order to attract the best and brightest, the computer science faculty at Waterloo allows its professors to keep intellectual property on their research. RapidMind in turn has an interest in keeping its source code open to the academic community, and its library is freely available online.

But it's not just the acadamians who benefit from the open distribution. Developers who want to experiment with the library are free to do so before they decide whether or not to purchase licensing rights. The economy at large benefits from being able to freely experiment with the library, and RapidMind gets wider recognition and the wider range of customers that comes with it.

Note that RapidMind still gets to hold on to its IP in this model.

The words "open source" intuitively mean the open distribution of source code. It's a fully-formed idea that stands on its own merits. The open distribution of intellectual property is a separate idea; it is a different solution to a different problem, and I submit that it needs a separate name.

There have been some attempts to streamline the process you describe already (libraries that involve small changes to existing code)
http://en.wikipedia.org/wiki/OpenMP
http://en.wikipedia.org/wiki/Message_Passing_Inter face
http://www.rapidmind.net/

The Rapidmind project showed some great benchmark results using the Cell.

What's really missing are better libraries and compilers.


Look here:

http://www.rapidmind.net/

These people are doing some very nice things with parallel compilers. Write once, run on Sony's core, GPGPU, or a traditional multicore x86. They are just now coming out of stealth mode. The compilers are free; rather they license based on deployment. The license charges are quite modest for deploying a few solutions ($1K for one deployment... scales down from there).

Joe.

Good morning slashdot!

As the (slightly terrified to find himself mentioned on slashdot) presenter in the video linked to above I thought I'd respond to a couple of comments in bulk. First off, I'm part of a much bigger team at RapidMind that builds this software to make targeting multicore and stream processors easier -- the system and the "chicken demo" was a group effort, and you can read more about it and the company in general in the article linked to from here, which unfortunately is PDF-only.

For those crying out about multi-threading not being the solution: you're absolutely right! Our platform's approach to programming multi-core processors is to expose a data parallel model. In this model, the programmer explicitly deals with parallel programming (writing algorithms to work well on arbitrarily many cores) but all of the standard multi-threading issues such as deadlocks and race conditions are avoided, and the developer doesn't worry about how many cores there actually are.

And no, the chicken demo didn't run each chicken on an individual core ;). But it did automatically scale to however many cores were available -- 6 SPUs and a PPU on the PS3, and 16 SPUs and 2 PPUs on a Cell Blade (on which we originally showed the simulation at GDC 2006).

If you want to learn more, drop by our website at http://www.rapidmind.net. You can sign up for a free no-strings-attached evaluation version if you want to try it yourself.

Good morning slashdot!

As the (slightly terrified to find himself mentioned on slashdot) presenter in the video linked to above I thought I'd respond to a couple of comments in bulk. First off, I'm part of a much bigger team at RapidMind that builds this software to make targeting multicore and stream processors easier -- the system and the "chicken demo" was a group effort, and you can read more about it and the company in general in the article linked to from here, which unfortunately is PDF-only.

For those crying out about multi-threading not being the solution: you're absolutely right! Our platform's approach to programming multi-core processors is to expose a data parallel model. In this model, the programmer explicitly deals with parallel programming (writing algorithms to work well on arbitrarily many cores) but all of the standard multi-threading issues such as deadlocks and race conditions are avoided, and the developer doesn't worry about how many cores there actually are.

And no, the chicken demo didn't run each chicken on an individual core ;). But it did automatically scale to however many cores were available -- 6 SPUs and a PPU on the PS3, and 16 SPUs and 2 PPUs on a Cell Blade (on which we originally showed the simulation at GDC 2006).

If you want to learn more, drop by our website at http://www.rapidmind.net. You can sign up for a free no-strings-attached evaluation version if you want to try it yourself.

From the site:

• 1. Replace types: The developer replaces numerical types representing floating point numbers and integers with the equivalent RapidMind platform types.
• 2. Capture computations: While the user's application is running, sequences of numerical operations invoked by the user's application can be captured, recorded, and dynamically compiled to a program object by the RapidMind platform.
• 3. Stream execution: The RapidMind platform runtime is used for managed parallel execution of program objects on the target hardware platform, which can be a GPU, the Cell processor, or a multicore CPU.

Man thats some funny stuff. Wow that cracked me up. A *games* company using a tool that has this level of indirection?!? I sure hope these guys got a lot of money from their sucker VC to roll in.

Look guys. There is no multi-processing silver bullet. It isn't even such a hard problem, *if you stop trying to solve it at such a low level*. Break your application into separate pieces that, *don't need to communicate very often.* Then this is the same kind of problem scalable websites like Google, MySpace, Hotmail and so on, have already, just without having to factor in the reliability issues. Finer grained multi-threading just leads to deadlocks and is really hard to debug. If you *really must* render the same sphere on 100 processors at the same time, then you need the speed of a custom coded solution. But you don't so let it go. The main loop of your program will be just fine as a single threaded implementation, 1 processor will do, and farm the 10% code / 90 % heavy lifting out in big clean chunks to other processors. If you find yourself writing some bizzare multi-threaded message passing system so that you can have 100s of threads all modifying the same live object model at the same time -- you are fucked, just forget about it 'cause you will never be able to debug that one killer bug that you know is going to get you right as you go to ship.

This looks similar to RapidMind, which is a software development platform that, among other things, "Enables applications to run in a data-parallel way." (I'm not affiliated with them.)

unless you use a decent compiler that actually works with almost standard C++:
http://www.rapidmind.net/technology.php

RapidMind has been designed to do what you speak of.
You can write on multicore processors using C and specialised libraries that were designed for multicores.
Its a pretty neat and should make multi-core development easier.

Theres some videos on their website of some pretty interesting things they done using Cell.
http://www.rapidmind.net/samples.php/
(note: these programs were done in as little as 3 weeks)
Some on Spectrum at IEEE http://www.spectrum.ieee.org/jan07/4837/1

According to some artices i read (hell knows what the links were again), it will be available for PS3, actually running under YDL.
Not sure if it is true, but it will be added to the devkits, it was meant to be added before release, but they decided to spend more time on it (possibly to their disadvantage with some developers being "left on their own"...pfft lazy if you ask me, not true programmers in my eyes! A true programmer would strive to get code working on anything!)

I think the decision to use an asymmetric CPU by Sony was a wrong one.

This is just my perception/opinion, but it sounds more like Carmac is getting old and lazy than any fundamental flaw with Sony's choice in processor. What we need is a new generation of developers to embrace the domain of parallel processing so that it can begin to realize its potential. I'm tired of the foot dragging and bellyaching about how different/difficult it is to multithread. Companies such as the previously mentioned RapidMind and PeakStream have made significant advancements in making multithreading more accessible, and if developers would put more effort into thinking in parallel rather than complaining about a changing environment, we'd be a lot farther along than we are now.

Someone has seen the light.