The performace of the 1.0.1 version has dropped by about 98% compared
to version 0.0.6 in wheezy. It now runs far slower than a naïve
implementation such as the 22 line 'microbf' program and clocks in
at around 20000 times slower than the fastest implementations.
The 0.0.6 version was already one of the slower C based interpreters
around but the version 1.0.1 performance is well below the norm and
in the range normally occupied by interpreters written in intepreted
languages.
There is obviously a serious problem here.
$ echo 255 | time beef bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real 17m 16.24s
user 17m 15.87s
sys 0m 0.00s
$ echo 255 | time bf.bin/microbf bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real 0m 50.31s
user 0m 50.29s
sys 0m 0.00s
$ echo 255 | time ~/beef-0.6 bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real 0m 26.69s
user 0m 26.68s
sys 0m 0.00s
$ echo 255 | time bf.bin/deadbeef bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real 0m 11.30s
user 0m 11.29s
sys 0m 0.00s
$ echo 255 | time bf.bin/bfi bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real 0m 0.04s
user 0m 0.04s
sys 0m 0.00s
$
Microbf.c ...
#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
int main (int argc, char *argv[]) {
char *b=0, *p, t[65536]={0};
unsigned short m=0;
int i=0;
FILE *fp=argc>1?fopen(argv[1], "r"):stdin;
size_t r=0;
if(!fp || getdelim(&b,&r,argc>1?'\0':'!',fp)<0)
perror(argv[1]);
else if(b&&r>0)for(p=b;*p;p++)switch(*p) {
case '>': m++;break;
case '<': m--;break;
case '+': t[m]++;break;
case '-': t[m]--;break;
case '.': putchar(t[m]);break;
case ',': {int c=getchar();if(c!=EOF)t[m]=c;}break;
case '[': if(t[m]==0)while((i+=(*p=='[')-(*p==']'))&&p[1])p++;break;
case ']': if(t[m]!=0)while((i+=(*p==']')-(*p=='['))&&p>b)p--;break;
}
return 0;
}
Beef's focus is on flexibilty rather than performance: as you noticed, previous versions were not among the fastest Brainfuck interpreters either. The latest version is a complete rewrite on top of Cattle, a GObject-based library, which of course introduces some overhead. That said, I agree with you that performance is not as good as it could, and should, be. In fact, now that the rewrite is complete, my main focus will be making it faster, but of course that will have to wait until jessie+1. Thank you for your interest in Beef. Have a nice day.
Then perhaps you should document where it's a flexible interpreter because at the moment I'm not seeing anything. I suppose I might look for, at first, things like changing the cell size at run time: 8/16/32 bits, maybe 64, 128 or unlimited bits, maybe ONE bit for 'boolfuck'. That could lead onto variations in the front end processing; perhaps a macro language, perhaps variant syntaxes like "Ook", "Blub" and "fuckfuck". Other things could include variations on the I/O, reading from a string (Looks like you have the ability to 'fdreopen' the standard in from a file, though I'm not sure why, after all shell redirection works fine and is well known) mixing reading the program and data from the stdin, either in the traditional compile style (with a "!", but obviously that's a comment character so it should be possible to disable it) or the scrablmed 'easy' style. You have EOF processing, but you missed the 'abort on EOF' variation. Things that can apply to both I/O might include ASCII vs Binary and Unicode vs Decimal, perhaps the EsoAPI you have a wishlist for. In the middle you can have optimisations, there's the short list of 'brainfuck' optimisations: RLE, SetZero, RailRunners, RailCleaners, CopyLoops, "Simple" (what I would call MaAd) loops and so forth. Then there's the more traditional optimisations starting with constant folding. Next there's how you run it, obviously a plain interpreter is one option. Then there are lots of languages you could convert it to ... Assembler, B, C, D, E, F#, Go, Haskell ... Perl, php, Python ... Ruby, Scheme, TCL ... Lua, Ksh, Julia ... fuckfuck ... that list is endless. Other features might relate to debugging, breakpoints, tracing, profiling, conditional breakpoints and more. Finally, there are language variations, extra commands, Forks, Files, Functions, Math and Boolean operations, Stack support, Clocks, timers and events ... this list is also endless. Some of these will be slow, or really slow, but BF is such a small language that nothing stops you including multiple interpreters; one with every bell an whistle you can think of and other smaller, much faster ones. I look forward to your next version, but, seriously, this version should be withdrawn until it's performance is better. I'd accept "sort of okay", after all it'd be a lot better than now. How about a little starter ... with the rather appropriate/inappropriate name of 'deadbeef' https://gist.github.com/rdebath/a12653a3c167cf93ab6a
It certainly is, and I'm not interested in implementing all of these suggestions. Some look very promising though, so I'll definitely try to integrate them in Cattle. I'm sorry Beef doesn't fit your use case anymore. That said, at this point in the release schedule there's not much I can do about it. That looks great! Why don't you get it packaged? Cheers.