For x86, you can also combine different runcores. If you try -Cj it
might run even faster. What type of program were you running to get
that slowdown? When I got the amd64 jit to the bare bones state, I got
a 10% increase in speed. If Lua's parrot implementation allows you to
turn the source program into a pbc, running that should help give you a
sizable increase in speed. Also, for some programs, keeping gc on can
be much faster. The --no-gc is to deal with(hopefully fixed) bugs in
parrot. I imagine the pbc option will provide the best increase in
speed.
On Sep 20, 2007, at 1:32 PM, chromatic wrote:
On Thursday 20 September 2007 11:20:45 François PERRAD wrote:
Umm, before I make a fool of myself over there ... I've tested
this with a few benchmarks. So, maybe I'm missing something
essential, but why does --jit-core *slow down* things (5%-10%
slower than --computed-goto-core)?
JIT's much better for long-running processes. The last time I
profiled a test
with JIT, the process spent most of its time *generating* the JIT
code. The
result ran faster than even the CGP code, but the process didn't run
the
JITted code long enough to overcome the cost of JITting.
And even if it's only interpreted, 20x-33x *slower* than the Lua
interpreter seems a bit hefty. And comparing (supposedly) JIT
compilers, it's 50x-200x slower than LuaJIT 1.1.
Do I need to disable some debug stuff? I just followed the
standard build instructions ...
Parrot has some known (unenabled) optimizations, and we haven't really
focused
on optimizations much yet, as we're still adding features.
I have a couple of Parrot Lua failures that I hope François can
resolve, but
I'm happy to do some optimization work where appropriate.
-- c
