lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 complete
in one and a half seconds on my machine.

But one million C++ try/catch/throw need more than a minute (!) to
complete. Yuck!

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 make sure that variables aren't cached in registers across a setjmp() call, for
example. C++ exceptions would need to do the same, but they have more
restricted semantics that simplify matters considerably... assuming that the objects being thrown are scalars, and not multi-byte objects, I don't see why
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).

David Jones