www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will the D GC be awesome?

reply "DypthroposTheImposter" <mcbracket gmail.com> writes:
   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+)
3. No long stalls(anything over a couple millisecond(<3))

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

STAB!
Oct 03 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 3 October 2012 at 21:31:52 UTC, 
DypthroposTheImposter wrote:

  But can the D GC ever be made:

 1. precise
 2. able to scale to large-ish data set(2gig+)
 3. No long stalls(anything over a couple millisecond(<3))

 Q. Curious, would it be compacting?


I believe all these things are being worked on, or at least 
planned.



 Which leaves me with structs, and lets just say D struct are 
 not impressive--


Why?



 * 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?


It doesn't need them, but it might be nice. In the meantime you 
can use out params.



 * OpCmp returning an int is fugly I r sad


Maybe, but it does make things easier to implement.



 * why is haskell so much shorter syntax, can D get that nice 
 syntax plssssssssss



programmers. A lot of people are scared off by Haskell's syntax 
because it is so unusual.
Oct 03 2012
prev sibling next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
On Wed, 03 Oct 2012 23:26:05 +0200, 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+)
 3. No long stalls(anything over a couple millisecond(<3))
 
 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
 
 STAB!


Can you write a GC which meets your criteria?  If so, D can get one as 
soon as you write and contribute it.

Justin
Oct 03 2012
parent reply "DypthroposTheImposter" <mcbracket gmail.com> writes:
  Did that hook thing to let peoples write custom GC ever make it 
in?
Oct 03 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-04 00:01, DypthroposTheImposter wrote:

   Did that hook thing to let peoples write custom GC ever make it in?


Yes, it's pluggable at link time. Here's an example of a stub 
implementation:

http://www.dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub

It's for Tango but the runtimes are basically the same.

-- 
/Jacob Carlborg
Oct 03 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-10-2012 08:49, Jacob Carlborg wrote:

 On 2012-10-04 00:01, DypthroposTheImposter wrote:

   Did that hook thing to let peoples write custom GC ever make it in?


 Yes, it's pluggable at link time. Here's an example of a stub
 implementation:

 http://www.dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub

 It's for Tango but the runtimes are basically the same.


More relevant to D2: 
https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub

(Though admittedly nobody has built it for a while - so, disclaimer: 
there may be some silly build errors if you try to build it, but they 
should be easy to fix.)

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-04 12:58, Alex Rønne Petersen wrote:


 More relevant to D2:
 https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub

 (Though admittedly nobody has built it for a while - so, disclaimer:
 there may be some silly build errors if you try to build it, but they
 should be easy to fix.)


There it is, I've been looking for the corresponding one in druntie.

-- 
/Jacob Carlborg
Oct 04 2012
prev sibling next sibling parent reply "Tommi" <tommitissari hotmail.com> writes:
On Wednesday, 3 October 2012 at 21:31:52 UTC, 
DypthroposTheImposter wrote:

 * 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?


If it's for composability's sake that you *need* multiple return 
types, wouldn't returning a tuple in D be just as good (tuples 
automatically expand if needed).
Oct 03 2012
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-40-04 00:10, Tommi <tommitissari hotmail.com> wrote:


 (tuples automatically expand if needed)


False. Typetuples do, but those cannot be returned from functions.

-- 
Simen
Oct 04 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 03-10-2012 23:26, 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


Yes. Work is being done.


 2. able to scale to large-ish data set(2gig+)


Parallel marking is perfectly possible even with a conservative GC. I've 
been meaning to look into this.


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


A (non-real time) GC can't really make guarantees about pause times. 
While having a real time GC might be nice, it'd take an incredible 
amount of engineering effort.


 Q. Curious, would it be compacting?


In theory, it is possible to do this for some heap objects, but I 
suspect that it would do more harm than good in a systems language.


   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?


Use tuples. Multiple return values (as far as ABI goes) are impractical 
because every major compiler back end (GCC, LLVM, ...) would have to be 
adjusted for every architecture.


 * OpCmp returning an int is fugly I r sad


