On Tuesday, 24 February 2015 at 13:07:38 UTC, Tobias Pankrath
wrote:
On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo Pinto
wrote:
Sorry about the caps, couldn't find a better way to emphasis.
Not sure where you found out the information about x86, or why
it should matter.
I found an (apparently older) version of the documentation
earlier that looked exactly the same, so I didn't mind to read
your link carefully enough.
"The current collector is, by default, INCREMENTAL and
GENERATIONAL. The interruptions of service should be very
small, and the overall performance should be better than with
the previous collectors."
Yes, however from your page now:
Now @M3novm is the default.
And if you follow the link:
@M3novm implies @M3noincremental and @M3nogenerational.
Maybe, that's an documentation error. This was the place where
the other version
mentioned that x86 is not supported.
While I like that you constantly remind us about achievements
of older programming languages, you'll often do it with a "that
problem was solved in Language X 20 years ago"-attitude, but
almost never elaborate how that solution could be applied to D.
When taking a closer look, I often find that those languages
solved an similar but different problem and the solution do not
apply to D at all. For example the last time in the discussion
on separate compilation, templates and object files you blamed
the C tool chain and pointed to pascal/delphi. But they didn't
solved the problem, because they didn't faced it in the first
place, because they didn't had the template and
meta-programming capabilities of D.
Yes I agree with you, it is just that I would like to see a
language like D being adopted at large, so as a language geek
that has spent too much time in language research during the
compiler design classes, I like to pull this information out of
the attic.
When knowledge goes away people get other understanding of the
reality, for example, many young developers think C was the very
first systems programming language, which isn't the case given
the research going on outside AT&T.
I am well aware that those solutions don't cover 100% D's use
cases, but maybe they have enough juice to provide ideas in D
context.
It is always a matter of research and funding for the said ideas.
If I was at academia, applying these ideas to improve D would be
a good source for papers and thesis. As such, I cannot do much
more than throw them over the wall and see if they can inspire
someone.
At the problem at hand: I don't see how Module3's distinction
between system and default pointer types or the lessons they
learned help in any way to improve the current D GC.
It helps reduce the pressure in the GC allocated memory, and also
allows for giving pointers straight to external code.
Maybe given the type of implicit allocations in D vs Modula-3, it
doesn't help.
But yeah, too much noise from a D dabbler I guess.
--
Paulo
