digitalmars.D - A smaller GC benchmark
- bearophile (118/118) Dec 10 2007 This tiny benchmark focus on GC performance and shows similar results to...
- Vladimir Panteleev (10/11) Dec 10 2007 I did some tests with Tango (head SVN).
- Sean Kelly (3/16) Dec 10 2007 Nifty.
- bearophile (4/4) Dec 10 2007 Regarding that Java version, the HotSpot Java compiler FAQ warns to not ...
- Sean Kelly (6/28) Dec 10 2007 Manually calling gc.collect() actually slowed down the app for me. And
- Robert Fraser (8/30) Dec 10 2007 I've been wanting for a while to implement a different GC for D taking
- Vladimir Panteleev (5/8) Dec 10 2007 I'm not sure if generational collectors are moving GCs, but since you're...
- Sean Kelly (12/19) Dec 10 2007 The void[] thing is a language decision, not a runtime decision. The
- Craig Black (4/8) Dec 10 2007 Is there a way to provide type information for the stack without hinderi...
- Vladimir Panteleev (8/18) Dec 10 2007 Ah, right.
- Robert Fraser (4/12) Dec 10 2007 How would you make a non-moving generational GC? Isn't the idea of the
- Leandro Lucarella (16/28) Dec 10 2007 Not exactly. Generation GCs are a particular case of parition based GCs.
- John Demme (14/34) Dec 10 2007 I don't believe so. According to the all-knowing Wikipedia entry on GCs...
- bearophile (7/11) Dec 10 2007 I can see people in this newsgroup don't like to try to adapt already wr...
- Robert Fraser (3/17) Dec 10 2007 I know it could be relatively easily plugged into Tango since Tango has
- Bruce Adams (5/27) Dec 14 2007 I thought D in general was supposed to have a pluggable GC interface.
- Sean Kelly (4/34) Dec 14 2007 I don't think so. The GC in Phobos does have some code in place that
- Sean Kelly (5/16) Dec 10 2007 It would be trivial to plug the Boehm GC into Tango. However, I'm not
- renoX (6/28) Dec 10 2007 I doubt that it truly doesn't leak: conservative GC may always leak
- bearophile (6/9) Dec 10 2007 I have found this page:
- James Jennings (5/7) Dec 18 2007 On a Pentium 4 @ 3.00GHz the obj_test_ss.py version ran in the range 7.3...
This tiny benchmark focus on GC performance and shows similar results to the
"binary trees" benchmark I have shown here few weeks ago, but it's quite
shorter, so it may be more useful. This code isn't meant to represent normal
programs with thousands of classes, etc, it just shows something quite limited.
This is an adaptation of the "Object Test" that you can find used and discussed
here:
http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html
http://blog.snaplogic.org/?p=55
http://programming.reddit.com/info/24ynh/comments
Note that I test the GC of Phobos only, I don't use Tango yet.
Object Test timings (on PIII 500 MHz), best of 3 runs (seconds, approximate
Mbytes memory used), n=1_000, m=10_000:
seconds MB
DMD class: 18.95 1.7
GDC class: 17.91 1.8
DMD struct: 11.77 1.7
GDC struct: 12.31 1.8
Python: 37.10 3.1 (ShedSkin version)
Psyco: 15.68 3.5
ShedSkin 6.35 1.6
Java (1): 2.19 7.3
Java (2): 2.10 7.8
See below for the sources. You can see the Java is about 9 (~= 18.95 / 2.10)
times faster than the program produced by DMD. Even Psyco (the JIT for the
turtle-slow language Python) gives faster performance (and the Python GC is
simple, it's just a reference count plus cycle detection). You can also see
Java (as usual) uses much more RAM (7.8/1.7 ~= 4.6).
Note that with some manual GC optimization the running time for the DMD class
benchmark can become about one-two seconds smaller, but the memory used can be
about 4 MB:
import std.gc;
class ObjectTest { ObjectTest next; }
void main() {
for (uint k = 0; k < 50; k++) {
std.gc.disable();
for (uint i = 0; i < 20; i++) {
auto root = new ObjectTest();
for (uint j = 0; j < 10_000; j++) {
root.next = new ObjectTest();
root = root.next;
}
}
std.gc.fullCollect();
}
}
-------------------
COMPILED/RUN WITH:
gcc version 3.4.5 (mingw special) (gdc 0.24, using dmd 1.020)
DMD v1.024
gcc version 3.4.2 (mingw-special)
javac 1.6.0_03
java version "1.6.0_03"
Python 2.5.1
ShedSkin 0.0.25 (shedskin.sourceforge.net , a Python to C++ compiler)
-------------------
COMPILATION/RUNNING PARAMETERS:
GDC used as:
gdc -O3 -s -frelease -finline-functions -ffast-math -fomit-frame-pointer
-funroll-loops -march=pentiumpro obj_test_class.d -o obj_test_class_gdc
DMD used as:
dmd -O -release -inline obj_test_class.d -ofobj_test_class_dmd.exe
Java compiled with:
javac ObjectTest.java
Java (1) run with:
java ObjectTest
Java (2) run with:
java -Xms20m -Xbatch ObjectTest
SS and Psyco compiled and run without flags.
-------------------
SOURCES:
// obj_test_class.d
class ObjectTest { ObjectTest next; }
void main() {
for (uint i = 0; i < 1_000; i++) {
auto root = new ObjectTest();
for (uint j = 0; j < 10_000; j++) {
root.next = new ObjectTest();
root = root.next;
}
}
}
-------------------
// obj_test_struct.d
struct ObjectTest { ObjectTest* next; }
void main() {
for (uint i = 0; i < 1_000; i++) {
auto root = new ObjectTest();
for (uint j = 0; j < 10_000; j++) {
root.next = new ObjectTest();
root = root.next;
}
}
}
-------------------
// ObjectTest.java
public class ObjectTest {
public ObjectTest next;
public static void main(String[] args) {
for (int i = 0; i < 1000; i++) {
ObjectTest root = new ObjectTest();
for (int j = 0; j < 10000; j++) {
root.next = new ObjectTest();
root = root.next;
}
}
}
}
-------------------
from psyco.classes import __metaclass__
class ObjectTest: pass
def main():
root = ObjectTest()
root.next = ObjectTest()
root = root.next
import psyco; psyco.full()
main()
-------------------
class ObjectTest: pass
def main():
root = ObjectTest()
root.next = ObjectTest()
root = root.next
main()
Bear hugs,
bearophile
Dec 10 2007
On Mon, 10 Dec 2007 18:56:10 +0200, bearophile <bearophileHUGS lycos.com> wrote:Note that I test the GC of Phobos only, I don't use Tango yet.I did some tests with Tango (head SVN). Specs: Core Duo E6600 2.40GHz per core, running Windows Phobos time: 3.140 seconds Tango time: 1.859 seconds Times are best of 3 runs, like your tests. I didn't measure memory usage, but it's pretty obvious that the Tango GC is significantly faster (in this case, at least) than the Phobos version. -- Best regards, Vladimir mailto:thecybershadow gmail.com
Dec 10 2007
Sean Kelly <sean f4.ca> Vladimir Panteleev wrote:On Mon, 10 Dec 2007 18:56:10 +0200, bearophile <bearophileHUGS lycos.com> wrote:Nifty. SeanNote that I test the GC of Phobos only, I don't use Tango yet.I did some tests with Tango (head SVN). Specs: Core Duo E6600 2.40GHz per core, running Windows Phobos time: 3.140 seconds Tango time: 1.859 seconds Times are best of 3 runs, like your tests. I didn't measure memory usage, but it's pretty obvious that the Tango GC is significantly faster (in this case, at least) than the Phobos version.
Dec 10 2007
Regarding that Java version, the HotSpot Java compiler FAQ warns to not use code like that: http://java.sun.com/docs/hotspot/HotSpotFAQ.html It says: if you insist on using/writing microbenchmarks like this, you can work around the problem by moving the body of main to a new method and calling it once from main to give the compiler a chance to compile the code, then calling it again in the timing bracket to see how fast HotSpot is.
Dec 10 2007
bearophile wrote:
This tiny benchmark focus on GC performance and shows similar results to the
"binary trees" benchmark I have shown here few weeks ago, but it's quite
shorter, so it may be more useful. This code isn't meant to represent normal
programs with thousands of classes, etc, it just shows something quite limited.
This is an adaptation of the "Object Test" that you can find used and discussed
here:
http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html
http://blog.snaplogic.org/?p=55
http://programming.reddit.com/info/24ynh/comments
Note that I test the GC of Phobos only, I don't use Tango yet.
Object Test timings (on PIII 500 MHz), best of 3 runs (seconds, approximate
Mbytes memory used), n=1_000, m=10_000:
seconds MB
DMD class: 18.95 1.7
GDC class: 17.91 1.8
DMD struct: 11.77 1.7
GDC struct: 12.31 1.8
Python: 37.10 3.1 (ShedSkin version)
Psyco: 15.68 3.5
ShedSkin 6.35 1.6
Java (1): 2.19 7.3
Java (2): 2.10 7.8
See below for the sources. You can see the Java is about 9 (~= 18.95 / 2.10)
times faster than the program produced by DMD. Even Psyco (the JIT for the
turtle-slow language Python) gives faster performance (and the Python GC is
simple, it's just a reference count plus cycle detection). You can also see
Java (as usual) uses much more RAM (7.8/1.7 ~= 4.6).
Note that with some manual GC optimization the running time for the DMD class
benchmark can become about one-two seconds smaller, but the memory used can be
about 4 MB:
Manually calling gc.collect() actually slowed down the app for me. And
Tango performs about the same as Phobos, when using the Java test as a
reference (ie. my quick test showed D being about 9 times as slow as
Java using Tango).
Sean
Dec 10 2007
bearophile wrote:
This tiny benchmark focus on GC performance and shows similar results to the
"binary trees" benchmark I have shown here few weeks ago, but it's quite
shorter, so it may be more useful. This code isn't meant to represent normal
programs with thousands of classes, etc, it just shows something quite limited.
This is an adaptation of the "Object Test" that you can find used and discussed
here:
http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html
http://blog.snaplogic.org/?p=55
http://programming.reddit.com/info/24ynh/comments
Note that I test the GC of Phobos only, I don't use Tango yet.
Object Test timings (on PIII 500 MHz), best of 3 runs (seconds, approximate
Mbytes memory used), n=1_000, m=10_000:
seconds MB
DMD class: 18.95 1.7
GDC class: 17.91 1.8
DMD struct: 11.77 1.7
GDC struct: 12.31 1.8
Python: 37.10 3.1 (ShedSkin version)
Psyco: 15.68 3.5
ShedSkin 6.35 1.6
Java (1): 2.19 7.3
Java (2): 2.10 7.8
See below for the sources. You can see the Java is about 9 (~= 18.95 / 2.10)
times faster than the program produced by DMD. Even Psyco (the JIT for the
turtle-slow language Python) gives faster performance (and the Python GC is
simple, it's just a reference count plus cycle detection). You can also see
Java (as usual) uses much more RAM (7.8/1.7 ~= 4.6).
Note that with some manual GC optimization the running time for the DMD class
benchmark can become about one-two seconds smaller, but the memory used can be
about 4 MB:
I've been wanting for a while to implement a different GC for D taking
into account some of the stuff talked about in a few papers I read on
non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they
don't do any sort of sexy trickery.
FWIW, I don't think non-moving GCs will ever be able to outperform a
well-tuned generational collector. But I'm not exactly in the know about
these things, so I may be wrong.
Dec 10 2007
On Mon, 10 Dec 2007 22:48:00 +0200, Robert Fraser <fraserofthenight gmail.com> wrote:FWIW, I don't think non-moving GCs will ever be able to outperform a well-tuned generational collector. But I'm not exactly in the know about these things, so I may be wrong.I'm not sure if generational collectors are moving GCs, but since you're comparing them to non-moving GCs I'll add that a moving GC needs full knowledge of type information to work properly. While confusing an integer for a pointer may be a forgiveable mistake for non-moving GCs, it's not for a moving GC. I think D isn't ready for that yet (especially considered that both Phobos and Tango maintainers/users insist on void[] being a type that's allowed to hold pointers). -- Best regards, Vladimir mailto:thecybershadow gmail.com
Dec 10 2007
Vladimir Panteleev wrote:On Mon, 10 Dec 2007 22:48:00 +0200, Robert Fraser <fraserofthenight gmail.com> wrote:The void[] thing is a language decision, not a runtime decision. The runtimes for Phobos and Tango rely on TypeInfo.flags & 1 to determine whether a particular type contains pointers. More exact type info for precise scanning would likely require a compiler change as well, since this would have to be added to TypeInfo. All of this would allow for a moving GC, but the GC would still be somewhat conservative because type information would still not be available for the stack (unless the app contained debug information, perhaps). So basically, any blocks pointed to from a location whose type is unknown, the block would effectively be pinned. SeanFWIW, I don't think non-moving GCs will ever be able to outperform a well-tuned generational collector. But I'm not exactly in the know about these things, so I may be wrong.I'm not sure if generational collectors are moving GCs, but since you're comparing them to non-moving GCs I'll add that a moving GC needs full knowledge of type information to work properly. While confusing an integer for a pointer may be a forgiveable mistake for non-moving GCs, it's not for a moving GC. I think D isn't ready for that yet (especially considered that both Phobos and Tango maintainers/users insist on void[] being a type that's allowed to hold pointers).
Dec 10 2007
All of this would allow for a moving GC, but the GC would still be somewhat conservative because type information would still not be available for the stack (unless the app contained debug information, perhaps).Is there a way to provide type information for the stack without hindering performance too badly? Obviously it will be better if the GC has as much information as possible. -Craig
Dec 10 2007
On Mon, 10 Dec 2007 23:12:38 +0200, Sean Kelly <sean f4.ca> wrote:The void[] thing is a language decision, not a runtime decision. The runtimes for Phobos and Tango rely on TypeInfo.flags & 1 to determine whether a particular type contains pointers. More exact type info for precise scanning would likely require a compiler change as well, since this would have to be added to TypeInfo. All of this would allow for a moving GC, but the GC would still be somewhat conservative because type information would still not be available for the stack (unless the app contained debug information, perhaps). So basically, any blocks pointed to from a location whose type is unknown, the block would effectively be pinned.Ah, right. Also, providing type information for the stack has already been discussed here. It's partially possible to do without much execution time overhead by storing the stack layout of a function's stack frame for every point in code somewhere. This requires that the GC have access to every stack frame in every thread, though - and it can't be done with a stack trace, because of non-D functions that D code might call. Hmm. What if every time before D code calls non-D code, it saves a pointer to its stack frame into thread local storage (saving the previous pointer beforehand)? Then it would be possible for the GC to trace the function stack. I think that this is definitely doable, but requires some thinking and work (and perhaps code change) :) -- Best regards, Vladimir mailto:thecybershadow gmail.com
Dec 10 2007
Vladimir Panteleev wrote:On Mon, 10 Dec 2007 22:48:00 +0200, Robert Fraser <fraserofthenight gmail.com> wrote:How would you make a non-moving generational GC? Isn't the idea of the generational GC that long-lived objects are moved into a separate part of memory?FWIW, I don't think non-moving GCs will ever be able to outperform a well-tuned generational collector. But I'm not exactly in the know about these things, so I may be wrong.I'm not sure if generational collectors are moving GCs, but since you're comparing them to non-moving GCs I'll add that a moving GC needs full knowledge of type information to work properly. While confusing an integer for a pointer may be a forgiveable mistake for non-moving GCs, it's not for a moving GC. I think D isn't ready for that yet (especially considered that both Phobos and Tango maintainers/users insist on void[] being a type that's allowed to hold pointers).
Dec 10 2007
Robert Fraser, el 10 de diciembre a las 13:32 me escribiste:Vladimir Panteleev wrote:Not exactly. Generation GCs are a particular case of parition based GCs. Their main feature is the posibility to perform a partial collection, instead of a full collection, making pause times smaller and, maybe increasing the cost/benefit ratio (recover as much as memory with the less processing time cost). You can make some tricks to avoid moving stuff (which might not be that performant, specially for generational collectors, but it can be done, and with some other types of partitional collectors could be very natural). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- La máquina de la moneda, mirá como te queda! -- Sidharta KiwiOn Mon, 10 Dec 2007 22:48:00 +0200, Robert Fraser <fraserofthenight gmail.com> wrote:How would you make a non-moving generational GC? Isn't the idea of the generational GC that long-lived objects are moved into a separate part of memory?FWIW, I don't think non-moving GCs will ever be able to outperform a well-tuned generational collector. But I'm not exactly in the know about these things, so I may be wrong.I'm not sure if generational collectors are moving GCs, but since you're comparing them to non-moving GCs I'll add that a moving GC needs full knowledge of type information to work properly. While confusing an integer for a pointer may be a forgiveable mistake for non-moving GCs, it's not for a moving GC. I think D isn't ready for that yet (especially considered that both Phobos and Tango maintainers/users insist on void[] being a type that's allowed to hold pointers).
Dec 10 2007
Robert Fraser wrote:Vladimir Panteleev wrote:I don't believe so. According to the all-knowing Wikipedia entry on GCs, generational GCs are frequently implemented by using difference sections of memory for each generation. However, this doesn't seem to be necessary. The only things that "generational" GC implies is that memory chunks are lumped into difference categories according to age- the older ones are scanned less often. Cross-generational references have to be given special attention, however. I could see a D GC being generational yet non-moving by storing a generation marker at the begining of a memory chunk or some such such scheme instead of partitioning memory by age. IANA GC expert, however, so please correct me if I'm wrong. -- ~John Demme me teqdruid.comOn Mon, 10 Dec 2007 22:48:00 +0200, Robert Fraser <fraserofthenight gmail.com> wrote:How would you make a non-moving generational GC? Isn't the idea of the generational GC that long-lived objects are moved into a separate part of memory?FWIW, I don't think non-moving GCs will ever be able to outperform a well-tuned generational collector. But I'm not exactly in the know about these things, so I may be wrong.I'm not sure if generational collectors are moving GCs, but since you're comparing them to non-moving GCs I'll add that a moving GC needs full knowledge of type information to work properly. While confusing an integer for a pointer may be a forgiveable mistake for non-moving GCs, it's not for a moving GC. I think D isn't ready for that yet (especially considered that both Phobos and Tango maintainers/users insist on void[] being a type that's allowed to hold pointers).
Dec 10 2007
Robert Fraser:I've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak, it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too. Bye, bearophile
Dec 10 2007
bearophile wrote:Robert Fraser:I know it could be relatively easily plugged into Tango since Tango has a pluggable GC interfaceI've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak, it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too. Bye, bearophile
Dec 10 2007
On Mon, 10 Dec 2007 21:34:20 -0000, Robert Fraser <fraserofthenight gmail.com> wrote:bearophile wrote:I thought D in general was supposed to have a pluggable GC interface. Isn't it part of the language spec?Robert Fraser:I know it could be relatively easily plugged into Tango since Tango has a pluggable GC interfaceI've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak, it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too. Bye, bearophile
Dec 14 2007
Bruce Adams wrote:On Mon, 10 Dec 2007 21:34:20 -0000, Robert Fraser <fraserofthenight gmail.com> wrote:I don't think so. The GC in Phobos does have some code in place that looks like it is meant to support run-time pluggability though. Seanbearophile wrote:I thought D in general was supposed to have a pluggable GC interface. Isn't it part of the language spec?Robert Fraser:I know it could be relatively easily plugged into Tango since Tango has a pluggable GC interfaceI've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak, it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too. Bye, bearophile
Dec 14 2007
bearophile wrote:Robert Fraser:It would be trivial to plug the Boehm GC into Tango. However, I'm not sure how much performance would benefit. IIRC someone tested the Boehm GC with D a while back and it was actually slower than the one Walter wrote. SeanI've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak, it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too.
Dec 10 2007
bearophile a écrit :Robert Fraser:I doubt that it truly doesn't leak: conservative GC may always leak depending on your program..I've been wanting for a while to implement a different GC for D taking into account some of the stuff talked about in a few papers I read on non-moving GCs. IMO, D's GCs (Tango & Phobos) are pretty basic, they don't do any sort of sexy trickery.I can see people in this newsgroup don't like to try to adapt already written code. Is this some bad from of NIH (Not Invented Here) syndrome? Maybe you can just take a 5-10-years old GC and adapt it, so we can avoid other 10 years of development and have a better GC soon (from your and other's comments I presume the Java GC can't be adapted to D, but other GCs may be found). Note that ShedSkin uses the Bohem GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ From various tests it seems faster than the Phobos GC. Can't it be copied inside Phobos? It's well refined, well debugged, it doesn't leak,it has something like ten years of development, articles written on it, it's used often, etc. And it can be used from C too. Bye, bearophileFor the rest I agree: reuse is nice. Regards, renoX
Dec 10 2007
Sean Kelly:However, I'm not sure how much performance would benefit. IIRC someone tested the Boehm GC with D a while back and it was actually slower than the one Walter wrote.I have found this page: http://wxd.sourceforge.net/misc.html But I don't know on how many benchmarks (and what benchmarks) this statement is based on :-) Bye, bearophile
Dec 10 2007
bearophile Wrote:This tiny benchmark focus on GC performance and shows similar results to the "binary trees" benchmark I have shown here few weeks ago, but it's quite shorter, so it may be more useful. <bearophile Wrote:This tiny benchmark focus on GC performance and shows similar results to the "binary trees" benchmark I have shown here few weeks ago, but it's quite shorter, so it may be more useful. <On a Pentium 4 3.00GHz the obj_test_ss.py version ran in the range 7.36 sec. to 7.54 sec. in three tests. The times are comparable to those of a P3 500 Mhz. Maybe a bit slower: 6*7.54=45.24. I would have thought that compiled C or D would be many times faster than shown in the test, but my expertise is slim in this area. Jim Jennings
Dec 18 2007