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,
"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
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
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
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
13 matches
Mail list logo