It's a sensible design decision. What would be the alternative?


 * why is haskell so much shorter syntax, can D get that nice syntax
 plssssssssss


D is a C-family language.


 STAB!


-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 03 2012
next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 3 October 2012 at 23:38:57 UTC, Alex Rønne
Petersen wrote:


 1. precise


 Yes. Work is being done.


BTW, where can I learn about the current progress with GC? Is
this work concentrated in one project or are there several
parallel works on improving GC? Is anyone already working on
making memory allocation and GC more multicore friendly?
Oct 03 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-04 08:01, thedeemon wrote:


 BTW, where can I learn about the current progress with GC? Is
 this work concentrated in one project or are there several
 parallel works on improving GC? Is anyone already working on
 making memory allocation and GC more multicore friendly?


If I recall correctly someone worked on a GC project during GSOC 2012. 
Trying search through "announce" list/forum.

-- 
/Jacob Carlborg
Oct 03 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-04 01:33, Alex Rønne Petersen wrote:


 Use tuples. Multiple return values (as far as ABI goes) are impractical
 because every major compiler back end (GCC, LLVM, ...) would have to be
 adjusted for every architecture.


Why can't it just be syntax sugar for returning a struct?

-- 
/Jacob Carlborg
Oct 03 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-10-2012 08:50, Jacob Carlborg wrote:

 On 2012-10-04 01:33, Alex Rønne Petersen wrote:


 Use tuples. Multiple return values (as far as ABI goes) are impractical
 because every major compiler back end (GCC, LLVM, ...) would have to be
 adjusted for every architecture.


 Why can't it just be syntax sugar for returning a struct?


I agree that it should be, FWIW. The problem is that some people really 
expect the ABI to be altered, which is unrealistic.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 04 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-04 12:59, Alex Rønne Petersen wrote:


 I agree that it should be, FWIW. The problem is that some people really
 expect the ABI to be altered, which is unrealistic.


Is there an advantage of altering the ABI?

-- 
/Jacob Carlborg
Oct 04 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-10-2012 14:26, Jacob Carlborg wrote:

 On 2012-10-04 12:59, Alex Rønne Petersen wrote:


 I agree that it should be, FWIW. The problem is that some people really
 expect the ABI to be altered, which is unrealistic.


 Is there an advantage of altering the ABI?


Presumably speed; returning small structs in registers will be faster 
than doing so on the stack.

But I don't agree that the vast complexity of altering well-established 
ABIs for multiple architectures is worth that speed gain.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-04 14:36, Alex Rønne Petersen wrote:


 Presumably speed; returning small structs in registers will be faster
 than doing so on the stack.


Are sturcts currently always returned on the stack?


 But I don't agree that the vast complexity of altering well-established
 ABIs for multiple architectures is worth that speed gain.


I agree.

-- 
/Jacob Carlborg
Oct 04 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:

 On 2012-10-04 14:36, Alex Rønne Petersen wrote:


 Presumably speed; returning small structs in registers will be faster
 than doing so on the stack.


 Are sturcts currently always returned on the stack?


From: http://dlang.org/abi.html, for Windows x86 extern(D):

* 1, 2 and 4 byte structs are returned in EAX.
* 8 byte structs are returned in EDX,EAX, where EDX gets the most 
significant half.
* For other struct sizes, the return value is stored through a hidden 
pointer passed as an argument to the function.
Oct 04 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-10-2012 15:21, Piotr Szturmaj wrote:

 Jacob Carlborg wrote:

 On 2012-10-04 14:36, Alex Rønne Petersen wrote:


 Presumably speed; returning small structs in registers will be faster
 than doing so on the stack.


 Are sturcts currently always returned on the stack?


 From: http://dlang.org/abi.html, for Windows x86 extern(D):

 * 1, 2 and 4 byte structs are returned in EAX.
 * 8 byte structs are returned in EDX,EAX, where EDX gets the most
 significant half.
 * 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.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 04 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 04 Oct 2012 15:27:58 +0200
