All: I generally hack on a netbook, which has a very slow hard drive (but is 1.66 GHz, 1 GB memory). So, gsc using gcc is a bit slow sometimes. I decided to try tcc (Gambit-C 4.6.6 - 64 bit - Fedora 17, tcc 0.9.25 - built from current web distribution). http://bellard.org/tcc/ http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25.tar.bz2 0.9.25 supports 64 bit x86 code. I did not rebuild gsi or gsc with tcc, but simply incorporated tcc into the gambc-cc script. Results: With 13,156 lines of Scheme (my "standard library") Building with tcc: real 0m25.577s user 0m18.633s sys 0m3.290s 4,465,784 bytes of object code. Building with gcc (4.7.2): real 3m47.997s user 3m8.047s sys 0m11.283s With 4,004,348 bytes of object obtained. Now, I haven't tested the results extensively at all, but I am very happy so far (no obvious problems). The change made to gambc-cc is an insertion at line 13 (just above DEFS_OBJ=...). I added the following hack: ==> Cut <== # If CC is tcc, use that instead. We use tcc 0.9.25 # Most of the options are meaningless with this compiler, but we grab # the ones that do make sense. Gambit-C itself has not been built with # tcc (I use the Fedora repo version of 4.6.6), but code that is # generated by gsc is compiled with tcc. So far, no problems! (larger # code size by up to 40% for "Hello world", but MUCH faster compilation # of C files). if [ "$CC" == "tcc" ]; then C_COMPILER="tcc" FLAGS_OBJ="-g -Wall" FLAGS_DYN="-g -Wall -rdynamic -shared" FLAGS_LIB="-g -Wall -rdynamic -shared" FLAGS_EXE="-g -Wall -rdynamic" fi ==> Cut <== To use, simply define CC=tcc in your enviroment (export CC=tcc), or put a similar statement into the Makefile (presuming that is used). I have not measured execution speed of Scheme code at all, but a 6x improvement in compilation speed is worth continuing along this path (for me, anyway). Typically, object size increases by 10% (for my standard library) to 40% (for a simple "hello world" example). I won't be able to expend cycles benchmarking code with tcc -- I am more interested in any failure cases from this compiler. Maybe someone can do a benchmark run? Fred Weigel
Afficher les réponses par date
On Fri, Feb 8, 2013 at 9:50 PM, Weigel, Fred <fred.weigel@zylog.ca> wrote:
Building with tcc:
real 0m25.577s user 0m18.633s sys 0m3.290s
Building with gcc (4.7.2):
real 3m47.997s user 3m8.047s sys 0m11.283s
Just a note: compiling C code generated by Gambit-C with the upcoming GCC 4.8 is many times faster than with GCC 4.7.x. Cheers, -- -alex http://unendli.ch/
Very cool! I have been a fan of TCC for a long time and have been interested in combining TCC and Gambit to make a standalone distribution of Gambit. I'm glad to see that TCC can compile Gambit generated code. Could you try building Gambit using TCC? I wonder how fast TCC generated code is. Marc On 2013-02-08, at 3:50 PM, Fred Weigel <fred.weigel@zylog.ca> wrote:
All:
I generally hack on a netbook, which has a very slow hard drive (but is 1.66 GHz, 1 GB memory). So, gsc using gcc is a bit slow sometimes. I decided to try tcc (Gambit-C 4.6.6 - 64 bit - Fedora 17, tcc 0.9.25 - built from current web distribution).
http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25.tar.bz2
0.9.25 supports 64 bit x86 code.
I did not rebuild gsi or gsc with tcc, but simply incorporated tcc into the gambc-cc script.
Results:
With 13,156 lines of Scheme (my "standard library")
Building with tcc:
real 0m25.577s user 0m18.633s sys 0m3.290s
4,465,784 bytes of object code.
Building with gcc (4.7.2):
real 3m47.997s user 3m8.047s sys 0m11.283s
With 4,004,348 bytes of object obtained.
Now, I haven't tested the results extensively at all, but I am very happy so far (no obvious problems).
The change made to gambc-cc is an insertion at line 13 (just above DEFS_OBJ=...). I added the following hack:
==> Cut <== # If CC is tcc, use that instead. We use tcc 0.9.25 # Most of the options are meaningless with this compiler, but we grab # the ones that do make sense. Gambit-C itself has not been built with # tcc (I use the Fedora repo version of 4.6.6), but code that is # generated by gsc is compiled with tcc. So far, no problems! (larger # code size by up to 40% for "Hello world", but MUCH faster compilation # of C files). if [ "$CC" == "tcc" ]; then C_COMPILER="tcc" FLAGS_OBJ="-g -Wall" FLAGS_DYN="-g -Wall -rdynamic -shared" FLAGS_LIB="-g -Wall -rdynamic -shared" FLAGS_EXE="-g -Wall -rdynamic" fi ==> Cut <==
To use, simply define CC=tcc in your enviroment (export CC=tcc), or put a similar statement into the Makefile (presuming that is used).
I have not measured execution speed of Scheme code at all, but a 6x improvement in compilation speed is worth continuing along this path (for me, anyway). Typically, object size increases by 10% (for my standard library) to 40% (for a simple "hello world" example).
I won't be able to expend cycles benchmarking code with tcc -- I am more interested in any failure cases from this compiler. Maybe someone can do a benchmark run?
Fred Weigel
Marc I brought down gambc-v4_6_6-devel ./configure CC=tcc --enable-single-host I then did time make make[1]: Leaving directory `/export/home/fred/Downloads/gambc-v4_6_6-devel/prebuilt' real 0m31.620s user 0m28.775s sys 0m2.241s (On my 1.66 GHz Atom, single core, with 1 GB RAM). Build seems successful, running through testing. I did upgrade tcc to the git "mob" head, because I found an issue with the older tcc (64 bit structure copies were sometimes, um.., mis-sized, seems ok with the most recent version). Fred Weigel On Tue, 2013-02-12 at 13:09 -0500, Marc Feeley wrote:
Very cool! I have been a fan of TCC for a long time and have been interested in combining TCC and Gambit to make a standalone distribution of Gambit. I'm glad to see that TCC can compile Gambit generated code. Could you try building Gambit using TCC? I wonder how fast TCC generated code is.
Marc
On 2013-02-08, at 3:50 PM, Fred Weigel <fred.weigel@zylog.ca> wrote:
All:
I generally hack on a netbook, which has a very slow hard drive (but is 1.66 GHz, 1 GB memory). So, gsc using gcc is a bit slow sometimes. I decided to try tcc (Gambit-C 4.6.6 - 64 bit - Fedora 17, tcc 0.9.25 - built from current web distribution).
http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25.tar.bz2
0.9.25 supports 64 bit x86 code.
I did not rebuild gsi or gsc with tcc, but simply incorporated tcc into the gambc-cc script.
Results:
With 13,156 lines of Scheme (my "standard library")
Building with tcc:
real 0m25.577s user 0m18.633s sys 0m3.290s
4,465,784 bytes of object code.
Building with gcc (4.7.2):
real 3m47.997s user 3m8.047s sys 0m11.283s
With 4,004,348 bytes of object obtained.
Now, I haven't tested the results extensively at all, but I am very happy so far (no obvious problems).
The change made to gambc-cc is an insertion at line 13 (just above DEFS_OBJ=...). I added the following hack:
==> Cut <== # If CC is tcc, use that instead. We use tcc 0.9.25 # Most of the options are meaningless with this compiler, but we grab # the ones that do make sense. Gambit-C itself has not been built with # tcc (I use the Fedora repo version of 4.6.6), but code that is # generated by gsc is compiled with tcc. So far, no problems! (larger # code size by up to 40% for "Hello world", but MUCH faster compilation # of C files). if [ "$CC" == "tcc" ]; then C_COMPILER="tcc" FLAGS_OBJ="-g -Wall" FLAGS_DYN="-g -Wall -rdynamic -shared" FLAGS_LIB="-g -Wall -rdynamic -shared" FLAGS_EXE="-g -Wall -rdynamic" fi ==> Cut <==
To use, simply define CC=tcc in your enviroment (export CC=tcc), or put a similar statement into the Makefile (presuming that is used).
I have not measured execution speed of Scheme code at all, but a 6x improvement in compilation speed is worth continuing along this path (for me, anyway). Typically, object size increases by 10% (for my standard library) to 40% (for a simple "hello world" example).
I won't be able to expend cycles benchmarking code with tcc -- I am more interested in any failure cases from this compiler. Maybe someone can do a benchmark run?
Fred Weigel
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc All right. First TCC results: gsi - appears to work... gsc - doesn't work (spins somewhere, very busy) First two tests pass (tests/ directory), third test "hangs" (at least, takes longer than 10 minutes). I guess I need a baseline. HOWEVER - I can benchmark the system with the old compiler using tcc (why not, code generation should be the same). Fred Weigel On Tue, 2013-02-12 at 13:09 -0500, Marc Feeley wrote:
Very cool! I have been a fan of TCC for a long time and have been interested in combining TCC and Gambit to make a standalone distribution of Gambit. I'm glad to see that TCC can compile Gambit generated code. Could you try building Gambit using TCC? I wonder how fast TCC generated code is.
Marc
On 2013-02-08, at 3:50 PM, Fred Weigel <fred.weigel@zylog.ca> wrote:
All:
I generally hack on a netbook, which has a very slow hard drive (but is 1.66 GHz, 1 GB memory). So, gsc using gcc is a bit slow sometimes. I decided to try tcc (Gambit-C 4.6.6 - 64 bit - Fedora 17, tcc 0.9.25 - built from current web distribution).
http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25.tar.bz2
0.9.25 supports 64 bit x86 code.
I did not rebuild gsi or gsc with tcc, but simply incorporated tcc into the gambc-cc script.
Results:
With 13,156 lines of Scheme (my "standard library")
Building with tcc:
real 0m25.577s user 0m18.633s sys 0m3.290s
4,465,784 bytes of object code.
Building with gcc (4.7.2):
real 3m47.997s user 3m8.047s sys 0m11.283s
With 4,004,348 bytes of object obtained.
Now, I haven't tested the results extensively at all, but I am very happy so far (no obvious problems).
The change made to gambc-cc is an insertion at line 13 (just above DEFS_OBJ=...). I added the following hack:
==> Cut <== # If CC is tcc, use that instead. We use tcc 0.9.25 # Most of the options are meaningless with this compiler, but we grab # the ones that do make sense. Gambit-C itself has not been built with # tcc (I use the Fedora repo version of 4.6.6), but code that is # generated by gsc is compiled with tcc. So far, no problems! (larger # code size by up to 40% for "Hello world", but MUCH faster compilation # of C files). if [ "$CC" == "tcc" ]; then C_COMPILER="tcc" FLAGS_OBJ="-g -Wall" FLAGS_DYN="-g -Wall -rdynamic -shared" FLAGS_LIB="-g -Wall -rdynamic -shared" FLAGS_EXE="-g -Wall -rdynamic" fi ==> Cut <==
To use, simply define CC=tcc in your enviroment (export CC=tcc), or put a similar statement into the Makefile (presuming that is used).
I have not measured execution speed of Scheme code at all, but a 6x improvement in compilation speed is worth continuing along this path (for me, anyway). Typically, object size increases by 10% (for my standard library) to 40% (for a simple "hello world" example).
I won't be able to expend cycles benchmarking code with tcc -- I am more interested in any failure cases from this compiler. Maybe someone can do a benchmark run?
Fred Weigel
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc First TCC benchmarks; they're not good. Get numbers for GCC on this platform. Just running fib and boyer, and only r5rs - we want to test the C compilers: [fred@dejah bench]$ ./bench gambit "fib boyer" Testing fib under Gambit-C-r5rs Compiling... gcc -Wl,-z,relro -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared -D___SINGLE_HOST -D___DYNAMIC -I"/usr/include" -o "fib.o1" fib.c 1.58user 0.15system 0:01.76elapsed 98%CPU (0avgtext+0avgdata 21156maxresident)k 0inputs+216outputs (0major+15623minor)pagefaults 0swaps Running... code size = -74 (time (run-bench name count ok? run)) 8351 ms real time 8332 ms cpu time (8331 user, 1 system) no collections no bytes allocated 1 minor fault no major faults Testing boyer under Gambit-C-r5rs Compiling... gcc -Wl,-z,relro -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared -D___SINGLE_HOST -D___DYNAMIC -I"/usr/include" -o "boyer.o1" boyer.c 7.91user 0.35system 0:08.29elapsed 99%CPU (0avgtext+0avgdata 58684maxresident)k 696inputs+1040outputs (7major+32154minor)pagefaults 0swaps Running... code size = -77 (time (run-bench name count ok? run)) 4598 ms real time 4584 ms cpu time (4565 user, 19 system) 23 collections accounting for 130 ms real time (125 user, 3 system) 217405440 bytes allocated 2728 minor faults no major faults ======== Now, times for TCC. The gambc-cc script has my hack, making it easy to switch compilers. Just add CC=tcc before the command and we are ready to go! [fred@dejah bench]$ CC=tcc ./bench gambit "fib boyer" Testing fib under Gambit-C-r5rs Compiling... tcc -g -Wall -rdynamic -shared -D___SINGLE_HOST -D___DYNAMIC -I"/usr/include" -o "fib.o1" fib.c 0.21user 0.06system 0:00.43elapsed 65%CPU (0avgtext+0avgdata 13700maxresident)k 5800inputs+192outputs (27major+5776minor)pagefaults 0swaps Running... code size = 17822 (time (run-bench name count ok? run)) 84861 ms real time 84658 ms cpu time (84607 user, 51 system) no collections no bytes allocated 2 minor faults no major faults Testing boyer under Gambit-C-r5rs Compiling... tcc -g -Wall -rdynamic -shared -D___SINGLE_HOST -D___DYNAMIC -I"/usr/include" -o "boyer.o1" boyer.c 0.94user 0.09system 0:01.10elapsed 94%CPU (0avgtext+0avgdata 22464maxresident)k 0inputs+1048outputs (0major+8263minor)pagefaults 0swaps Running... code size = 79164 (time (run-bench name count ok? run)) 53469 ms real time 53309 ms cpu time (53202 user, 107 system) 23 collections accounting for 127 ms real time (124 user, 0 system) 217405440 bytes allocated 2725 minor faults no major faults =============== TCC compiles 6 times faster, but the code runs 10 times slower! In fact Boyer runs at HALF THE SPEED OF THE INTERPRETER. Conversely, the Fib benchmark compiled by TCC is twice as fast as the interpreter. What does this tell us? - It isn't worth using TCC right now. Its too bad, this had such promise (I suspect that TCC spills to memory on every statement, etc. and the Atom may be the worst platform for TCC). Maybe gsc wasn't broken... just incredibly slow?! (when built with tcc). Enough for tonight. Fred Weigel On Tue, 2013-02-12 at 13:09 -0500, Marc Feeley wrote:
Very cool! I have been a fan of TCC for a long time and have been interested in combining TCC and Gambit to make a standalone distribution of Gambit. I'm glad to see that TCC can compile Gambit generated code. Could you try building Gambit using TCC? I wonder how fast TCC generated code is.
Marc
On 2013-02-08, at 3:50 PM, Fred Weigel <fred.weigel@zylog.ca> wrote:
All:
I generally hack on a netbook, which has a very slow hard drive (but is 1.66 GHz, 1 GB memory). So, gsc using gcc is a bit slow sometimes. I decided to try tcc (Gambit-C 4.6.6 - 64 bit - Fedora 17, tcc 0.9.25 - built from current web distribution).
http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25.tar.bz2
0.9.25 supports 64 bit x86 code.
I did not rebuild gsi or gsc with tcc, but simply incorporated tcc into the gambc-cc script.
Results:
With 13,156 lines of Scheme (my "standard library")
Building with tcc:
real 0m25.577s user 0m18.633s sys 0m3.290s
4,465,784 bytes of object code.
Building with gcc (4.7.2):
real 3m47.997s user 3m8.047s sys 0m11.283s
With 4,004,348 bytes of object obtained.
Now, I haven't tested the results extensively at all, but I am very happy so far (no obvious problems).
The change made to gambc-cc is an insertion at line 13 (just above DEFS_OBJ=...). I added the following hack:
==> Cut <== # If CC is tcc, use that instead. We use tcc 0.9.25 # Most of the options are meaningless with this compiler, but we grab # the ones that do make sense. Gambit-C itself has not been built with # tcc (I use the Fedora repo version of 4.6.6), but code that is # generated by gsc is compiled with tcc. So far, no problems! (larger # code size by up to 40% for "Hello world", but MUCH faster compilation # of C files). if [ "$CC" == "tcc" ]; then C_COMPILER="tcc" FLAGS_OBJ="-g -Wall" FLAGS_DYN="-g -Wall -rdynamic -shared" FLAGS_LIB="-g -Wall -rdynamic -shared" FLAGS_EXE="-g -Wall -rdynamic" fi ==> Cut <==
To use, simply define CC=tcc in your enviroment (export CC=tcc), or put a similar statement into the Makefile (presuming that is used).
I have not measured execution speed of Scheme code at all, but a 6x improvement in compilation speed is worth continuing along this path (for me, anyway). Typically, object size increases by 10% (for my standard library) to 40% (for a simple "hello world" example).
I won't be able to expend cycles benchmarking code with tcc -- I am more interested in any failure cases from this compiler. Maybe someone can do a benchmark run?
Fred Weigel
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
participants (4)
-
Alex Queiroz -
Fred Weigel -
Marc Feeley -
Weigel, Fred