On 10/03/2012 05:26 PM, DypthroposTheImposter wrote:
> D is pretty cool, perhaps someday I can use it instead of C++ and have
> cool shit like fast build times, modules, no more bloody headers, sane
> templates, CTFE, UFCS etc
>
> But can the D GC ever be made:
>
> 1. precise
> 2. able to scale to large-ish data set(2gig+)

Others have already addressed these 2 points better than my knowledge.

> 3. No long stalls(anything over a couple millisecond(<3))

One of the cool things about D's memory management is that it has a lot of features that help you /avoid heap allocation/:

- Stack allocation.  Just about anything in D can be stack allocated. As long as you know that your memory won't need to survive past its scope, you should be able to put it in the stack.

- Array slices.  This can be used to reduce copying.  Many other languages seem to implement string slicing as a copy operation, which introduces allocations.

- Ranges allow you to traverse arbitrary containers /without/ first converting them into an array, thus avoiding copying allocations. (Exception: if you need random access on a range that doesn't support random access, then you may have to do this.)

- Preallocation with conventional malloc.  Any time you find yourself frequently allocating and freeing the same struct/object/whatever, then you may want to preallocate it and avoid the allocation/deallocation overhead.

Using these things is probably a much better strategy for real-time software than leaning on a GC.  There will probably be times when a GC is still all-too-convenient or perhaps even necessary (if you've ever looked at MMO code).  As long as you keep the GC stuff down to only what is strictly necessary, then it will probably do well.

Try to do array slicing in Java or C#.  You probably won't be able to do it.  You'll get string /copies/ and this will incur heap allocations in the GC heap.  Those languages /need/ good garbage collection to be performant because they abuse the poor GC heavily.

The one thing I find missing (as of a couple months ago, anyways) is reference counting.  For soft-real-time apps it would be nice if transitively-atomic types (ex: strings) could be reference counted. This would allow a lot of copy-on-write standard library functions to be called without incurring the wrath of the GC.  D is already so powerful at memory management in other regards that I won't be worrying about this unless it gets in my way some day.


>
> Q. Curious, would it be compacting?
>
> If not then I'm stuck not using it much--
>
> Which leaves me with structs, and lets just say D struct are not
> impressive--
>
>
> * Oh and on a totally unrelated note, D needs Multiple return values.
> Lua has it, it's awesome. D doesn't want to be left out does it?
>
> * OpCmp returning an int is fugly I r sad
>
> * why is haskell so much shorter syntax, can D get that nice syntax
> plssssssssss
>

I'll stick with the comments of others for these points too.

> STAB!
>

PAWNCH!

On 06/10/2012 04:03, Chad J wrote:
> Try to do array slicing in Java or C#.  You probably won't be able to do
> it.  You'll get string /copies/ and this will incur heap allocations in
> the GC heap.  Those languages /need/ good garbage collection to be
> performant because they abuse the poor GC heavily.

In fairness to Java, it does share the inner char array between strings when you request a substring. (Inside the String class you'll find a reference to a char array, and 'start' and 'count' ints.) The String object itself though (which is small and wraps the char array reference) is allocated new each time. Java's GC is rather good though, so it totally gets away with it.

On Thursday, 4 October 2012 at 05:33:21 UTC, Walter Bright wrote:
> On 10/3/2012 2:26 PM, DypthroposTheImposter wrote:
>> * OpCmp returning an int is fugly I r sad
>
> How else would you return a 3 state value?

 Via enums.

 enum CmpValues { lessThan = -1, equal = 0, greaterThan = 1}

 But then again, the enum is convertible to int :P. I think ints (or size_t) are just fine and do their job.

On 2012-10-09 00:44, Ben Davis wrote:

> In fairness to Java, it does share the inner char array between strings
> when you request a substring. (Inside the String class you'll find a
> reference to a char array, and 'start' and 'count' ints.) The String
> object itself though (which is small and wraps the char array reference)
> is allocated new each time. Java's GC is rather good though, so it
> totally gets away with it.

The Java GC is far superior than the one in D. But in D it's possible to write a parser that doesn't allocate during processing, it just need some pre-allocation before starting. This is all due to the array slicing, which I think is pretty cool. The XML parser in Tango is an example of this:

http://dotnot.org/blog/archives/2008/02/24/xml-benchmarks-tango-ups-the-ante/

http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

https://github.com/SiegeLord/Tango-D2

http://www.dsource.org/projects/tango/docs/current/tango.text.xml.PullParser.html

-- 
/Jacob Carlborg

Am Thu, 04 Oct 2012 15:27:58 +0200
schrieb Alex Rønne Petersen <alex@lycus.org>:

> On 04-10-2012 15:21, Piotr Szturmaj wrote:
> > Jacob Carlborg wrote:
> > […]
> > * For other struct sizes, the return value is stored through a hidden
> > pointer passed as an argument to the function.
> 
> I strongly advise ignoring the D calling convention. Only DMD implements it and nowhere else than on Windows for 32-bit x86.
> 
> Instead, refer to the Windows and System V x86 ABIs.

The hidden pointer is exactly what I see MSVC++ produce for
struct returns (but even for 4 byte ones). e.g. "MyStruct
foo()" is equivalent to "foo(MyStruct&)"
I understand that the GCC people don't want to add YACC (yet
another calling-convention), but frankly Pascal got away with
a c-c of its own, too and I never heard anyone complain.
I mean aside from compiler implementations, what's the problem
with an own calling convention for D code calling D code if it
is more efficient?

-- 
Marco

Am Fri, 05 Oct 2012 08:43:53 +0200
schrieb Jacob Carlborg <doob@me.com>:

> We already have the .tupleof property:
> 
> struct Foo
> {
>      int x;
>      int y;
> }
> 
> void foo (int a, int b)
> {
>      writeln(a, " ", b);
> }
> 
> void main ()
> {
>      auto f = Foo(1, 2);
>      foo(f.tupleof);
> }
> 
> This works today and I'm pretty sure it has for a long time.

Thanks for this practical usage example. I always
ignored .tupleof. Next time I contemplate if I should make a
function take a "Rect" struct or four coordinates, I'll
remember that!

-- 
Marco

Am Thu, 04 Oct 2012 16:12:43 +0200
schrieb "Simen Kjaeraas" <simen.kjaras@gmail.com>:

> On 2012-27-04 07:10, Walter Bright <newshound1@digitalmars.com> wrote:
> 
> >> * OpCmp returning an int is fugly I r sad
> >
> > How else would you return a 3 state value?
> 
> enum Comparison {
>      Before = -1,
>      Same = 0,
>      After = 1,
>      Unordered = NaN,
> }
> 
> I'm not saying it should be done, but it would be more readable
> (and more cmoplex to write).

a) There is no integer NaN and floating point is a no-go. b) If you mix sortable and unsortable most algorithms fail.

