partcl accelerator
Will Coleda
bytecode, I'm seeing the following timings with "hello.tcl" in
partcl's examples:
CokeZero:~/research/parrot/languages/tcl/examples wcoleda$
time ../..//../parrot ../tcl.pbc hello.tcl
Hello World
real 0m0.313s
user 0m0.187s
sys 0m0.057s
CokeZero:~/research/parrot/languages/tcl/examples wcoleda$
time ../..//../parrot ../tcl.pbc hello.tcl
Hello World
real 0m0.315s
user 0m0.189s
sys 0m0.061s
CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time tclsh
hello.tcl
Hello World
real 0m0.325s
user 0m0.035s
sys 0m0.032s
Yes, it's actually *faster* than real tclsh. This cannot be right
(Actually, given the incredible amount of cheating partcl must be
doing, only going this much faster is disappointing. =-) Let's try
again.
CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time tclsh
hello.tcl
Hello World
real 0m0.069s
user 0m0.035s
sys 0m0.023s
Ah, there we go. partcl is back down to about 4.5 times slower.
Running a trace, I see the top two opcodes are:
Code J Name Calls Total/s Avg/ms
177 - compile_p_p_s 2 0.088355 44.177380
537 - load_bytecode_sc 6 0.034809 5.801486
Which combined only make up .122s - not enough to get us back down to
even, but it's a start. There are no compile opcodes in the path for
"hello.tcl", so this has to be coming in through something we're
loading:
load_bytecode "library/Data/Escape.pbc"
load_bytecode "library/PGE.pbc"
load_bytecode "library/PGE/Glob.pbc"
Can any of these stdlib items be optimized so they load faster?
Anything they're doing at load time that could have been done at
compile time instead - like the hash init in PGE::EXP && P6Rule, or
the rule compilation in PGE::Rule.
As for the load_bytecode, I followed the code from the opcode back
into src/embed.c, where it calls (eventually) Parrot_readbc - which
appears to read the files via fread(). Can we can changed this to
something that mmaps instead? (I wonder how much time is spent
setting up the initial load of tcl.pbc - that's not done via an
opcode, so that time isn't reported via -p, is it?)
Regards.
Patrick R. Michaud
> Ah, there we go. partcl is back down to about 4.5 times slower.
> Running a trace, I see the top two opcodes are:
>
> Code J Name Calls Total/s Avg/ms
> 177 - compile_p_p_s 2 0.088355 44.177380
> 537 - load_bytecode_sc 6 0.034809 5.801486
>
> Which combined only make up .122s - not enough to get us back down to
> even, but it's a start. There are no compile opcodes in the path for
> "hello.tcl", so this has to be coming in through something we're
> loading:
>
> load_bytecode "library/Data/Escape.pbc"
> load_bytecode "library/PGE.pbc"
> load_bytecode "library/PGE/Glob.pbc"
The only compile opcodes that are executed by PGE are when a rule
is compiled (to convert from PIR source to a subroutine PMC).
If partcl or hello.tcl is using PGE at all, then there will be at
least one compile for each rule it uses. (Perhaps there aren't
any.)
> Can any of these stdlib items be optimized so they load faster?
> Anything they're doing at load time that could have been done at
> compile time instead - like the hash init in PGE::EXP && P6Rule, or
> the rule compilation in PGE::Rule.
Well, for this I need more details about the load/compile process
that Parrot uses when creating a .pbc file. In particular, given
that the PGE.pbc file is created by doing
parrot -o PGE.pbc --output-pbc PGE.pir
is the @LOAD subroutine in PGE.pir executed when parrot compiles it
or when PGE.pbc is loaded? (I suspect the latter.)
More generally, how does one save precompiled tables into a .pbc
file...? I haven't seen quite how to do this yet...
Pm
Leopold Toetsch
> On Wed, Jul 13, 2005 at 12:29:29AM -0400, Will Coleda wrote:
>
>>Ah, there we go. partcl is back down to about 4.5 times slower.
>>Running a trace, I see the top two opcodes are:
>>
>> Code J Name Calls Total/s Avg/ms
>> 177 - compile_p_p_s 2 0.088355 44.177380
>> 537 - load_bytecode_sc 6 0.034809 5.801486
Well, I would currently not worry about interpreter (+PGE) startup time
for a 'hello world'ish program, but anyway ...
> ... In particular, given
> that the PGE.pbc file is created by doing
>
> parrot -o PGE.pbc --output-pbc PGE.pir
>
> is the @LOAD subroutine in PGE.pir executed when parrot compiles it
> or when PGE.pbc is loaded? (I suspect the latter.)
At load time, i.e. when you run "load_bytecode 'PGE.pbc'".
> More generally, how does one save precompiled tables into a .pbc
> file...? I haven't seen quite how to do this yet...
There is no interface (from PIR) yet. But I'm pondering since quite a
time a "PackFile" PMC, with some methods for manipulating PBCs,
including "write" to be able to create pre-compiled code.
> Pm
leo