Am 09.01.2014 20:40, schrieb H. S. Teoh:
> On Thu, Jan 09, 2014 at 07:01:59PM +0000, Sean Kelly wrote:
>> On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
> [...]
>>> Manual memory management is a LOT of effort, and to be quite
>>> honest, unless you're writing an AAA 3D game engine, you don't
>>> *need* that last 5% performance improvement that manual memory
>>> management *might* gives you. That is, if you get it right. Which
>>> most C/C++ coders don't.
>>
>> The other common case is server apps, since unpredictable delays
>> can be quite undesirable as well.  Java seems to mostly get
>> around this by having very mature and capable GCs despite having
>> a standard library that wants you to churn through memory like
>> pies at an eating contest.  The best you can do with D so far is
>> mostly to just not allocate whenever possible, by slicing strings
>> and such, since scanning can still be costly.  I think there's
>> still some work to do here, despite loving the GC as a general
>> feature.
>
> I think we all agree that D's GC in its current state needs a lot of
> improvement. While I have come to accept GCs as a good thing, that
> doesn't mean that D's current GC is *that* good. Yet. I wish I had the
> know-how (and the time!) to improve D's GC, because if D can get a GC
> that's on par with Java's, then D can totally beat Java flat, since the
> existence of value types greatly reduces the memory pressure on the GC,
> so the GC will have much less work to do compared to an equivalent Java
> program.
>
> OTOH, even with D's suboptimal GC, I'm already seeing great productivity
> gains at only a low cost, so that's a big thumbs up for GC's. And the
> nice thing about being able to call malloc from D (which you can't in
> Java) means you can still do manual memory management in critical code
> sections when you need to squeeze out some extra performance.
>
>
> T
>

Well, there are a few options to call malloc from Java:

- Do you own JNI wrapper
- Use Java Native Access
- Use Java Native Runtime
- Use NIO Buffers
- Use sun.misc.Unsafe.allocateMemory (sun.misc.Unsafe is planned to become a public API)

--
Paulo

On Thursday, 9 January 2014 at 19:41:43 UTC, H. S. Teoh wrote:
> because if D can get a GC
> that's on par with Java's, then D can totally beat Java flat, since the
> existence of value types greatly reduces the memory pressure on the GC,
> so the GC will have much less work to do compared to an equivalent Java
> program.

Java will probably gain (something like) value types at some point. Google for "packed objects", it provides similar gains as value types.

Hopefully, D gets a better GC first.

On Thursday, 9 January 2014 at 19:16:10 UTC, Paulo Pinto wrote:
> Every time I see such discussions, it reminds me when I started coding in the mid-80s and the heresy of using languages like Pascal and C dialects for microcomputers, instead of coding everything in Assembly or Forth

If you insist on bringing up heresy...

Motorola 680xx is pretty nice compared to x86, although the AMD64bit mode is better than it was. 680xx feels almost like C, just better ;9, I think only MIPS is close in programmer friendlieness.  Forth is nice too, very minimalistic and quite powerful for the simplistic implementation. I had a Forth64 module for my C64 to dabble with, a bit hard to create more than toy programs in Forth... Postscript is pretty close actually, and clean. But Forth is dense, so dense that you don't edit text files, you edit text screens...  But don't diss assembly, try to get more than 8 sprites and move sprites into the screen border without assembly, can't be done! High level languages, my ass, BASIC can't do that!

But hey, I am not arguing in favour of Forth and C (although I would argue in favour of 680xx and MIPS). I am arguing in favour of smart compilers that allow you to go low level at the top of the call stack where it matters (inner loops) without having to resort to a different language. D is close to that, so it is a promising candidate.

And... I actually think D is too lax in some areas. I don't think you should be allowed to call C/C++ without nailing down the pre/postconditions, basically describing what happens in terms of optimization constraints. I also want the programmer to be able to assert facts that the compiler fail to prove so that it can be used for optimization. Basically the ability to guide the optimizer so you don't have to resort to low level coding. I also think giving access to malloc is a bad idea. :-P

And well, I am not new to GC, I have actually used Simula quite a bit in classes/teaching newbies. Simula incidentally has exactly the same Garbage Collector that D has AFAIK.  I remember we had a 1970s internal memo describing the garbage collector of Simula on the curriculum of the compiler course... So that is veeeery old news.

Actually Simula kinda has the same kind of string type representation that D has too. And OO. And it has coroutines… While it doesn't have templates, it does actually have name parameters that has textual substitution semantics (in addition to ref and value). Now I also kinda like that it has ":-" for reference assignment and ":=" for value assignment, but I didn't like it back then.

45 years later D merge Simula semantics with C (and some more stuff). And that is an interesting thing, of course.

But hey, no point in pretending that other people don't know what programming a GC high level language entails. If I want low latency, I go to C/C++ and hopefully D. If I want high level productivity I use whatever fits the bill… all GC languages. But I don't think D should be the first option in any non-speed area yet, so the GC is of limited use for now IMO. (In clusters you might want that though, speed+convenience but no need for low latency.)

I think D could pick up more good stuff from Python, like the array closures that allows you to succinctly transform arrays. Makes large portions of Python's standard library pointless.

What I really like about D is that the front end code appears to be quite readable. Take a look at clang and you will see the difference. So, I guess anyone with C++ knowledge has the opportunity to tune both syntax and semantics to their own liking and share it with others. That's pretty sweet (I'd like to try that one day).

