[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: PATCH: Fully Resumable VM (yield across pcall/callback/meta/iter)
- From: David Jones <drj@...>
- Date: Tue, 15 Feb 2005 16:18:07 +0000
On Feb 15, 2005, at 15:46, David Given wrote:
On Tuesday 15 February 2005 14:15, David Burgess wrote:
On Tue, 15 Feb 2005 14:
One million setjmp/longjmp plus the surrounding overhead easily
in one and a half seconds on my machine.
But one million C++ try/catch/throw need more than a minute (!) to
Your platform and compiler?
I think he said Visual C++, which is notorious for its lousy exception
support. I wonder what the same benchmark would be like on gcc?
setjmp() and longjmp() are a lot more sophisticated than they look; the
compiler requires special knowledge of them in order to do things like
sure that variables aren't cached in registers across a setjmp() call,
example. C++ exceptions would need to do the same, but they have more
restricted semantics that simplify matters considerably... assuming
objects being thrown are scalars, and not multi-byte objects, I don't
C++ exceptions can't be nearly as fast as longjmp().
setjmp and longjmp are specified (in the ISO standard) so that C
implementations can pretty much get away with a minimal fast
implementation, not a clever one. In particular when longjmp is
invoked it is allowed to trash any local variable declared in the
function that called setjmp (the one to which we are jumping), unless
that variable is declared volatile. Basically this means that in the
traditional split of a C implementation into a compiler and a library
the compiler _doesn't_ need to know about setjmp and longjmp. And all
that setjmp and longjmp have to do is copy the PC, the SP, and the
saved registers (those registers that the platform ABI defines as being
preserved across function calls). Of course it's possible that some
implementations go out of their way to have longjmp deliberately _not_
trash local variables even when not declared volatile, and they are
allowed to do that, but not required.
C++ exceptions are _designed_ to be slow aren't they? It was a
specific goal when designing C++ that C code, when compiled under a C++
compiler, be no slower; and it was specifically intended that the
runtime design of exceptions be slow in order to do make this so. In
other words, you don't have a complicated function call arrangement
with lots of stack baggage to make exceptions faster if that would slow
down C code (which doesn't use exceptions, naturally).