schrieb Alex R=C3=B8nne Petersen <alex lycus.org>:


 On 04-10-2012 15:21, Piotr Szturmaj wrote:

 Jacob Carlborg wrote:
 [=E2=80=A6]
 * For other struct sizes, the return value is stored through a hidden
 pointer passed as an argument to the function.


=20
 I strongly advise ignoring the D calling convention. Only DMD implements=


=20

 it and nowhere else than on Windows for 32-bit x86.
=20
 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?

--=20
Marco
Oct 10 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Oct 10 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Oct 10 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-10-2012 15:06, Jacob Carlborg wrote:

 On 2012-10-04 14:36, Alex Rønne Petersen wrote:


 Presumably speed; returning small structs in registers will be faster
 than doing so on the stack.


 Are sturcts currently always returned on the stack?


As always, it depends on the arch, but on 32-bit x86: Yes. On 64-bit 
x86: Yes, if the struct size is larger than 8 bytes (otherwise it's 
returned in RAX).


 But I don't agree that the vast complexity of altering well-established
 ABIs for multiple architectures is worth that speed gain.


 I agree.


-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 04 2012
prev sibling parent reply "Tommi" <tommitissari hotmail.com> writes:
I wonder if tuple should automatically expand (flatten) into a 
list of arguments not only when used with template parameters, 
but with regular functions as well. This so, that it would enable 
composition of tuple returning functions with functions that take 
in individual arguments instead of a tuple, enabling that:

Tuple!(int, int) getTuple()
{
     //...
}

void fun(int arg1, int arg2)
{
     //...
}

void main()
{
     fun( getTuple() );
}
Oct 04 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/04/2012 05:16 PM, Tommi wrote:

 I wonder if tuple should automatically expand (flatten) into a list of
 arguments not only when used with template parameters, but with regular
 functions as well. This so, that it would enable composition of tuple
 returning functions with functions that take in individual arguments
 instead of a tuple, enabling that:

 Tuple!(int, int) getTuple()
 {
      //...
 }

 void fun(int arg1, int arg2)
 {
      //...
 }

 void main()
 {
      fun( getTuple() );
 }


No, it should not.

void main(){
     fun(getTuple().expand);
}
Oct 04 2012
parent reply "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:

 void main(){
     fun(getTuple().expand);
 }


Great, that works for me. It would be probably confusing if they 
tuples expanded automatically; non-obvious if you'd be passing 
one argument or multiple.
Oct 04 2012
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-10-04, 20:56, Tommi wrote:


 On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:

 void main(){
     fun(getTuple().expand);
 }


 Great, that works for me. It would be probably confusing if they tuples  
 expanded automatically; non-obvious if you'd be passing one argument or  
 multiple.


There's another reason:

void foo(T)(T, int, float);
void foo(T)(string, T);

Tuple!(int, float) getTuple();

foo("Hello", getTuple()); // What to call?

And:

void baz(T...)(T t);

baz(getTuple()) // Expand or not?


And while this is a constructed example, there is also the matter of
exponential possibilities for the overload system (Oh, so that didn't
work, maybe if I expand *this* tuple? No. *That* tuple? ...)

-- 
Simen
Oct 04 2012
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
On 10/3/2012 11:50 PM, Jacob Carlborg wrote:

 On 2012-10-04 01:33, Alex Rønne Petersen wrote:


 Use tuples. Multiple return values (as far as ABI goes) are impractical
 because every major compiler back end (GCC, LLVM, ...) would have to be
 adjusted for every architecture.


 Why can't it just be syntax sugar for returning a struct?


That's really the only credible way. A tuple should be an anonymous 
struct with the fields being the elements of the tuple.

The main issue for me for having perfect tuples is that the layout of 
fields in a struct is different from the layout of parameters being 
passed on the stack to a function. Ideally,

    struct S { int a; int b; }
    void foo(int p, int q);
    S s;
    foo(s);

