Le 09/04/2012 02:24, Alex Rønne Petersen a écrit :
On 09-04-2012 02:18, Manu wrote:
On 9 April 2012 02:24, Walter Bright <newshou...@digitalmars.com
<mailto:newshou...@digitalmars.com>> wrote:
On 4/8/2012 3:57 PM, Manu wrote:
What do you base that statistic on? I'm not arguing that fact,
just that I
haven't seen any evidence one way or the other. What causes Go
to create
significantly more garbage than D? Are there benchmarks or test
cases I should
be aware of on the topic?
The first ycombinator reference is a person who didn't run out of
memory using D. That implies far less pressure on the gc.
My understanding of Go is that when it does structural conformance,
it builds some of the necessary data at runtime on the gc heap.
Anyhow, D has a lot of facilities for putting things on the stack
rather than the heap, immutable data doesn't need to get copied, and
slices allow lots of reuse of existing objects.
"optimized D was slightly faster than Go at almost anything and consumed
up to 70% less memory"
Interesting... I don't know enough about Go to reason that finding, I
guess I assumed it has most of the same possibilities available to D.
(no immutable data? no stack structs? no references/pointers/slices?
crazy...)
The only D program I have significant experience with is VisualD, and it
hogs 1-2gb of ram for me under general usage, and eventually crashes,
after paging heavily and bringing my computer to a crawl. Not a good
sign from the first and only productive D app I've run yet ;)
This seems a lot like his experience with Go... but comparisons aside, D
still clearly isn't there yet when it comes to the GC either, and I'm
amazed Google thing Go is production ready if that guys findings are
true!
Google likes to invent random useless languages. See: Dart. Both
languages are solutions looking for problems. ;)
And yes, precise GC is more essential than most people think.
I posted some an article about that. 64bits pretty much solve the false
positive problem.
Still, precise GC is nice, but alternative like precise on heap and
imprecise on stack are very valid alternatives.
