I've read your other mail.
Eliot Miranda writes:
On Mon, Feb 23, 2009 at 1:49 PM, bryce@kampjes.demon.co.uk wrote:
What are the inefficiences in Exupery's call return sequences?
Exupery uses a C call sequence so it's easy to enter from the interpreter,
that's a non sequitur. The Cog VM has full interoperability between interpreter and machine code without a C calling convention. The interpreter doesn't call machine code methods, instead it calls a trampoline that jumps to the right point in a machine code method, allowing the system to optimize the common case of machine-code to machine-code calls (through inline caches). The return address of a machine-code frame above an interpreter frame is that of a routine that does a return to the interpreter so that returns don't have to check for returning to the interpreter.
that C call frame is torn down when exiting each compiled method then re-created when reentering native code. That's a complete waste when going from one native method to another.
So you go to all the effort of producing native code and then you wrap it in so much gunk that you get minimal performance benefit from it. I don't understand. What are your goals? Experimenting with compilers or producing an efficient Squeak VM?
My goal is an efficient Squeak VM. Exupery's current send performance is about twice the interpreters, just above twice on Athlons, just below twice on the Core 2. This was achieved primarily by using PICs. Once send performance was twice the interpreters other issues became more pressing including reliability and compile speed. More call sequence optimisation is planned but is unlikely to be next.
If Cog's successful then it may make sense for Exupery to use the same calling conventions as Cog so Cog->Exupery->Cog calls are zero cost. Exupery is built to perform heavy optimisation on inlined code, inlining is also needed to expose entire loops for further optimisation.
Bryce