Item — HN Reader

I agree - same reason Rubinius will probably be the future of Ruby.

Smalltalk has been around forever and one of Smalltalk's strengths is that most of the implementation is in Smalltalk itself.

When I first got into Ruby I kept the implementation handy and a Textmate project set up for all installed Ruby gems to make it easy to read through the code. Rubinius makes it easier to read the implementation code. I installed Rubinius using an OS X installer, but then went back and installed the source code.

1 comments

>Smalltalk has been around forever and one of Smalltalk's strengths is that most of the implementation is in Smalltalk itself.

I think LISP is a good thing to look at as well. Even though it's not that efficient to write the implementation of LISP in LISP, it's practically possible with 37 operators. There has to be something with these languages where you can write the language in itself.

To be completely honest, I'm somewhat astonished that speed is one of the reasons to write the core in itself: Usually you would think it would be a reason to write it in a low level language.

> To be completely honest, I'm somewhat astonished that speed is one of the reasons to write the core in itself: Usually you would think it would be a reason to write it in a low level language.

Can anyone elaborate on this?

A good optimizing compiler almost always beats hand coded assembly language. It is difficult for a programmer to keep track of what is going on in his code: instruction timing, register allocation and locking, pipelined multiple instruction execution, instruction optimization, global optimization, on and on. JIT can do even better.

I've done hand optimization of RISC assembly. It's fun, but nowhere near as productive as productive as coding in Python, or C for that matter.

Modern processors may be to blame for that. Out of order execution, register renaming and speculative execution are very hard to wrap your head around.

That's what I liked about the 6502 - very simple, very direct and somewhat RISC-ish. Not many ways to do something. It is said the ARM was very 6502 influenced, but I never worked with it on a low level.

The other thing I liked about the 6502 was that I was flying under the OS all the time on those machines. Dealing with the OS at the machine-language-level is usually painful.

I think you are overestimating the current capabilities of JIT's.

Also, unfortunately, current compilers are notoriously bad at generating code with special instructions (vectorized code).

So in the end applications that need to be really fast end up being written in assembly, or carefully written fortran and C code to generate a particular assembly.

>Also, unfortunately, current compilers are notoriously bad at generating code with special instructions (vectorized code).

Sounds like the downfall of the Itanium. They promised that the compilers would make it all usable, but the compilers never showed up.

Clever beats just fast? I think the idea behind PyPy is that the high-level language is more flexible, and allows trying many different approaches, rather than heavily optimizing one or two possibly sub-optimal approaches in a low-level language.

Also, if you write the core in the language itself, when you improve your optimizations, you speed the core up too.

Last I heard, there were some quirks in matching the memory model between C and Python which caused excessive paging (?) that PyPy can avoid. Can't find the reference, but maybe it's a clue to help you look.

I think the speedup is mainly because of the JIT compiler. Is there any benchmark against cPython with Psyco?

speed.pypy.org gives a timeout for me