On Thursday, 9 January 2014 at 22:02:48 UTC, Ola Fosheim Grøstad
wrote:
> What I really like about D is that the front end code appears to be quite readable. Take a look at clang and you will see the difference. So, I guess anyone with C++ knowledge has the opportunity to tune both syntax and semantics to their own liking and share it with others. That's pretty sweet (I'd like to try that one day).

This definitively convinced me that you must be very high on
drugs.

On Thursday, 9 January 2014 at 22:15:18 UTC, deadalnix wrote:
> This definitively convinced me that you must be very high on
> drugs.

Why is that? I have browsed the repositories and had no problems figuring out what was going on from what I read. I don't understand all the interdependencies of course, but making small changes should not be a big deal from what I've seen.

On Thursday, 9 January 2014 at 21:35:45 UTC, qznc wrote:
> On Thursday, 9 January 2014 at 19:41:43 UTC, H. S. Teoh wrote:
>> because if D can get a GC
>> that's on par with Java's, then D can totally beat Java flat, since the
>> existence of value types greatly reduces the memory pressure on the GC,
>> so the GC will have much less work to do compared to an equivalent Java
>> program.
>
> Java will probably gain (something like) value types at some point. Google for "packed objects", it provides similar gains as value types.
>
> Hopefully, D gets a better GC first.

What's the status of all that? There were interesting talks at DConf 2013 about precise and concurrent GCs, and it seemed that work was going on to fold all that into the compilers, and that Walter/Andrei were ready to make changes to the spec and runtime if needed to support precise GC. All very encouraging.

Will DMD have a precise GC by the next DConf?

-- Brian

On 08/01/14 21:22, Paulo Pinto wrote:
> As I shared a few times here, it was Oberon which opened my eyes
> to GC enabled systems programming languages, around 1996, maybe.

What was the GC design for Oberon, and how does that relate to what's in D (and what's in other GC'd languages)?

On Thu, Jan 09, 2014 at 10:51:22PM +0000, Brian Rogoff wrote:
> On Thursday, 9 January 2014 at 21:35:45 UTC, qznc wrote:
> >On Thursday, 9 January 2014 at 19:41:43 UTC, H. S. Teoh wrote:
> >>because if D can get a GC that's on par with Java's, then D can totally beat Java flat, since the existence of value types greatly reduces the memory pressure on the GC, so the GC will have much less work to do compared to an equivalent Java program.
> >
> >Java will probably gain (something like) value types at some point. Google for "packed objects", it provides similar gains as value types.
> >
> >Hopefully, D gets a better GC first.
> 
> What's the status of all that? There were interesting talks at DConf 2013 about precise and concurrent GCs, and it seemed that work was going on to fold all that into the compilers, and that Walter/Andrei were ready to make changes to the spec and runtime if needed to support precise GC. All very encouraging.
> 
> Will DMD have a precise GC by the next DConf?
[...]

Has *anything* been done on the GC at all since the previous DConf? Not trying to be provocative, just genuinely curious if anything has been happening on that front, since I don't remember seeing any commits in that area all year.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On 1/9/2014 3:29 PM, H. S. Teoh wrote:
> Has *anything* been done on the GC at all since the previous DConf? Not
> trying to be provocative, just genuinely curious if anything has been
> happening on that front, since I don't remember seeing any commits in
> that area all year.

Not much.

On Thursday, 9 January 2014 at 23:02:57 UTC, Joseph Rushton Wakeling wrote:
> On 08/01/14 21:22, Paulo Pinto wrote:
>> As I shared a few times here, it was Oberon which opened my eyes
>> to GC enabled systems programming languages, around 1996, maybe.
>
> What was the GC design for Oberon, and how does that relate to what's in D (and what's in other GC'd languages)?

The original Oberon was a simple mark and sweep collector. Initially implemented in Assembly. In later versions it was coded in Oberon itself.

Original 1992/2005 edition
http://www.inf.ethz.ch/personal/wirth/ProjectOberon1992.pdf

2013 edition with images of the workstations were Oberon ran
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf

EthOS used a mark and sweep GC with support for weak pointers and finalization. Running when the system was idle or when not enough memory was available.

http://research.microsoft.com/en-us/um/people/cszypers/books/insight-ethos.pdf

Active Oberon implementation used a mark and sweep with finalization support.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.5753&rep=rep1&type=pdf

Modula-3 used a compacting GC initially, with an optional background one.

https://modula3.elegosoft.com/cm3/doc/help/bib.html
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.6890

Cedar used a concurrent reference-counting collector, coupled with a mark and sweep one for cycle removals, with finalization support

http://www.textfiles.com/bitsavers/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf

The features are quite similar to D:

- GC
- Allocation of data structures statically in global memory and stack
- Escape hatches to allocate memory manually when needed

I cannot say if they also allow for interior pointers like D does.

However the main point about Oberon and other languages wasn't only technical, but human. Funny enough that is also Andrew Koening's latest post

http://www.drdobbs.com/cpp/social-processes-and-the-design-of-progr/240165221

The people designing such systems believed that it was possible to write from the ground up a workstation operating system in a GC enabled systems programming language, with minimal Assembly.

They did succeed and built workstations that were usable for normal office work, which were then used at ETHZ, Xerox and Olivetti for some time.

For games, some more effort would be required I do acknowledge that.

However the world at large, ignored these efforts. As Andrew nicely puts on his article, many times the social barrier is higher than the technical one.

For many developers hearing the GC word, safe coding, bounds checking is enough to make them run away as fast as they can.

--
Paulo