should work (setting aside for the moment that they are different 
types). Unfortunately, the variety of function calling ABIs makes this 
impractical.

So tuples in a language like D that must conform to external ABIs is 
that tuples will always have some rough edges.
Oct 04 2012
parent reply "timotheecour" <thelastmammoth gmail.com> writes:
 Ideally,
    struct S { int a; int b; }
    void foo(int p, int q);
    S s;
    foo(s);

 should work (setting aside for the moment that they are 
 different types). Unfortunately, the variety of function 
 calling ABIs makes this impractical.
 So tuples in a language like D that must conform to external 
 ABIs is that tuples will always have some rough edges.


Why not simply introduce an "expand" property for structs?
----
foo(s.expand) //equivalent to foo(s.a,s.b)
----
That would be the exact analogous of expand for tuples and would 
maintain a sane type system .
Oct 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-05 04:57, timotheecour wrote:


 Why not simply introduce an "expand" property for structs?
 ----
 foo(s.expand) //equivalent to foo(s.a,s.b)
 ----
 That would be the exact analogous of expand for tuples and would
 maintain a sane type system .


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.

-- 
/Jacob Carlborg
Oct 04 2012
parent Marco Leise <Marco.Leise gmx.de> writes:
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
Oct 10 2012
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
On 10/3/2012 2:26 PM, DypthroposTheImposter wrote:

 But can the D GC ever be made:

 1. precise
 2. able to scale to large-ish data set(2gig+)
 3. No long stalls(anything over a couple millisecond(<3))


There is nothing in the language that prevents this, it's a matter of 
doing the implementation effort. Recently, the compiler started using a 
library-defined hook for doing precise GC. That hook currently does 
nothing, but it enables development of a better GC without needing 
compiler modifications.



 Q. Curious, would it be compacting?

 If not then I'm stuck not using it much--


Compacting requires making objects movable, and yes, D's semantics allow 
for movable objects. Interestingly, some of the latest ideas in GC seem 
to be moving away from compacting.




 * 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?


You can do that now with Tuples.



 * OpCmp returning an int is fugly I r sad


How else would you return a 3 state value?



 * why is haskell so much shorter syntax, can D get that nice syntax
 plssssssssss


Haskell's syntax is quite a bit shorter, but I find it difficult to 
mentally read, though I'm sure with practice I could get used to it.

D's syntax is deliberately designed to be a { } language, and to be 
comfortable for people who are used to { } languages.
Oct 03 2012
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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).

-- 
Simen
Oct 04 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
Oct 10 2012
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Oct 10 2012
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 10 Oct 2012 15:24:58 +0200
schrieb "Simen Kjaeraas" <simen.kjaras gmail.com>:


 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.


Do you know this effect on bad news in the morning, that makes
you take satire serious for the rest of the day? :p

-- 
Marco
Oct 10 2012
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Oct 08 2012
prev sibling next sibling parent "renoX" <renozyx gmail.com> writes:
On Wednesday, 3 October 2012 at 21:31:52 UTC, 
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+)
 3. No long stalls(anything over a couple millisecond(<3))



This figure is quite meaningless: if I split a collection phase 
in several 2ms portion, it would be conformat yet the user would 
still see long stalls: you need to define both a period and a 
maximum period of time usable by the GC in this period.



 Q. Curious, would it be compacting?



Add VM-aware GC (http://lambda-the-ultimate.org/node/2391) and 
you'll have also my ideal but non existant GC.

That said I know two free languages with a "real time"  GC: 
SuperCollider and Nimrod.


  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.



Agreed here.

Regards,
renoX


 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

 STAB!
Oct 04 2012
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.


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!
Oct 05 2012
parent reply Ben Davis <entheh cantab.net> writes:
On 06/10/2012 04:03, Chad J wrote:


 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.
Oct 08 2012
parent Jacob Carlborg <doob me.com> writes:
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
Oct 08 2012