It is slow because you run the compiler for each iteration. If you precompile the code, it improves substantially (but it is still among the slowest implementations).
It's very hard, if not impossible to compile befunge efficiently to Javascript, or to anything else, really, especially when there can be self-modifying code.

http://jsperf.com/codewars-befunge-interpreter/3

BTW, my version (which wasn't included in the initial benchmark) is the fastest with Firefox, and it comes second with Chrome and Safari. w0000t :-)

EDIT3, well, I have to take back what I said in the first two edits... I wasn't re-initialising the code properly, the output of your compiler is competitive with the interpreters, but not that fast,

EDIT: ooooohhh, my bad, for the quine, the output of your compiler is 10 times faster than the fastest interpreter.

actually.

EDIT2: The same goes for the sieve of Eratosthenes, and it is competitive for the factorial and hello world test cases.

Good job!

http://jsperf.com/codewars-befunge-interpreter/4 (the Sieve example)

Thanks :-)

Actually, that's what I was doing :-).

Pointer location direction, opcode, stack and output (plus the code matrix for 'g' and 'p').

I have little time for non-necessary stuff at the moment, which explains the time it took me. But I didn't find it difficult.

Another thing: It may be nice to add a test for the random operator. Maybe compare the output of two runs of a PRNG?

The kernel may look like this:

v  <
 >1^
>? ^
 >0^

It may be useful to specify the details of the coordinate system (top left = 0, 0).

Otherwise, great kata :-)

I ranked it at 2 kyu, because I didn't find it hard to debug. It may be due to my dumb/straightforward implementation, which made it easy to output the full interpreter state for each cycle.

I've installed CoffeeScript locally (I'm doing the CS version). The current version of my interpreter outputs streams of "nul" for the quine... Fun stuff.

Actually, I found it very useful. It may find its place in the language basics section?

why do you index the third parameter of the callback (arr) rather than logins ?