Comments for Byteworm

Comment on About by hack2root

hack2root — Tue, 04 Oct 2011 06:50:32 +0000

Reccurent imaging! Can I be the next (not the last)?

Comment on The Fastest VM Bytecode Interpreter by undef

undef — Fri, 26 Nov 2010 10:50:00 +0000

hahaha, interesting article

Comment on The Fastest VM Bytecode Interpreter by snify

snify — Wed, 24 Nov 2010 18:09:36 +0000

I’ve written a similar thing, but the opcode generation was more generic using an assembler. Nice source anyway.

Comment on The Fastest VM Bytecode Interpreter by Bored

Bored — Wed, 24 Nov 2010 01:51:00 +0000

I got bored and decided to see if, by your logic, C was faster than Assembly too!

Here is my implementation of your VM.
http://benchmarks.are.stupid.at.pastebin.com/G7amhdt8

Basically, it build a C file, calls gcc, and runs the executable.

$ time ./bench # original benchmark code
857419840

real 0m0.396s
user 0m0.390s
sys 0m0.003s

$ time ./simvm # your asm version
857419840

real 0m0.759s
user 0m0.760s
sys 0m0.000s

$ time ./rofl_vm # my version
857419840

real 0m0.208s
user 0m0.143s
sys 0m0.033s

C IS FASTER THAN ASSEMBLY!

Note: simvm and simvm were built using -O4 and bench was built with -O0

I would have tested the VB version but mono kept crashing on CreateDelegate.

P.S. I agree with your point, I just wanted to post that for comedic effect.

Comment on The Fastest VM Bytecode Interpreter by A.T.

A.T. — Tue, 23 Nov 2010 09:22:44 +0000

love that assumption “world is 99% built on x86″, caused mainly by illiteracy about any other platforms or refuse to admit that all their *elegance* will go down pipes once assumption is removed… :)))

Comment on The Fastest VM Bytecode Interpreter by Bill

Bill — Tue, 23 Nov 2010 05:33:05 +0000

In simvm-slow.c, what’s the rationale for using:

#define NEXT() __asm__(“jmp *%0″::”r”((++ip)->jmp)); goto *ip->jmp

instead of

#define NEXT() goto *(++ip)->jmp

Comment on The Fastest VM Bytecode Interpreter by Duran

Duran — Mon, 22 Nov 2010 10:41:52 +0000

Technically, when you turn source code into a parse tree (or other internal representation) it’s no longer a pure interpreter.

If that’s too technical, how about this: Compiling to bytecode is still compiling, because the only difference between bytecode and machine code is whether there is a (possibly microcoded) hardware implementation.

Comment on The Fastest VM Bytecode Interpreter by Bruno

Bruno — Mon, 22 Nov 2010 10:40:51 +0000

Of course it does. JIT compilation is not a 0-time expenditure. However, if you make a very slight change (already rocking that the change is so slight) and export a .exe file…then compare that to optimized C. It’ll be fairly close, maybe 2x (optimized C vs optimized .NET plus overhead). Both will end up running a “save then print a precompiled constant”, of course.

That you can get .NET optimization so free is something pretty awesome. I didn’t see in the article anything showing which optimization options were used, though I did see that none were in comments, and my other comments here reflect that.

Of course 100% optimized C code will outrun any VM. Can OP give us a fully optimized control for reference, anyway? On the box that ran the other tests?

E: And about your edit…I THOUGHT so. I had trouble finding anything for sure, but I was pretty damn sure we could unroll the loop when the Delegate compiled.

Comment on The Fastest VM Bytecode Interpreter by exaggeration, but it was quite good

exaggeration, but it was quite good — Mon, 22 Nov 2010 05:07:31 +0000

This is the greatest blog post of all time.

Comment on The Fastest VM Bytecode Interpreter by Bob Foster

Bob Foster — Mon, 22 Nov 2010 03:47:38 +0000

Actually fascinating. Most of us wish we had a bud like Mat to challenge us!