http://d.puremagic.com/issues/show_bug.cgi?id=3463
Leandro Lucarella changed:
What|Removed |Added
CC||wfunct...@hotmail.com
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #133 from bearophile_h...@eml.cc 2013-03-08 11:48:39 PST ---
(In reply to comment #132)
> Did this actually get into 2.062?
I don't think so.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- Y
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Jameson changed:
What|Removed |Added
CC||beatgam...@gmail.com
--- Comment #132 from J
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #131 from David Simcha 2011-07-18 08:54:57 PDT
---
(In reply to comment #130)
> (In reply to comment #126)
> > Why not just add an additional garbage collector with this new
> > implementation
> > and leave the old one as it is an
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #130 from Trass3r 2011-07-18 06:10:29 PDT ---
(In reply to comment #126)
> Why not just add an additional garbage collector with this new implementation
> and leave the old one as it is and then developers can choose which one to us
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Trass3r changed:
What|Removed |Added
CC||mrmoc...@gmx.de
--- Comment #128 from Vladim
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #128 from Vladimir 2011-04-15 02:14:17
PDT ---
(In reply to comment #127)
Thank you for your insight!
> So from a game's developers point of I need to know when the GC will run
> either
> by configuration or by manually driving
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Sean Cavanaugh changed:
What|Removed |Added
CC||worksonmymach...@gmail.com
--- Commen
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Jacob Carlborg changed:
What|Removed |Added
CC||d...@me.com
--- Comment #126 from Jac
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #125 from Walter Bright 2011-04-14
20:33:11 PDT ---
(In reply to comment #120)
> I understand the advantages of a moving GC - heap compaction allowing for an
> overall smaller managed heap etc., but I hope you understand that sacri
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #124 from Walter Bright 2011-04-14
20:26:14 PDT ---
(In reply to comment #122)
> PS: Yeah, for some reason I still get the e-mails even when I removed myself
> from te Cc =/
Just when I thought I was out... they pull me back in!
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #123 from Vladimir 2011-04-14 20:09:13
PDT ---
(In reply to comment #121)
> Your case is a niche case and calls for a niche garbage collector
> implementation.
I would like to ask you to reconsider that opinion. Please take into
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Leandro Lucarella changed:
What|Removed |Added
CC||llu...@gmail.com
--- Comment #122
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #121 from David Simcha 2011-04-14 19:59:28 PDT
---
(In reply to comment #120)
> I understand the advantages of a moving GC - heap compaction allowing for an
> overall smaller managed heap etc., but I hope you understand that sacrif
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #120 from Vladimir 2011-04-14 19:50:08
PDT ---
(In reply to comment #118)
> > I hope it is as you say it is, but without benchmarks it's hard to say
> > anything, and this talk of state machines etc. is disconcerting.
>
> Why?
It
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #119 from David Simcha 2011-04-14 19:47:44 PDT
---
(In reply to comment #118)
> Also, even if the compiler emits the tables necessary for more precise gc, the
> gc implementation can ignore them and do it the old way. Emitting the
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #118 from Walter Bright 2011-04-14
19:34:40 PDT ---
(In reply to comment #117)
> I hope it is as you say it is, but without benchmarks it's hard to say
> anything, and this talk of state machines etc. is disconcerting.
Why?
Also,
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #117 from Vladimir 2011-04-14 19:06:29
PDT ---
(In reply to comment #116)
> Yes, they do. It's called the frame rate. (Though I'd guess to be technical,
> this a soft-realtime requirement.)
That's exactly what I meant. Hard realt
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #116 from Rob Jacques 2011-04-14 19:00:38 PDT ---
(In reply to comment #113)
> (In reply to comment #112)
> > Anything with hard realtime requirements cannot do allocation - even in
> > C/C++,
> > malloc() does not have an upper li
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #115 from Vladimir 2011-04-14 18:29:21
PDT ---
(In reply to comment #114)
> How about this: I can virtually guarantee that any slowness caused by precise
> heap scanning is more than offset by my recent patches (in Git but not in
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #114 from David Simcha 2011-04-14 18:23:13 PDT
---
(In reply to comment #113)
> (In reply to comment #112)
> > Anything with hard realtime requirements cannot do allocation - even in
> > C/C++,
> > malloc() does not have an upper
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #113 from Vladimir 2011-04-14 18:00:14
PDT ---
(In reply to comment #112)
> Anything with hard realtime requirements cannot do allocation - even in C/C++,
> malloc() does not have an upper limit on its time.
>
> What is done is to
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #112 from Walter Bright 2011-04-14
17:48:22 PDT ---
(In reply to comment #110)
> And allocating heap memory (for objects, structs, dynamic
> arrays, closures, array concatenations, etc) between two frames of a fast
> video
> game
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #111 from Vladimir 2011-04-14 17:44:29
PDT ---
(In reply to comment #110)
> Because currently the GC gets called when you allocate heap memory.
Thanks for teaching me how garbage collectors work. I had no idea:
http://thecybersha
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #110 from bearophile_h...@eml.cc 2011-04-14 17:36:47 PDT ---
(In reply to comment #109)
> (In reply to comment #108)
> > That's why heap allocations in real-time code are a bad idea. This patch
> > won't
> > change that.
>
> Um, n
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #109 from Vladimir 2011-04-14 17:11:02
PDT ---
(In reply to comment #108)
> That's why heap allocations in real-time code are a bad idea. This patch
> won't
> change that.
Um, no, the GC is currently fast enough to scan a small
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #108 from David Simcha 2011-04-14 17:08:48 PDT
---
(In reply to comment #107)
> Am I the only one who is concerned with the performance implications of
> complicating the garbage collector any further, especially considering that
>
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Vladimir changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #107 f
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #106 from Walter Bright 2011-04-14
16:25:11 PDT ---
(In reply to comment #105)
> I think it's just a simple idea. You do generate code for constructors etc.
> already...
The main challenge would be finding the fastest interface fo
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #105 from Andrei Alexandrescu 2011-04-14
16:00:24 PDT ---
(In reply to comment #104)
> (In reply to comment #103)
> > I was thinking that the compiler could generate D code that does the
> > scanning
> > instead of us defining a D
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #104 from Walter Bright 2011-04-14
15:47:25 PDT ---
(In reply to comment #103)
> I was thinking that the compiler could generate D code that does the scanning
> instead of us defining a DSL for that.
That's a fascinating idea.
--
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #103 from Andrei Alexandrescu 2011-04-14
15:08:15 PDT ---
(In reply to comment #102)
> (In reply to comment #100)
> > (In reply to comment #99)
> > > (In reply to comment #98)
> > > > The work on improving introspection should be d
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #101 from Walter Bright 2011-04-14
14:46:52 PDT ---
(In reply to comment #96)
> Anyway, this problem is taking care of in the implementation by nfxjfg,
His bitmap implementation consists of two bitmaps, one for all pointers and th
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #102 from Walter Bright 2011-04-14
14:49:49 PDT ---
(In reply to comment #100)
> (In reply to comment #99)
> > (In reply to comment #98)
> > > The work on improving introspection should be done anyway.
> >
> > The trouble with usi
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #100 from Andrei Alexandrescu 2011-04-14
14:03:26 PDT ---
(In reply to comment #99)
> (In reply to comment #98)
> > The work on improving introspection should be done anyway.
>
> The trouble with using runtime introspection for th
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #99 from Walter Bright 2011-04-14
13:50:21 PDT ---
(In reply to comment #98)
> The work on improving introspection should be done anyway.
The trouble with using runtime introspection for this is it'll be slow, and the
scanning of
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #98 from Andrei Alexandrescu 2011-04-14
13:45:23 PDT ---
Though I understand its attractiveness, I oppose the state machine approach
because it is hopelessly specific. After taking to completion this nontrivial
task we'll have (a)
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #97 from Andrei Alexandrescu 2011-04-14
13:00:36 PDT ---
(In reply to comment #96)
> (In reply to comment #95)
> > (In reply to comment #94)
> > >
> > > I think that covers things, except for handling ambiguous pointers.
> >
> >
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #96 from Leandro Lucarella 2011-04-14 12:32:49
PDT ---
(In reply to comment #95)
> (In reply to comment #94)
> >
> > I think that covers things, except for handling ambiguous pointers.
>
> Can you explain why we care about ambigu
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #95 from Steven Schveighoffer 2011-04-14
12:25:48 PDT ---
(In reply to comment #94)
>
> I think that covers things, except for handling ambiguous pointers.
Can you explain why we care about ambiguous pointers? That is, shouldn't
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #94 from Walter Bright 2011-04-14
11:54:00 PDT ---
(In reply to comment #92)
> This is roughly what I did in my initial patches. The comments at the top of
> the file describe it in more detail. See
> http://d.puremagic.com/issue
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #93 from Leandro Lucarella 2011-04-14 06:21:29
PDT ---
You can take a look at my concurrent D GC (CDGC), which is also precise. It is
based on the work done by nfx...@gmail.com (which is based on the work done by
David Simcha).
He
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #92 from David Simcha 2011-04-14 06:04:04 PDT
---
(In reply to comment #91)
> Yes and no. Consider right now (although I think David fixed this), we
> allocate a bit for every 16 bytes of a page, even if the whole page is a
> blo
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #90 from bearophile_h...@eml.cc 2011-04-14 03:58:52 PDT ---
(In reply to comment #89)
> (In reply to comment #88)
>
> In order to support C compatibility, untagged unions must be supported by the
> type system and the GC.
Right, bu
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #89 from Walter Bright 2011-04-14
02:23:28 PDT ---
(In reply to comment #88)
In order to support C compatibility, untagged unions must be supported by the
type system and the GC.
--
Configure issuemail: http://d.puremagic.com/is
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #88 from bearophile_h...@eml.cc 2011-04-14 02:06:33 PDT ---
(In reply to comment #87)
> 1. distinguishing real pointers from might-be-a-pointer (such as you might get
> from union { int a; void* p; }).
In C unions are not tagged, b
http://d.puremagic.com/issues/show_bug.cgi?id=3463
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #86 from Leandro Lucarella 2010-11-15 09:44:18
PST ---
(In reply to comment #85)
> (In reply to comment #84)
>
> > I (and others) already suggested him how to improve things,
>
> Keep suggesting those things. Sometimes you have t
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #85 from bearophile_h...@eml.cc 2010-11-15 09:33:56 PST ---
(In reply to comment #84)
> I (and others) already suggested him how to improve things,
Keep suggesting those things. Sometimes you have to say something five times to
Wal
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #84 from Leandro Lucarella 2010-11-15 04:47:48
PST ---
(In reply to comment #83)
> (In reply to comment #82)
>
> > Anyway, unfortunately DMD development model still sucks, it sucks much less
> > than... let's say 2 years ago, but.
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #83 from bearophile_h...@eml.cc 2010-11-15 04:43:23 PST ---
(In reply to comment #82)
> Anyway, unfortunately DMD development model still sucks, it sucks much less
> than... let's say 2 years ago, but...
Walter is willing to slowly
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #82 from Leandro Lucarella 2010-11-14 19:17:59
PST ---
Maybe you should try with LDC's or GDC's issues trackers, as this is an
implementation detail maybe it gets better reception there (but it would be
hard to get accepted there s
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #81 from nfx...@gmail.com 2010-11-14 18:06:05 PST ---
I obsoleted all the patches because they were outdated (too old dmd/Tango
versions). I don't think it's very efficient to make new patches and post them
here (I mean, there are al
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #80 from nfx...@gmail.com 2010-09-16 11:26:43 PDT ---
By the way, if the patch is going to be accepted, it would probably be good to
get rid of the NO_SCAN flags. Instead, NO_SCAN should be detected by examining
the PointerMap. A Poi
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #79 from nfx...@gmail.com 2010-09-15 06:33:39 PDT ---
Incremental patch:
diff --git a/tango/core/rt/gc/basic/gcx.d b/tango/core/rt/gc/basic/gcx.d
index 93c8078..0f049d7 100644
--- a/tango/core/rt/gc/basic/gcx.d
+++ b/tango/core/rt/g
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #78 from Leandro Lucarella 2010-09-15 05:51:08
PDT ---
(In reply to comment #77)
> There's a small bug in the memory clearing in mallocNoSync(), that could cause
> memory leaks. Will post patch on request (nobody is using this anyw
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #77 from nfx...@gmail.com 2010-09-15 02:22:03 PDT ---
There's a small bug in the memory clearing in mallocNoSync(), that could cause
memory leaks. Will post patch on request (nobody is using this anyway, right?).
Also, I found out t
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #488 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #75 from nfx...@gmail.com 2010-09-09 06:43:43 PDT ---
Created an attachment (id=754)
tango: enable precise scanning for AAs
This is the Tango patch that goes with the dmd patch (attachment 753). The AA
implementation is duplicated b
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #74 from nfx...@gmail.com 2010-09-09 06:41:46 PDT ---
Created an attachment (id=753)
dmd: enable precise scanning for AAs
AAs are special because they use some runtime mechanism. dmd didn't allow
precise scanning because not all typ
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #739 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #737 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #700 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #70 from nfx...@gmail.com 2010-08-24 01:40:52 PDT ---
Created an attachment (id=738)
experiment: use ClassInfo to get bitmask for object allocations
objbitmask.patch is a patch on top of tango_precise_gc.patch, which makes
storing t
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #701 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #68 from Leandro Lucarella 2010-08-15 07:24:36
PDT ---
More analysis on wasted space (for the current GC and for the precise patch)
here:
http://www.llucax.com.ar/blog/blog/post/098ceae8
--
Configure issuemail: http://d.puremagic
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #67 from Leandro Lucarella 2010-08-08 08:10:19
PDT ---
Sor(In reply to comment #66)
> > http://www.llucax.com.ar/blog/blog/post/1490c03e
>
> That page shows me a spectacularly complex page of Python error messages.
Sorry about th
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #66 from bearophile_h...@eml.cc 2010-08-08 06:03:55 PDT ---
> http://www.llucax.com.ar/blog/blog/post/1490c03e
That page shows me a spectacularly complex page of Python error messages.
--
Configure issuemail: http://d.puremagic.co
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #65 from Leandro Lucarella 2010-08-07 22:19:43
PDT ---
This blog post might be of interesting for this bug report:
http://www.llucax.com.ar/blog/blog/post/1490c03e
Specially for comment 55 and comment 56.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #64 from Leandro Lucarella 2010-07-28 13:04:07
PDT ---
(In reply to comment #62)
> (In reply to comment #61)
> > Even when I agree that the GC needs a lot of refactoring, I don't think
> > it's a
> > good idea to include it in thi
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #63 from Leandro Lucarella 2010-07-28 12:57:35
PDT ---
(In reply to comment #60)
>- explicitly support SENTINEL (I have no idea why the code apparently
> worked
> with SENTINEL enabled; at least it should have messed up the bi
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #62 from nfx...@gmail.com 2010-07-28 12:49:49 PDT ---
(In reply to comment #61)
> Even when I agree that the GC needs a lot of refactoring, I don't think it's a
> good idea to include it in this patch, it makes much harder to underst
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #61 from Leandro Lucarella 2010-07-28 12:23:01
PDT ---
(In reply to comment #60)
> Created an attachment (id=701) [details]
> D1 - patch for Tango's runtime to enable precise GC scanning
>
> - lots of nasty refactoring in gcx.d:
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #696 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #698 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #58 from Leandro Lucarella 2010-07-27 21:23:34
PDT ---
And another small comment about the Tango runtime patch, you add a binSize()
function, but there is already a binsize[] array for the same purpose, you can
remove the binSize(b
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #57 from Leandro Lucarella 2010-07-27 21:19:01
PDT ---
I think there is a not-so-important bug in the DMD patch, the bits.length value
looks like it needs to be divided by size_t.sizeof (which is odd, since in the
patch it looks li
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #56 from Leandro Lucarella 2010-07-26 06:40:21
PDT ---
(In reply to comment #55)
> If/when this makes it into D2 I'm going to store the info in a parallel array
> kind of like the bits are.
Will you store a pointer to the pointer
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #55 from Sean Kelly 2010-07-25 20:45:32
PDT ---
If/when this makes it into D2 I'm going to store the info in a parallel array
kind of like the bits are.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=emai
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #54 from Leandro Lucarella 2010-07-25 19:47:26
PDT ---
(In reply to comment #53)
> Created an attachment (id=698) [details]
> D1 - patch for dmd for creating pointer bitmasks
>
> Some changes to make the patch behave under 64 bit
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #695 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #52 from Leandro Lucarella 2010-07-25 18:45:10
PDT ---
OK, here is the other side of the coin, a small fabricated benchmark (actually
stolen from the NG, sightly modified by me to make false pointers much more
likely):
// Written
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #51 from Leandro Lucarella 2010-07-25 18:10:01
PDT ---
(In reply to comment #48)
> Here are the profiling results (using perf[1]):
> Non-precise scanning: http://pastebin.com/zRKyc9mW
> Precise scanning: http://pastebin.com/jPJ
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #50 from Leandro Lucarella 2010-07-25 17:30:20
PDT ---
(In reply to comment #48)
> It looks like findPool() might be used much more often than before? For
> example, I noticed the mixin code calls findPool() very early, so maybe it
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #49 from nfx...@gmail.com 2010-07-25 17:21:10 PDT ---
@Leandro:
Thanks for doing these tests!
In D1, the runtime calls gc_query on _every_ array append operation. Though the
cache in Gcx.getInfo() speeds it up a bit. But it doesn't
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #48 from Leandro Lucarella 2010-07-25 17:04:56
PDT ---
Well timings for dil are much worse :(
This is dil generating the Tango docs, without precise scanning (dmd with the
last patch, Tango unpatched):
52.01
53.73
52.21
51.79
50.5
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #47 from Leandro Lucarella 2010-07-25 13:43:10
PDT ---
(In reply to comment #46)
> As far as the (small) drop in mean performance, I say "who cares?". In
> practice, once false pointers start eating you alive and the heap gets
> u
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #46 from David Simcha 2010-07-25 09:07:00 PDT
---
As far as the (small) drop in mean performance, I say "who cares?". In
practice, once false pointers start eating you alive and the heap gets
unnecessarily huge, everything memory
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #45 from Leandro Lucarella 2010-07-24 20:08:30
PDT ---
Well, I've made a little benchmark for the patch.
I'm using the voronoi[1] benchmark, since I think is a good GC benchmark,
because it exercises the GC a lot, but it does real
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #44 from Leandro Lucarella 2010-07-23 12:15:44
PDT ---
(In reply to comment #43)
> You're right, there seem to be some places where the bitmask size is added or
> substracted twice. I don't really know; I took that code over from d
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #43 from nfx...@gmail.com 2010-07-23 11:39:19 PDT ---
You're right, there seem to be some places where the bitmask size is added or
substracted twice. I don't really know; I took that code over from dsimcha's
patch without modificati
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #693 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
nfx...@gmail.com changed:
What|Removed |Added
Attachment #692 is|0 |1
obsolete|
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #40 from Leandro Lucarella 2010-07-22 20:26:48
PDT ---
Also, I think queryNoSync() subtract the bitmask size twice, because getInfo()
already subtract it from the block size.
--
Configure issuemail: http://d.puremagic.com/issues/
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #38 from Leandro Lucarella 2010-07-22 19:26:36
PDT ---
If I'm understanding the patch right, I think I found a bug. At the end of
reallocNoSync():
+if (psize < size || // if new size is bigger
+
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #39 from Leandro Lucarella 2010-07-22 19:27:29
PDT ---
(In reply to comment #38)
> If I'm understanding the patch right, I think I found a bug. At the end of
> reallocNoSync():
>
> +if (psize < size || // i
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #37 from Leandro Lucarella 2010-07-22 17:54:38
PDT ---
BTW, I just realized that this type information scheme doesn't enable the GC to
move data around (i.e. it doesn't open the door to moving collectors) since the
distinction betw
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #36 from nfx...@gmail.com 2010-07-21 12:05:08 PDT ---
I guess we will have to see how Walter's 64 bit port will look like.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #35 from Leandro Lucarella 2010-07-21 11:59:40
PDT ---
(In reply to comment #34)
> I don't really use D2 (all my code is in D1). Porting it to D2 will require
> dealing with the recently added array append stuff. Not sure how hard
1 - 100 of 134 matches
Mail list logo
