On 4/6/2012 6:20 PM, deadalnix wrote:
Le 06/04/2012 18:07, Andrei Alexandrescu a écrit :
A few more samples of people's perception of the two languages:
http://news.ycombinator.com/item?id=3805302
Andrei
I did some measurement on that point for D lately :
http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
GC issues like this are currently blocking development of Visual D (a
Win32 project): when just adding spaces to a file, parsing the new file
every other second often needs 10 or more parsings until an equal amount
of memory is collected compared to the allocated memory. AFAICT Visual D
just keeps a reference to the root of the most recent AST of a source file.
What's even worse: when the allocated memory gets larger (say > 200MB),
the garbage collection itself takes more than a second stalling the
application, which is a real pain if it happens while you are typing
source text (it does happen quite often).
I've benchmarked testgc3.d from the dmd test suite a little: it
allocates about 200 MB of memory, never collects anything, still the
latest garbage collections takes about a second on an i7 boosted to 3GHz.
Compiling testgc3.d for x64 with GDC, it allocates twice as much memory,
still the garbage collection takes about a second.
Most of the time is spent in the mark phase of the collection, which
could probably be optimized to some extend, but that would have to be a
very good optimization to not running into problems with a little more
allocated memory.
So my current feeling is that conservative garbage collection with
stop-the-world mechanics is unusable in an interactive application
allocating a decent amount of memory (which is rather small in today's
computers). False pointers add to the problem, but they are not the
worst issue.
I hope there is something wrong with my reasoning, and that you could
give me some hints to avoid the memory bloat and the application stalls.
Rainer
