On 04/16/2014 10:10 PM, Peter Alexander wrote:
>
> However, that raises a second question: since err is allocated when a
> new thread is created, does that mean @nogc functions cannot create
> threads in the presence of such static initialisation?

This does not allocate on the GC heap.

> I am really looking forward to .NET Native becoming widespread.
>
> Then this type of comparisons (C# vs C++) will be quite different.


 I don't think it will make a major difference. Taking a GC based language and giving it a native compiler doesn't automatically make it performance competitive with C++(see Haskel and D(without dumping GC) on anything besides micro bench marks).

C# is still GC based, still makes heavy use of indirection(See Herb Sutters recent talk on arrays).

C++ exposes SSE/AVX intrinsics, C# does not.
Many programs don't use these, but if you have a few hot spots involving number crunching, they can make a major difference.

My current project spends about 80% of its CPU time in SSE amenable locations, some template magic mixed with SSE intrinsics, and now those spots run 4x faster.
 You might be thinking auto vectorization can compete, but I've yet to see the one in VS2013 accomplish much of anything.
  Also I doubt very much that an auto vectorizer can squash branches, which is very possible with intrinsics. True branches and vectorized code don't mix well...

On 4/16/2014 2:14 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> If the custom allocators are in D then you
> should be able to track all the way down to malloc.

malloc is hardly the only storage allocator.

On Wed, 16 Apr 2014 04:50:51 -0700, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I am convinced that ARC would be acceptable, and I've never heard anyone
> suggest any proposal/fantasy/imaginary GC implementation that would be
> acceptable...
> In complete absence of a path towards an acceptable GC implementation, I'd
> prefer to see people that know what they're talking about explore how
> refcounting could be used instead.
> GC backed ARC sounds like it would acceptably automate the circular
> reference catching that people fuss about, while still providing a workable
> solution for embedded/realtime users; disable(/don't link) the backing GC,
> make sure you mark weak references properly.

I'm just going to leave this here. I mentioned it previously in a debate over ARC vs. GC but I couldn't find the link at the time.

http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

The paper is pretty math heavy.

Long story short, Tracing vs. Ref-counting are algorithmic duals and therefore do not significantly differ. My read of the article is that all the different GC styles are doing is pushing the cost somewhere else.

ARC may in fact be the most advantageous for a specific use case, but that in no way means that all use cases will see a performance improvement, and in all likelihood, may see a decrease in performance.

That makes ARC a specialization for a certain type of programming, which would then remove D the "Systems" category and place it in a "Specialist" category. One could argue that due to the currently non-optional status of the GC that D is currently a "Specialist" language, and I would be hard pressed to argue against that.

@nogc removes the shackles of the GC from the language and thus brings it closer to the definition of "Systems". @nogc allows programmers to revert to C-style resource management without enforcing a specialized RM system, be it GC or ARC. @nogc might not make you run through the fields singing D's praises, but it is entirely consistent with the goals and direction of D.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Wednesday, 16 April 2014 at 22:34:35 UTC, Walter Bright wrote:
> malloc is hardly the only storage allocator.

Except for syscalls such as brk/sbrk, which ones are you thinking of?

On 4/16/2014 3:45 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 16 April 2014 at 22:34:35 UTC, Walter Bright wrote:
>> malloc is hardly the only storage allocator.
>
> Except for syscalls such as brk/sbrk, which ones are you thinking of?

I've written several myself that do not use malloc. Even the Linux kernel does not use malloc. Windows offers many ways to allocate memory without malloc. Trying to have a core language detect attempts to write a storage allocator is way, way beyond the scope of what is reasonable for it to do.

And, frankly, I don't see a point for such a capability. malloc is hardly the only problem people will encounter with realtime callbacks. You'll want to avoid disk I/O, network access, etc., too.

On 4/16/2014 3:42 PM, Adam Wilson wrote:
> ARC may in fact be the most advantageous for a specific use case, but that in no
> way means that all use cases will see a performance improvement, and in all
> likelihood, may see a decrease in performance.

Right on. Pervasive ARC is very costly, meaning that one will have to define alongside it all kinds of schemes to mitigate those costs, all of which are expensive for the programmer to get right.

Walter Bright:

> malloc is hardly the only problem people will encounter with
> realtime callbacks. You'll want to avoid disk I/O, network
> access, etc., too.

It seems a good idea to offer a way to extend the type system with new semantically meaningful annotations in user code. (Koka language does this too, with its effects management). I have seen an almost nice idea in this same thread.

Bye,
bearophile

On Wednesday, 16 April 2014 at 15:32:05 UTC, sclytrack wrote:
> What about adding custom annotations that don't do any checking by
> itself. Like when @nogc doesn't actually verify that the
> ~ is not used for strings.
>
> void hello() require(@nogc)
> {
>
> }
>
> Just a verification by the compiler that you use only routines
> that are marked with certain annotations.
>
> void boe()
> {
> }
>
> @(nasaverified)
> void test()
> {
> }
>
> //
>
> void hello() require(@(nasaverified))
> {
>   test(); // ok
>   boe();  // not ok.
> }

I really REALLY like this.
I can see it being rather useful. Assuming its expanded to
support UDA's.
Not quite sure what a use case is for it though.

On 2014-04-16 23:20:07 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 4/16/2014 3:42 PM, Adam Wilson wrote:
>> ARC may in fact be the most advantageous for a specific use case, but that in no
>> way means that all use cases will see a performance improvement, and in all
>> likelihood, may see a decrease in performance.
> 
> Right on. Pervasive ARC is very costly, meaning that one will have to define alongside it all kinds of schemes to mitigate those costs, all of which are expensive for the programmer to get right.

It's not just ARC. As far as I know, most GC algorithms require some action to be taken when changing the value of a pointer. If you're seeing this as unnecessary bloat, then there's not much hope in a better GC for D either.

But beyond that I wonder if @nogc won't entrench that stance even more. Here's the question: is assigning to a pointer allowed in a @nogc function? Of course it's allowed! Assigning to a pointer does not involve the GC in its current implementation... but what if another GC implementation to be used later needs something to be done every time a pointer is modified, is this "something to be done" allowed in a @nogc function?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca