Hallo,
I am thinking about doing some basic 3D graphics with Gambit-C. Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses?
Afficher les réponses par date
Alex Sandro Queiroz e Silva wrote:
Hallo,
I am thinking about doing some basic 3D graphics with Gambit-C.Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses?
Unfortunately, yes you should expect such problems. If I'm correct, gambit's gc is a regular stop & copy style collector, which stops the world at each gc. I think that Marc has changing this to either a generationnal or incremental gc, which would lead respectively to smaller collection pauses or virtually none (but maybe with execution speed reduced?).
Still, if you pre-allocate lots of space, gc shouldn't occur too often and you can always force a gc with (##gc) at opportune moments.
David
On Sep 23, 2008, at 2:32 PM, David St-Hilaire wrote:
Alex Sandro Queiroz e Silva wrote:
Hallo,
I am thinking about doing some basic 3D graphics with Gambit-C.Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses?
Unfortunately, yes you should expect such problems. If I'm correct, gambit's gc is a regular stop & copy style collector, which stops the world at each gc. I think that Marc has changing this to either a generationnal or incremental gc, which would lead respectively to smaller collection pauses or virtually none (but maybe with execution speed reduced?).
Still, if you pre-allocate lots of space, gc shouldn't occur too often and you can always force a gc with (##gc) at opportune moments.
GCs are often very short, on the order of milliseconds, for example on a 2.0GHz G5:
[descartes:~/Desktop] lucier% gsi Gambit v4.2.8
(##gc-report-set! #t) (define a (time (expt 3 10000000)))
*** GC: 1 ms, 692K alloc, 386K heap, 82.0K live (21% 65712+18208) *** GC: 1 ms, 992K alloc, 386K heap, 88.0K live (23% 71920+18208) *** GC: 1 ms, 1.19M alloc, 1.27M heap, 94.8K live (7% 55584+41536) *** GC: 2 ms, 2.08M alloc, 2.22M heap, 163K live (7% 55456+111184) *** GC: 2 ms, 3.22M alloc, 4.05M heap, 253K live (6% 55392+204064) *** GC: 2 ms, 5.48M alloc, 6.86M heap, 435K live (6% 55328+389808) *** GC: 4 ms, 9.98M alloc, 14.2M heap, 797K live (5% 55264+761280) *** GC: 7 ms, 19.0M alloc, 27.2M heap, 1.49M live (5% 55200+1504224) *** GC: 12 ms, 36.9M alloc, 54.0M heap, 2.90M live (5% 55136+2990128) (time (expt 3 10000000)) 1165 ms real time 1096 ms cpu time (936 user, 160 system) 9 collections accounting for 33 ms real time (9 user, 23 system) 71837896 bytes allocated no minor faults no major faults
I'd write the app without worrying about gc times, instrument it with ##gc-report-set!, and then worry about gc's if they become a problem.
Brad
I agree with Brad. In fact some people are writing commercial video games right now with Gambit and the GC is performing reasonably well. This does not mean that a better (real-time or generational) GC wouldn't be good to have when the memory requirements are more severe, but with some planing and profiling it is possible to get the current GC to perform at a near real-time performance standard.
Marc
On 23-Sep-08, at 1:14 PM, Bradley Lucier wrote:
On Sep 23, 2008, at 2:32 PM, David St-Hilaire wrote:
Alex Sandro Queiroz e Silva wrote:
Hallo,
I am thinking about doing some basic 3D graphics with Gambit-C. Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses?
Unfortunately, yes you should expect such problems. If I'm correct, gambit's gc is a regular stop & copy style collector, which stops the world at each gc. I think that Marc has changing this to either a generationnal or incremental gc, which would lead respectively to smaller collection pauses or virtually none (but maybe with execution speed reduced?).
Still, if you pre-allocate lots of space, gc shouldn't occur too often and you can always force a gc with (##gc) at opportune moments.
GCs are often very short, on the order of milliseconds, for example on a 2.0GHz G5:
[descartes:~/Desktop] lucier% gsi Gambit v4.2.8
(##gc-report-set! #t) (define a (time (expt 3 10000000)))
*** GC: 1 ms, 692K alloc, 386K heap, 82.0K live (21% 65712+18208) *** GC: 1 ms, 992K alloc, 386K heap, 88.0K live (23% 71920+18208) *** GC: 1 ms, 1.19M alloc, 1.27M heap, 94.8K live (7% 55584+41536) *** GC: 2 ms, 2.08M alloc, 2.22M heap, 163K live (7% 55456+111184) *** GC: 2 ms, 3.22M alloc, 4.05M heap, 253K live (6% 55392+204064) *** GC: 2 ms, 5.48M alloc, 6.86M heap, 435K live (6% 55328+389808) *** GC: 4 ms, 9.98M alloc, 14.2M heap, 797K live (5% 55264+761280) *** GC: 7 ms, 19.0M alloc, 27.2M heap, 1.49M live (5% 55200+1504224) *** GC: 12 ms, 36.9M alloc, 54.0M heap, 2.90M live (5% 55136+2990128) (time (expt 3 10000000)) 1165 ms real time 1096 ms cpu time (936 user, 160 system) 9 collections accounting for 33 ms real time (9 user, 23 system) 71837896 bytes allocated no minor faults no major faults
I'd write the app without worrying about gc times, instrument it with ##gc-report-set!, and then worry about gc's if they become a problem.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hallo,
Marc Feeley wrote:
I agree with Brad. In fact some people are writing commercial video games right now with Gambit and the GC is performing reasonably well. This does not mean that a better (real-time or generational) GC wouldn't be good to have when the memory requirements are more severe, but with some planing and profiling it is possible to get the current GC to perform at a near real-time performance standard.
This is very good to know! Thanks David, Bradley and Marc for your insightful responses.
Cheers, -alex http://www.ventonegro.org/
Hallo,
On Tue, Sep 23, 2008 at 6:14 PM, Bradley Lucier lucier@math.purdue.edu wrote:
GCs are often very short, on the order of milliseconds, for example on a 2.0GHz G5:
[descartes:~/Desktop] lucier% gsi Gambit v4.2.8
> (##gc-report-set! #t) > (define a (time (expt 3 10000000))) *** GC: 1 ms, 692K alloc, 386K heap, 82.0K live (21% 65712+18208) *** GC: 1 ms, 992K alloc, 386K heap, 88.0K live (23% 71920+18208) *** GC: 1 ms, 1.19M alloc, 1.27M heap, 94.8K live (7% 55584+41536) *** GC: 2 ms, 2.08M alloc, 2.22M heap, 163K live (7% 55456+111184) *** GC: 2 ms, 3.22M alloc, 4.05M heap, 253K live (6% 55392+204064) *** GC: 2 ms, 5.48M alloc, 6.86M heap, 435K live (6% 55328+389808) *** GC: 4 ms, 9.98M alloc, 14.2M heap, 797K live (5% 55264+761280) *** GC: 7 ms, 19.0M alloc, 27.2M heap, 1.49M live (5% 55200+1504224) *** GC: 12 ms, 36.9M alloc, 54.0M heap, 2.90M live (5% 55136+2990128) (time (expt 3 10000000)) 1165 ms real time 1096 ms cpu time (936 user, 160 system) 9 collections accounting for 33 ms real time (9 user, 23 system) 71837896 bytes allocated no minor faults no major faults
I know this is an oooold thread, but I just compiled Gambit-C with Clang and wanted something to compare with. The time I got is roughly 1/3 of this:
(time (expt 3 10000000)) 480 ms real time 478 ms cpu time (418 user, 60 system) 15 collections accounting for 13 ms real time (6 user, 7 system) 71857592 bytes allocated 13810 minor faults no major faults
This is a 2.4GHz Core 2 Duo running Snow Leopard, so some of the improvement must be due to the CPU difference.
Cheers,
On Jan 5, 2010, at 9:20 PM, Alex Queiroz wrote:
Hallo,
On Tue, Sep 23, 2008 at 6:14 PM, Bradley Lucier <lucier@math.purdue.edu
wrote:
GCs are often very short, on the order of milliseconds, for example on a 2.0GHz G5:
[descartes:~/Desktop] lucier% gsi Gambit v4.2.8
(##gc-report-set! #t) (define a (time (expt 3 10000000)))
*** GC: 1 ms, 692K alloc, 386K heap, 82.0K live (21% 65712+18208) *** GC: 1 ms, 992K alloc, 386K heap, 88.0K live (23% 71920+18208) *** GC: 1 ms, 1.19M alloc, 1.27M heap, 94.8K live (7% 55584+41536) *** GC: 2 ms, 2.08M alloc, 2.22M heap, 163K live (7% 55456+111184) *** GC: 2 ms, 3.22M alloc, 4.05M heap, 253K live (6% 55392+204064) *** GC: 2 ms, 5.48M alloc, 6.86M heap, 435K live (6% 55328+389808) *** GC: 4 ms, 9.98M alloc, 14.2M heap, 797K live (5% 55264+761280) *** GC: 7 ms, 19.0M alloc, 27.2M heap, 1.49M live (5% 55200+1504224) *** GC: 12 ms, 36.9M alloc, 54.0M heap, 2.90M live (5% 55136+2990128) (time (expt 3 10000000)) 1165 ms real time 1096 ms cpu time (936 user, 160 system) 9 collections accounting for 33 ms real time (9 user, 23 system) 71837896 bytes allocated no minor faults no major faults
I know this is an oooold thread, but I just compiled Gambit-Cwith Clang and wanted something to compare with. The time I got is roughly 1/3 of this:
(time (expt 3 10000000)) 480 ms real time 478 ms cpu time (418 user, 60 system) 15 collections accounting for 13 ms real time (6 user, 7 system) 71857592 bytes allocated 13810 minor faults no major faults
This is a 2.4GHz Core 2 Duo running Snow Leopard, so some of the improvement must be due to the CPU difference.
Using the latest version of gambit and Apple's standard compiler on Leopard:
[maureen-luciers-macbook-pro:~] lucier% gsi -v v4.5.3 20091128045012 i386-apple-darwin9.8.0 "./configure CC=gcc -m64 - march=nocona --enable-single-host --enable-multiple-versions --no- create --no-recursion" [maureen-luciers-macbook-pro:~] lucier% gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493)
I get
(define a (time (expt 3 10000000)))
(time (expt 3 10000000)) 503 ms real time 501 ms cpu time (438 user, 63 system) 6 collections accounting for 9 ms real time (3 user, 6 system) 71793992 bytes allocated no minor faults no major faults
on a 2.26 GHz Core 2 Duo on a 13" Macbook Pro. So scaling CPU speed to your slightly faster machine, I get an estimated time of
(* 501 2.26 (/ 2.4))
471.77500000000003
on your machine, which is just about what you got. I'm not sure what difference, if any, clang makes to the performance of this code.
Brad
Hallo,
On Wed, Jan 6, 2010 at 4:02 AM, Bradley Lucier lucier@math.purdue.edu wrote:
on your machine, which is just about what you got. I'm not sure what difference, if any, clang makes to the performance of this code.
I guess you just proved it makes no difference at all. :) So let's keep waiting for GCC 4.5.
Cheers,
-
Alex Queiroz -
Alex Sandro Queiroz e Silva
-
Bradley Lucier -
David St-Hilaire -
Marc Feeley