Re: To go with Go or C/C++?
On Wednesday, 8 May 2013 00:47:33 UTC+3, Melzzzzz wrote:
On Tue, 7 May 2013 22:41:49 +0200
Melzzzzz <mel@zzzzz.com> wrote:
On Fri, 3 May 2013 10:46:39 -0700 (PDT)
=D6=F6 Tiib <ootiib@hot.ee> wrote:
Output with Visual studio 2010 (run it *without* debugging otherwise
it heavily hooks itself to exceptions):
With if it took 921 msec; (sum 197990000)
With try it took 782 msec; (sum 197990000)
So 17% better performance thanks to replacing 200 ifs in cycle with
one try/catch.
With more realistic example:
bmaxa@maxa:~/examples$ cat module.cpp
#include <cstring>
#include <stdexcept>
bool checkThingsWithIf( int param, char* error, unsigned errsz )throw()
{
if( param % 10000 == 0)
{
strncpy(error,"some error",errsz);
return false;
}
return true;
}
I omitted that 'throw()' in hope that compilers can well see themselves
that the function does not throw. At least visual studio did not
add stack unwinding code to it.
In C code that I have seen the functions return an int. Sometimes
there is enum returned. One value (often 0) indicates success and rest
of the values mean error codes. It is unlikely that whole string buffer
and its size as parameters will be devoted to error handling in real
code.
void checkThingsWithTry( int param )
{
if ( param % 10000 == 0 )
{
throw std::runtime_error("some error");
}
}
Lot of C++ coding standards require throwing application-specific
exceptions. Such may be inherited from std::exception family but note
that in memory-constrained situation the bad_alloc will fly here
instead of runtime_error.
Other code was like it was for testing purposes. Catch
chains in actual applications are commonly farther around big
operations not around for cycles of 200.
bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 340 msec; (sum 197990000)
With if it took 410 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 490 msec; (sum 197990000)
With if it took 510 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 870 msec; (sum 1525529904)
With if it took 860 msec; (sum 1525529904)
Btw ... I assumed -fno-inline-small-functions with gcc just to make
it harder for it to merge the ifs in exception-less code. However that
does not matter, the whole thing only demonstrated that exceptions and
return value checking are comparable, both cost something and when
exceptions are thrown rarely (often more rarely than 1:10000) then
return value checking slows the application needlessly by costing
more.
Seems that exceptions win when throwing exception
objects instead of filling error buffer;)
Likely some dynamic memory management in std::runtime error kicked
the tables here. Note that in real code the performance of exception
objects does matter less since throwing thousands of exceptions per
second is unusual. I just wanted to demonstrate that the thing is far
more efficient than lot of people seem to think; it was no way meant
as example of realistic usage of exceptions.
If you want to improve performance of exception objects then you can
throw pointers to static exception objects or throw your own exception
objects that do not manage memory dynamically or derive such from std::exce=
ption by overriding what() instead of having string
constructor arguments.