Open rdebath opened 8 years ago
Fair enough! I just didn't search long enough.
LLVM is just one of standard backends for the interpreter itself, there's no JIT or machine code generation involved anywhere.
Okay, so it's sort of dependency only not is a Debian packaging problem; okay.
Anyway, I've finally worked out what's wrong with your interpreter and got it to run most of the tests; here's the interpreters I've found that are faster.
I'm not sure how applicable the techniques used will be to Haskel as I usually don't look too closely at it. BTW: You need to fix this line:
. B.filter (P.inClass "+-<>,.[]")
I did test bff.c and bff4.c from http://mazonka.com/brainf/ with mandelbrot.bf and they both were slower than my interpreter (3,5 sec vs. 4,8 sec for bff.c and bff4.c both). Could you maybe tell me your times for these?
I basically only tested with mandelbrot, and omitted some optimizations that made mandelbrot slower but could have potentially benefited other programs.
The line with B.filter
is not relevant to interpreter performance, since it's in the parser.
Sorry, you're quite right, I didn't get the program to sort the table and didn't get it quite right. This looks closer, it's still six of them, but it's a shame you can't see the colours.
<table style="font-family:sans-serif;font-size:10pt;border-collapse:collapse;" bgcolor=white border=1px solid #000 >
Thanks, your table is quite amazing, and it's very helpful to have all test programs and interpreters in one place. Maybe later I'll benchmark more of your test programs and try to do other optimizations as well.
For mandelbrot and turning off the JIT mine runs about double the speed. But you seem to be using llvm which would mean turning off JIT is a bit unfair.
For Urban Muller's 'prime.b' program I seem to be managing about 40 times your speed ... without JIT.
It's taking a while to run all the tests...