Am Thu, 17 Apr 2014 06:19:56 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> On Wednesday, 16 April 2014 at 23:14:27 UTC, Walter Bright wrote:
> > On 4/16/2014 3:45 PM, "Ola Fosheim Grøstad" I've written several myself that do not use malloc.
> 
> If it is shared or can call brk() it should be annotated.
> 
> > 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.
> 
> Library and syscalls can be marked, besides you can have dynamic tracing in debug mode.

It's a bit of a grey zone. There are probably real-time malloc() implementations out there. And syscalls like mmap() can be used to allocate virtual memory or just to map a file into virtual memory. If you mark all syscalls that doesn't matter of course.

At the end of the day you cannot really trace what a library uses that you happen to call into. Or at least not without significant overhead at runtime.

-- 
Marco

On 4/18/2014 5:30 AM, Steven Schveighoffer wrote:
> Absolutely not, the compiler knows whether the count needs to be incremented, I
> don't need to know.

But there are manual escapes from it, meaning you need to know to use them:

   unsigned char *vdata = data.data;
   // process vdata

I am skeptical that the O-C compiler is sufficiently smart to make ARC on all pointers practical. That snippet pretty much proves it.

Total replacement of GC with ARC in D will:

1. Be a massive change that will break most every D program
2. Require people to use unsafe escapes to recover lost performance
3. Require multiple pointer types
4. Will not be memory safe (see (2))
5. Require the invention of optimization technology that doesn't exist
6. Become more or less ABI incompatible with C without a long list of caveats and translations

and, to top it off, as the paper Andrei referenced pointed out,
it may not even be faster than the GC.

It has the very real likelihood of destroying D.

A much more tractable idea is to implement something like C++'s shared_ptr<> as a library type, with usage strategies paralleling C++'s (and yes, use of shared_ptr<> would be unsafe).

> Also possible in C# with structs, interop annotations and unsafe blocks.

 And now you aren't using the language, but a (very) poor subset of a language that doesn't even support templates.


>> C++ exposes SSE/AVX intrinsics, C# does not.
>
> That is not correct.
>
> 1 - Nowhere in the ANSI/ISO C++ are SSE/AVX intrinsics defined, those are compiler extensions. So equal foot with the C# EMCA standard;

 Duh, but every C++ compiler exposes this, so it is defacto standard. C++ has plenty of non-standard standards, such as #pragma once.


> 3 - .NET Native and RyuJIT have official support for SIMD instructions, GPGPU support is also planned

  I see on MS website an article about having a vector data type. While interesting that isn't the same as exposing the actual instructions, which will limit potential gains.

 The aricle http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx


 Additionally .NET native will be MS only--

On Friday, 18 April 2014 at 23:54:52 UTC, Walter Bright wrote:
> You shouldn't be using global data anyway.

Why not? LUTs and indexes that are global saves you a register.

On Friday, 18 April 2014 at 22:10:06 UTC, John Colvin wrote:
> Which, if any, of the more sophisticated GC designs out there - in your opinion - would work well with D? Perhaps more importantly, which do you see as *not* working well with D.

I think you can improve GC by:
- supporting c++ owned/shared pointers at the language level and marking them as no-scan.
- aligning scanned pointers in structs and classes to the same cache line
- having scan metadata at an offset from the return address of functions
- segmented collection
- whole program analysis to figure out what individual stacks can contain
- meta level invariants specified by the programmer

On 2014-04-18 18:17, Brad Anderson wrote:

> Problems like how toUpperInPlace would still allocate (with
> gusto) could much more easily be recognized and fixed with @nogc available.

toUpperInPlace should be removed. It cannot work reliable in place.

-- 
/Jacob Carlborg

On 2014-04-18 22:25, Walter Bright wrote:

> dmd could do a better job of escape analysis, and do this automatically.

That would be really nice. Is this long hanging fruit or does it require a lot of work?

-- 
/Jacob Carlborg

Jacob Carlborg:

> toUpperInPlace should be removed. It cannot work reliable in place.

Better to move it in std.ascii instead of removing it.

Bye,
bearophile

On 2014-04-19 12:21, bearophile wrote:

> Better to move it in std.ascii instead of removing it.

The current implementation works with more characters than ASCII.

-- 
/Jacob Carlborg

On Saturday, 19 April 2014 at 10:31:28 UTC, Jacob Carlborg wrote:
> On 2014-04-19 12:21, bearophile wrote:
>
>> Better to move it in std.ascii instead of removing it.
>
> The current implementation works with more characters than ASCII.

Or replace characters whose upper case representation is bigger than the lower case representation with U+FFFD or similar.