On Sat, 19 Feb 2011 22:39:10 -0500, Nick Sabalausky wrote:
"bearophile" wrote in message
news:ijpkh8$232r$1...@digitalmars.com...
dsimcha:
Yeh, I rebuilt the same model in my head over the past few hours (like
you, I had a good mental model of the GC at one point but have slowly
forgotten i
Nick Sabalausky wrote:
Ahh, I was confusing "gene" with "chromosome" (and probably still got the
exact number wrong ;) ).
That you did. Humans have 23 chromosome pairs. But now you know!
--
Simen
Sat, 19 Feb 2011 22:15:52 -0500, Nick Sabalausky wrote:
> "retard" wrote in message
> news:ijp7pa$1d34$1...@digitalmars.com...
>> Sat, 19 Feb 2011 14:32:27 -0500, dsimcha wrote:
>>
>>> On 2/19/2011 12:50 PM, Ulrik Mikaelsson wrote:
Just a thought; I guess the references to the non-GC-scanned
"dsimcha" wrote in message
news:ijq2bl$2opj$1...@digitalmars.com...
> On 2/19/2011 10:21 PM, Nick Sabalausky wrote:
>> Out of curiosity, roughly how many, umm "characters" (I forget the
>> technical
>> term for each T, G, etc), are in each yeast gene, and how many genes do
>> they
>> have? (Hum
On 2/19/2011 10:21 PM, Nick Sabalausky wrote:
Out of curiosity, roughly how many, umm "characters" (I forget the technical
term for each T, G, etc), are in each yeast gene, and how many genes do they
have? (Humans have, umm, was it 26? My last biology class was ages ago.)
It varies massively,
"bearophile" wrote in message
news:ijpkh8$232r$1...@digitalmars.com...
> dsimcha:
>
>> Yeh, I rebuilt the same model in my head over the past few hours (like
>> you, I had a good mental model of the GC at one point but have slowly
>> forgotten it).
>
> For serious D programmers having such model
"dsimcha" wrote in message
news:ijp61d$1bu1$1...@digitalmars.com...
> On 2/19/2011 12:50 PM, Ulrik Mikaelsson wrote:
>> Just a thought; I guess the references to the non-GC-scanned strings
>> are held in GC-scanned memory, right? Are the number of such
>> references also increased linearly?
>
> W
"retard" wrote in message
news:ijp7pa$1d34$1...@digitalmars.com...
> Sat, 19 Feb 2011 14:32:27 -0500, dsimcha wrote:
>
>> On 2/19/2011 12:50 PM, Ulrik Mikaelsson wrote:
>>> Just a thought; I guess the references to the non-GC-scanned strings
>>> are held in GC-scanned memory, right? Are the numbe
dsimcha:
> Yeh, I rebuilt the same model in my head over the past few hours (like
> you, I had a good mental model of the GC at one point but have slowly
> forgotten it).
For serious D programmers having such model in the head is so important that
I'd like a short page with such explanations &
...and actually, forget() would only work for arrays of primitives,
because if the object has pointers, you can change what these point to
after calling forget() and Bad Things Can Happen.
On 2/19/2011 6:17 PM, dsimcha wrote:
Yeh, I rebuilt the same model in my head over the past few hours (li
Yeh, I rebuilt the same model in my head over the past few hours (like
you, I had a good mental model of the GC at one point but have slowly
forgotten it). Unfortunately it looks like there's no easy fix. It
also seems like gcbits are allocated as 1 bit for every 16 bytes of heap
space, no ma
On Sat, 19 Feb 2011 00:03:27 -0500, dsimcha wrote:
I've been trying out D's new 64-bit compiler and a serious barrier to
using it effectively seems to be abysmal garbage collection performance
with large heaps. It seems like the time for a garbage collection to run
scales linearly with the
On 2/19/2011 2:46 PM, Trass3r wrote:
Note: I know I could make the program in question a lot more space
efficient, and that's what I ended up doing. It works now. It's just
that it was originally written for yeast, where space efficiency is
obviously not a concern, and I would have liked to just
Sat, 19 Feb 2011 14:32:27 -0500, dsimcha wrote:
> On 2/19/2011 12:50 PM, Ulrik Mikaelsson wrote:
>> Just a thought; I guess the references to the non-GC-scanned strings
>> are held in GC-scanned memory, right? Are the number of such references
>> also increased linearly?
>
> Well, first of all, t
Note: I know I could make the program in question a lot more space
efficient, and that's what I ended up doing. It works now. It's just
that it was originally written for yeast, where space efficiency is
obviously not a concern, and I would have liked to just try a one-off
calculation on
On 2/19/2011 12:50 PM, Ulrik Mikaelsson wrote:
Just a thought; I guess the references to the non-GC-scanned strings
are held in GC-scanned memory, right? Are the number of such
references also increased linearly?
Well, first of all, the benchmark I posted seems to indicate otherwise.
Second o
Just a thought; I guess the references to the non-GC-scanned strings
are held in GC-scanned memory, right? Are the number of such
references also increased linearly?
I'm not a GC-expert, but if so, wouldn't that pretty much force the GC
to do at least one follow-up of every reference, before reali
You may be right, but:
1. Reinventing the wheel has its advantages in that you get to step
back and reevaluate things and remove all the cruft that built up on the
existing wheel.
2. I'm guessing this is a silly bug somewhere rather than a deep design
flaw, and that it can easily be solved
dsimcha:
> BTW, here are the timings if I remove the GC.BlkAttr.NO_SCAN, meaning
> that everything gets scanned. Said timings aren't drastically
> different. Something is seriously wrong here.
Languages like Clojure, Scala, Boo, etc, start their development on a virtual
machine where there i
BTW, here are the timings if I remove the GC.BlkAttr.NO_SCAN, meaning
that everything gets scanned. Said timings aren't drastically
different. Something is seriously wrong here.
Collected a 10 megabyte heap in 1 milliseconds.
Collected a 50 megabyte heap in 3 milliseconds.
Collected a 200 meg
I've been trying out D's new 64-bit compiler and a serious barrier to
using it effectively seems to be abysmal garbage collection performance
with large heaps. It seems like the time for a garbage collection to run
scales linearly with the size of the heap *even if most of the heap is
marked as
21 matches
Mail list logo
