some befunge love

i took some time to review my befunge modules. trying to speed up things is always fun, so thanks to devel::nytprof, i saw that i was spending quite some time on my debug statements.

it should be noted that those statements were method calls on the main language::befunge::interpreter object. and the method then was outputing things depending on the value of a debug attribute of the interpreter. the interpreter was not used outside of this.

knowing that method calls are expensive (since perl doesn't know until run-time where to find the method), i therefore created a language::befunge::debug module that exports a debug() sub. 2 other subs are provided (but not exported) to turn on/off the debug. (there's a trick here, that i will explain in another post).

net result? around 20% speedup (a bit more in fact). not bad for one hour spent on the subject. :-)

other than that, language::befunge tests got sanitized (using test::more, test::output and test::exception everywhere instead of crafting stuff by hand). part of this code was not touched since 2002...

finally, language::befunge got some new extensions, still passing all mycology tests. you can now enjoy the following in jqbef98:

• CPLI - complex numbers extension
• DIRF - directory operations
• FILE - file i/o operations
• FIXP - fixed point operations
• STRN - string operations
• SUBR - subroutines extension
• TIME - date/time operations

some of them were pretty difficult to get right, if you forget some befunge basis (note to self: the storage offset is here for a reason, dammit!).

which leaded me to update language::befunge::debugger to load mycology correctly, with a new option to run without delay till the next breakpoint. using it, things were easier to get right. still not perfect, but already more than usable...

so, enjoy language::befunge 4.11 and language::befunge::debugger 0.3.6, now available on cpan!

how to shave 10% speed?

contributing to other projects is good (not counting the fact that it's fun):

• you help open-source as a whole
  
• you gain some knowledge on the projects you help
• ... and you discover some new stuff, techniques, tricks

so recently i've been helping the padre team, where i discovered the module class::xsaccessor. reading the pod, it seemed quite good, but the question was: is it really that interesting?

so, i decided to try that on language::befunge, which currently uses a mix of class::accessor::fast and hand-crafted accessors (man, some part of the code is untouched since 2002!). who recalls of using the following in his/her code:

BEGIN {
my @attrs = qw{ attr1 attr2 attr3 };
foreach my $attr ( @attrs ) {
    my $code = qq[ sub get_$attr { return \$_[0]->{$attr} } ];
    $code .= qq[ sub set_$attr { \$_[0]->{$attr} = \$_[1] } ];
    eval $code;
}
}

anyway, i created a new git branch in langage::befunge's repository, and ported all my classes to use class::xsaccessor. and then i've run both the module's test suite and mycology:

• current language::befunge: tests = 5.28s, mycology = 20.48s
• using class::xsaccessor: tests = 5.12s, mycology = 18.18s
  

(everything ran once to warm cache, and then averaging three passes. all output directed to /dev/null in order not to pollute cpu measures with io)

that is, around 5% saved (a bit less) for the tests, but 10% (a bit more) for mycology. knowing that the tests are not representative of real befunge workload, this means a 10% speedup in befunge programs... neat!

needless to say that i merged this temp branch (ain't git cool?) to master, and language::befunge 4.09 is on its way to cpan!

conclusion: use class::xsaccessor, it fulfils its promises... and contribute to other projects, at least you'll find some ideas for your own projects!

befunge on parrot fix for "sgml spaces" error in mycology

my bad - mycology was right, i was wrong. when spotting an error in my befunge interpreters, i should trust matti and look in my code. :-)

the sgml spaces mycology error mentioned previously came from the instruction ` which is greater than, not greater than or equal.

so i fixed it, and befunge on parrot now passes completely the befunge 93 mycology tests.

befunge on parrot interpreter now working (again)

it all started with a discussion on #parrot:

Dec 28 19:17:27 <kj> don't think zcode is still being maintained
Dec 28 19:19:16 <rurban> Looks like so, yes.
Dec 28 19:19:27 <rurban> befunge being the worst.

(funny thing is that i wasn't even here at that time, cognominal reported it to me later on)

as befunge on parrot author, it hurted my pride. i could stand that befunge wasn't the best parrot language implemented, but being the worst... i had to do something!

so, after some time to compile parrot (didn't did that for 3 years, it's now way easier!), getting up to speed to groak parrot error messages, i started porting befunge on recent parrot.

i took the opportunity to move from pasm to pir, using neat addons such as subs (even with parameters and return values!), named vars, random pmc (instead of pseudo random stuff using mod and chicken sacrifying) and other welcome stuff that were not available in 2002 when i first implemented befunge on parrot.

the result is a working befunge-93 implementation on top of parrot, and befunge now passes its tests:

$ make test
../../parrot -o befunge.pbc befunge.pir
cd .. && /usr/bin/perl5.10.0 t/harness --languages=befunge
befunge/t/basic....ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.06 cusr + 0.01 csys = 0.07 CPU)

i also checked this implementation with mycology, and it seems to work:

• plain mycology: reports a failure on sgml-mode, but that's a bug in mycology
  
• mycouser: success, before jumping to befunge-98 library semantics, where it fails (of course)
  
• mycorand: success
  

so, all in all, befunge on parrot is once again alive and kicking!