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

Using C-family syntax makes D feel more at home to C/C++/Java/C# 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 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 "DypthroposTheImposter" <mcbracket gmail.com> writes:
  Did that hook thing to let peoples write custom GC ever make it 
in?
Oct 03 2012
prev sibling next sibling parent "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
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 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 =?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 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
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 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
prev sibling 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 next sibling parent 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
prev sibling next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 3 October 2012 at 23:38:57 UTC, Alex Rønne
Petersen wrote:

 1. precise


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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling next 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. 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!
Oct 05 2012
parent reply Ben Davis <entheh cantab.net> writes:
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.
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
prev sibling next 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 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.

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

 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
prev sibling next sibling 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 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
prev sibling next sibling parent "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
prev sibling 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 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