Ruby for HPC?

[xman]

Just a humble post for your leisure read. Mark your calendar now. Let's see if Ruby gets into the HPC community in two years time. :) Why two years? After two years, the computation power of a single processor unit would have doubled up. The software efficiency would be halved after two years. If we can increase the productivity by 2x with the use of Ruby, perhaps we can buy more time for software optimization to rectify the software efficiency.

http://blog.speedgocomputing.com/2011/04/first-release-of-sgc-ruby-cuda.html

[hyqneuron]

HPC? Ruby? Are you sure this is a good match given that plenty of
algorithms take months or even years to run?

I'm very curious. How do you deal with the kernel code? Do you
translate Ruby into CUDA C first, then invoke the NVIDIA compiler to
make a cubin and use driver API to load and call that kernel from
within the Ruby code? If this is the case I see no reason why Ruby
couldn't be used here.

As for CPU-side computation, I really doubt that Ruby is going to come
up as a good candidate for HPC in any time soon. After all, its design
philosophy, in the first place, does not look like a good one for HPC.
HPC, as its name suggests, is really about performance, isn't it?

As for the human side of programming, I actually find C# to be the
most elegant. (I joined this group because it has CUDA in its title
and looks like it's set up by someone in Singapore :D)

> http://blog.speedgocomputing.com/2011/04/first-release-of-sgc-ruby-cu...

[xman]

HPC? Ruby? Are you sure this is a good match given that plenty of
algorithms take months or even years to run?

Whether you like it, dynamic programming languges are getting much more adoptions nowadays. The quest I'm after is more about I use Ruby, and can I use it for HPC as well? How far can I go with that?

If not, do you continue with C/C++ programming?

 

I'm very curious. How do you deal with the kernel code? Do you
translate Ruby into CUDA C first, then invoke the NVIDIA compiler to
make a cubin and use driver API to load and call that kernel from
within the Ruby code? If this is the case I see no reason why Ruby
couldn't be used here.

The kernel code is still in CUDA C for the time being. But there is no reason why you couldn't invent another embedded language that's much easier to program with.

 

As for CPU-side computation, I really doubt that Ruby is going to come
up as a good candidate for HPC in any time soon. After all, its design
philosophy, in the first place, does not look like a good one for HPC.
HPC, as its name suggests, is really about performance, isn't it?

Performance is definite. Yet productivity is critical too. That's why people going after python, Ruby nowadays.

Do you use Java? It has been thought as slow performer, yet Java is ruling the world now for some reasons other than pure performance.

 

As for the human side of programming, I actually find C# to be the
most elegant. (I joined this group because it has CUDA in its title
and looks like it's set up by someone in Singapore :D)

Perhaps you can try the CUDA.NET which allows you to write kernel functions in C#.

[hyqneuron]

> Do you use Java? It has been thought as slow performer, yet Java is ruling
> the world now for some reasons other than pure performance.

I'd think portability is the best thing with Java. Same goes for
Python. Of course, this is subjective.

> Perhaps you can try the CUDA.NET which allows you to write kernel functions
> in C#.

I'm tired with the optimization of ptxas. I guess I'll finish my Fermi
assembler first before I deal with the high-level things.

I downloaded CUDA.NET and took a brief look at its documentation. It
doesn't seem to allow me to write kernels in C#. Thanks for the
inspiration, though. I'm now thinking of something like Fermi C#
(maybe a compiler to generate more readable code that has good 1-to-1
correspondence with native opcode).

[xman]

I'd think portability is the best thing with Java. Same goes for
Python. Of course, this is subjective.

Java was favored for its portability. But Ruby and Python are favored for productivity. If you look at the themes of people introducing these two programming languages, simple to use is #1, portability is secondary. I agree that this is subjective.

Google is one of the heavy Python users, and Apple uses Ruby.

 

> Perhaps you can try the CUDA.NET which allows you to write kernel functions
> in C#.

I'm tired with the optimization of ptxas. I guess I'll finish my Fermi
assembler first before I deal with the high-level things.

I downloaded CUDA.NET and took a brief look at its documentation. It
doesn't seem to allow me to write kernels in C#. Thanks for the
inspiration, though. I'm now thinking of something like Fermi C#
(maybe a compiler to generate more readable code that has good 1-to-1
correspondence with native opcode).

Possibly I was confused with this GPU.NET http://www.tidepowerd.com/product/howitworks

At least from the description, you can write the kernel in C# with this.

The Fermi would have a lifespan of a few years I guess. So if you are really doing it low level, you got to do it fast to benefit from it. GPU architecture changes very quickly, after that, you'll need major rework.

[hyqneuron]

> The Fermi would have a lifespan of a few years I guess. So if you are really
> doing it low level, you got to do it fast to benefit from it. GPU
> architecture changes very quickly, after that, you'll need major rework.

That's true. Looks like Kepler is coming in just a few months (maybe
the next month). Though I guess the ISA will remain the same, or at
least extremely similar. The next big change would be Maxwell, which
will be in 2013. I'll just do the assembler in a extensible way to
ensure it doesn't take much extra work to support a different ISA.