Otherwise an enum solution is good, but a bit longer in code:

auto rel = a.OpCmp(b);
if (rel < 0) ...;
else if (rel > 0) ...;
else ...;

vs.

if (rel == Comparison.Before) ...;
else if (rel == Comparison.After) ...;
else ...;

And in many cases right now you can just "return a - b";

-- 
Marco

On 2012-10-10, 14:24, Marco Leise wrote:

>> enum Comparison {
>>      Before = -1,
>>      Same = 0,
>>      After = 1,
>>      Unordered = NaN,
>> }

> a) There is no integer NaN and floating point is a no-go.

The NaN was intended as a joke, and to highlight the fact that
you can have opCmp return a float today, and get some of the
behavior that floats have.


> b) If you mix sortable and unsortable most algorithms fail.
>
> Otherwise an enum solution is good, but a bit longer in
> code:
>
> auto rel = a.OpCmp(b);
> if (rel < 0) ...;
> else if (rel > 0) ...;
> else ...;
>
> vs.
>
> if (rel == Comparison.Before) ...;
> else if (rel == Comparison.After) ...;
> else ...;
>
> And in many cases right now you can just "return a - b";

Yeah, this last part is what I really like about the
current solution. Of course, if we could have ranged enums:

enum Comparison {
    Before < 0,
    Same = 0,
    After > 0
}

But that's not going to happen (unless someone provides it
in a library, of course).

-- 
Simen

On Wednesday, 10 October 2012 at 12:29:19 UTC, Marco Leise wrote:
> Am Thu, 04 Oct 2012 15:27:58 +0200
> schrieb Alex Rønne Petersen <alex@lycus.org>:
>
>> On 04-10-2012 15:21, Piotr Szturmaj wrote:
>> > Jacob Carlborg wrote:
>> > […]
>> > * For other struct sizes, the return value is stored through a hidden
>> > pointer passed as an argument to the function.
>> 
>> I strongly advise ignoring the D calling convention. Only DMD implements it and nowhere else than on Windows for 32-bit x86.
>> 
>> Instead, refer to the Windows and System V x86 ABIs.
>
> The hidden pointer is exactly what I see MSVC++ produce for
> struct returns (but even for 4 byte ones). e.g. "MyStruct
> foo()" is equivalent to "foo(MyStruct&)"
> I understand that the GCC people don't want to add YACC (yet
> another calling-convention), but frankly Pascal got away with
> a c-c of its own, too and I never heard anyone complain.

Because many moons ago people did use Pascal dialects for systems programming, and thanks to it, the Pascal calling convention earned its place in the land of operating systems calling conventions.


--
Paulo

On 10-10-2012 14:05, Marco Leise wrote:
> Am Thu, 04 Oct 2012 15:27:58 +0200
> schrieb Alex Rønne Petersen <alex@lycus.org>:
>
>> On 04-10-2012 15:21, Piotr Szturmaj wrote:
>>> Jacob Carlborg wrote:
>>> […]
>>> * For other struct sizes, the return value is stored through a hidden
>>> pointer passed as an argument to the function.
>>
>> I strongly advise ignoring the D calling convention. Only DMD implements
>> it and nowhere else than on Windows for 32-bit x86.
>>
>> Instead, refer to the Windows and System V x86 ABIs.
>
> The hidden pointer is exactly what I see MSVC++ produce for
> struct returns (but even for 4 byte ones). e.g. "MyStruct
> foo()" is equivalent to "foo(MyStruct&)"
> I understand that the GCC people don't want to add YACC (yet
> another calling-convention), but frankly Pascal got away with
> a c-c of its own, too and I never heard anyone complain.
> I mean aside from compiler implementations, what's the problem
> with an own calling convention for D code calling D code if it
> is more efficient?
>

The problem is ABI specification. Right now, you can't reliably write inline assembly in D because all the compilers use different calling conventions for extern (D).

Also, the Pascal calling convention is only supported by very few compilers today.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org