On Monday, 18 August 2014 at 07:44:14 UTC, Joakim wrote:
> Nice, though I don't know how fair it is to have a university professor take part in such a contest. ;)

The contest is open for everyone.  For example, Tomas Rokicki (one of the previous contests' winners) is a member of the "God's number is 20" band (see http://www.cube20.org/).  Besides, formally speaking, I don't have a PhD.

> It would be good if you could expand on your thoughts on D from part 11 of your technical report and post it somewhere, so that others can learn from your experience.

Another notably useful feature for such applications is the scope statement.  It is generally useful for any complex search recursively iterating over changes to combinatorial objects.  My contest code gives a count of 65 to a "grep 'scope (exit)' | wc" command.

Again, with the scrabble board example, a play is constructed recursively: we put a letter from the rack into some cell and move towards the next cell.  In code:

play (row,col):
 1. check if we have a word
 ...
 2. put letter to (row,col)
 3. remove letter from the rack
 4. recursively call play (row,col+1)
 ... and whatnot ...
 5. erase letter from (row,col)
 6. restore letter in the rack

As the code gets complex, the semantic dependence between lines 2-3 and lines 5-6 (the latter canceling out the former) may suffer from the blocks moving further apart, preliminary returns from the function appearing in between, and  needing a change to the blocks.  With scope statement, they can be kept close together, and are guaranteed to work if a preliminary return occurs.  Again in pseudocode:

play (row,col):
 1. check if we have a word
 ...
 2. put letter to (row,col)
 3. remove letter from the rack
 scope (exit):
     5. erase letter from (row,col)
     6. restore letter in the rack
 4. recursively call play (row,col+1)
 ... and whatnot ...

-----

Indeed, you seem to be right that these points can be converted to a text of some interest to general audience.  But that's a task for a few weeks later, as I'm busy with other stuff until the beginning of September.

Ivan Kazmenko.

On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:
> On 08/18/2014 03:11 AM, Ivan Kazmenko wrote:
>
> > my program usually hit an out-of-memory error very soon.  It
> > worked fine when compiled with 64-bit DMD but failed to
> collect
> > the garbage in time with 32-bit DMD and with recent LDC.
>
> That sounds like a false pointer issue. D's current GC is conservative: It takes any value that could be a pointer as a pointer and persists the memory that is falsely being pointed at.
>
> The problem becomes 2^^32 times less likely when pointers are 64-bit wide.

Hmm, that might be it, thank you for the tip.

I suppose there is a way to disable scanning certain parts of memory for possible pointers.  Still, the core.memory documentation speaks a lower-level language than I'm currently familiar with.  A quick look on your book's memory management chapter provided some explanation but still didn't enlighten me on this specific problem.

It looks like I want to have most of my data under something like GC.BlkAttr.NO_SCAN.  But I don't yet see a clean way to introduce something like that in the code.  It seems like I want a custom allocator, but various pages show they existed in D1 and are now deprecated in D2.  And perhaps there is also a granularity problem: I have classes containing structs and structs pointing to classes, so struct data (single bytes to hundreds of bytes) lies next to class pointers most of the time.

So, is there a tutorial on how to better hint the D garbage collector?

Ivan Kazmenko.

On Tuesday, 19 August 2014 at 17:19:40 UTC, Ivan Kazmenko wrote:
> Indeed, you seem to be right that these points can be converted to a text of some interest to general audience.  But that's a task for a few weeks later, as I'm busy with other stuff until the beginning of September.

No hurry.  Put some thought into how D actually helped you win and I think whatever you write would be a nice showcase for the language.  Looking forward to reading it. :)

On Tuesday, 19 August 2014 at 17:39:13 UTC, Ivan Kazmenko wrote:
>
> It looks like I want to have most of my data under something like GC.BlkAttr.NO_SCAN.  But I don't yet see a clean way to introduce something like that in the code.

GC.BlkAttr.NO_INTERIOR can also be useful for eliminating false pointers pointing into large structures. It only works when you know that there is always a pointer to the base of the object while it is "alive."

N.B. That attribute is ignored for small allocations.

On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:
> On 08/18/2014 03:11 AM, Ivan Kazmenko wrote:
>
> > my program usually hit an out-of-memory error very soon.  It
> > worked fine when compiled with 64-bit DMD but failed to
> collect
> > the garbage in time with 32-bit DMD and with recent LDC.
>
> That sounds like a false pointer issue. D's current GC is conservative: It takes any value that could be a pointer as a pointer and persists the memory that is falsely being pointed at.
>
> The problem becomes 2^^32 times less likely when pointers are 64-bit wide.
>
> Ali

http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/