On 2/25/2015 6:57 PM, deadalnix wrote:
> You seems to avoid the important part of my message : write barrier tend to be
> very cheap on immutable data. Because, as a matter of fact, you don't write
> immutable data (in fact you do to some extent, but the amount of write is minimal.
>
> There is no reason not to leverage this for D, and java comparison are
> irrelevant on the subject as java does not have the concept of immutability.
>
> The same way, we can use the fact that TL data are not supposed to refers to
> each others.

Of course, you don't pay a write barrier cost when you don't write to data, whether it is immutable or not is irrelevant.

On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright wrote:
> On 2/25/2015 7:27 PM, deadalnix wrote:
>> On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
>>> Writing a generational collector for D is possible right now with no language
>>> changes, it's just that nobody has bothered to do it. Don't need write
>>> barriers for it, either.
>> How are you planning to track assignment a pointer to the young generation in
>> the old generation ? Because if you plan to rescan the whole old generation,
>> this is not exactly a generational GC.
>
> A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory.

Is this implying you've begun work on a compacting D collector, or are you relating to your Java experiences?

On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright wrote:
> On 2/25/2015 7:27 PM, deadalnix wrote:
>> On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
>>> Writing a generational collector for D is possible right now with no language
>>> changes, it's just that nobody has bothered to do it. Don't need write
>>> barriers for it, either.
>> How are you planning to track assignment a pointer to the young generation in
>> the old generation ? Because if you plan to rescan the whole old generation,
>> this is not exactly a generational GC.
>
> A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory.

That's is not answering the question at all.

On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright wrote:
> On 2/25/2015 6:57 PM, deadalnix wrote:
>> You seems to avoid the important part of my message : write barrier tend to be
>> very cheap on immutable data. Because, as a matter of fact, you don't write
>> immutable data (in fact you do to some extent, but the amount of write is minimal.
>>
>> There is no reason not to leverage this for D, and java comparison are
>> irrelevant on the subject as java does not have the concept of immutability.
>>
>> The same way, we can use the fact that TL data are not supposed to refers to
>> each others.
>
> Of course, you don't pay a write barrier cost when you don't write to data, whether it is immutable or not is irrelevant.

It DOES matter as user tends to write way more mutable data than immutable ones. Pretending otherwise is ridiculous.

Am 26.02.2015 um 05:08 schrieb Walter Bright:
> On 2/25/2015 7:27 PM, deadalnix wrote:
>> On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
>>> Writing a generational collector for D is possible right now with no
>>> language
>>> changes, it's just that nobody has bothered to do it. Don't need write
>>> barriers for it, either.
>> How are you planning to track assignment a pointer to the young
>> generation in
>> the old generation ? Because if you plan to rescan the whole old
>> generation,
>> this is not exactly a generational GC.
>
> A lot of benefit simply came from compacting all the remaining used
> allocations together, essentially defragging the memory.

What you are describing is a compacting GC and not a generational GC. Please just describe in words how you would do a generational GC without write barriers. Because just as deadalnix wrote, the problem is tracking pointers within the old generation that point to the new generation.

On Wed, 2015-02-25 at 18:48 -0800, Walter Bright via Digitalmars-d wrote:
> On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:
> > […]
> >
> > Do you have data to back that up?
> 
> I've written a Java compiler and and a GC for the Java VM (for Symantec, back in the 90's.). I'm familiar with the code generated for Java, and the code generated for D.

Have you studied the G1 GC? Any "data" from the 1990 regarding Java, and indeed any other programming language with a lifespan of 20+years, is suspect, to say the least. Also what is said above is not data, it is opinion.

All too often in these mailing lists, performance issues are argued with pure opinion and handwaving, not to mention mud-slinging. There should be a rule saying that no-one, but no-one, is allowed to make any claims about anything to do with performance without first having actually done a proper experiment and presented actual real data with statistical analysis.

Nigh on every GC-related comment in this thread has been a waste of time reading. It must therefore have been a waste of time writing. Time that could have been used doing something constructive. Perhaps the benchmark module now has a lot of resource able to move it to being a tool for making experiments to answer the questions with data rather than unfounded opinion.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright wrote:
> On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
>> It does annoy me that I can't comment on the exceptions case,
>
> ...
>
>> COM is also an excellent candidate for consideration. If COM works
>> well, then I imagine anything should work.
>> Microsoft's latest C++ presents a model for this that I'm generally
>> happy with; distinct RC pointer type. We could do better by having
>> implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
>> scope(T*) would be to T^ and T* like const(T*) is to T* and
>> immutable(T*).
>
> Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin.
>
>

This is not true for those of us working on Windows.

It just got replaced by C++/CLI, which was an improved version based on feedback about Managed C++.

The main difference was the removal of double underscore prefixes and making the keywords semantic. The multiple pointer types are still there.

https://msdn.microsoft.com/en-us/library/ms379603%28v=vs.80%29.aspx

Maybe it failed the goal of having C++ developers fully embrace .NET, but it achieved its goal of providing an easier way to integrate existing C++ code into .NET applications, instead of the P/Invoke dance.

The same syntax extensions that became the foundation of the second coming of COM, aka WinRT and is at the kernel of Windows 8.

Specially because this,

"Creating Windows Runtime Components in C++"
https://msdn.microsoft.com/library/windows/apps/hh441569/

is way simpler than this

"Creating a Basic Windows Runtime Component Using Windows Runtime Library"
https://msdn.microsoft.com/en-us/library/jj155856%28v=vs.110%29.aspx

It might happen that with C++14 and Windows 10, C++/CLI and C++/CX will become irrelevant, but until then, they have been useful integrating C++ code into .NET and Store applications.

--
Paulo

On Thursday, 26 February 2015 at 07:05:56 UTC, Russel Winder wrote:
> pure opinion and handwaving, not to mention mud-slinging. There should
> be a rule saying that no-one, but no-one, is allowed to make any claims
> about anything to do with performance without first having actually done
> a proper experiment and presented actual real data with statistical
> analysis.

I agree in general, but one can argue the theoretical best performance based on computer architecture and language features. The fact is to get good performance you need cache-line friendly layout. D is stuck with:

1. Fixed C struct layout

2. Separate compilation units that leaves the compiler blind.

3. C backends that are less GC friendly than Java/Javascript.

4. No compiler control over multi-threading.

5. Generic programming without compiler optimized data layout (that hurts).

It is possible to do "atomic writes" cheaply on x86 if you stick everything on the same cache line, and schedule instructions around the SFENCE in a clever manner to prevent pipeline stalls.

It is possible to avoid pointers and use indexes thus limiting the extent of a precise scan.

So surely you can create an experiment that gets good performance close to the theoretical limit, but it does not tell you how it will work out with a complicated generic programming based program based on D semantics and "monkey programming".

Computer architecture is also moving. AFAIK, on Intel MIC you get fast RAM close to the core (multi layered on top) and slower shared RAM. There is also a big difference on memory bus throughput  ranging from ~5 - 30 GB/s peak on desktop CPUs.

But before you measure anything you need to agree on what you want measured. You need a baseline.  IMO, the only acceptable baseline is carefully hand crafted data layout and manual memory management...

On Wednesday, 25 February 2015 at 15:55:26 UTC, Manu wrote:
> On 24 February 2015 at 10:36, deadalnix via Digitalmars-d
>> I'd like to see ARC support in D, but I do not think it makes sense as a
>> default.
>
> Then we will have 2 distinct worlds. There will be 2 kinds of D code,
> and they will be incompatible... I think that's worse.

There are already at least 2 kinds of D code. @nogc and with gc...

Do you want ARC without regular pointers? I think you will find the performance disappointing...

I don't mind replacing the current GC with ARC, but only if ARC is used with the same low frequency as shared_ptr in C++...

> or:
>
>   f = open_file(…)
>   g = open_file(…)
>   h = open_file(…)
>   if( error(f,g,h) ) log_error
>
>
> Also with async programming, futures/promises, the errors will be delayed,

That's the problem with future/promises, you spent your time explaining who waits for what instead of just writing what things do.


> so you might be better off having them as part of the object.

No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII.

So you can't re-enter that mutex as you asked, so I will grant you a scopedLock, but it is in an errored state so you'd better check that it is valid!