Re: Will the D GC be awesome?
Am Thu, 04 Oct 2012 15:27:58 +0200 schrieb Alex Rønne Petersen a...@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
Re: Will the D GC be awesome?
Am Fri, 05 Oct 2012 08:43:53 +0200
schrieb Jacob Carlborg d...@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
Re: Will the D GC be awesome?
Am Thu, 04 Oct 2012 16:12:43 +0200
schrieb Simen Kjaeraas simen.kja...@gmail.com:
On 2012-27-04 07:10, Walter Bright newshou...@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
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 a...@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
Re: Will the D GC be awesome?
On 10-10-2012 14:05, Marco Leise wrote: Am Thu, 04 Oct 2012 15:27:58 +0200 schrieb Alex Rønne Petersen a...@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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
Am Wed, 10 Oct 2012 15:24:58 +0200 schrieb Simen Kjaeraas simen.kja...@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
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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.
Re: Will the D GC be awesome?
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.
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 plss I'll stick with the comments of others for these points too. STAB! PAWNCH!
Re: Will the D GC be awesome?
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?
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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.
Re: Will the D GC be awesome?
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 a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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() );
}
Re: Will the D GC be awesome?
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);
}
Re: Will the D GC be awesome?
On 2012-40-04 00:10, Tommi tommitiss...@hotmail.com wrote: (tuples automatically expand if needed) False. Typetuples do, but those cannot be returned from functions. -- Simen
Re: Will the D GC be awesome?
On 2012-27-04 07:10, Walter Bright newshou...@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
Re: Will the D GC be awesome?
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.
Re: Will the D GC be awesome?
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
Re: Will the D GC be awesome?
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 plss STAB!
Re: Will the D GC be awesome?
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.
Re: Will the D GC be awesome?
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 .
Will the D GC be awesome?
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 plss STAB!
Re: Will the D GC be awesome?
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 plss 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
Re: Will the D GC be awesome?
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 plss 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.
Re: Will the D GC be awesome?
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).
Re: Will the D GC be awesome?
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 plss D is a C-family language. STAB! -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Will the D GC be awesome?
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
plss
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.
