On Wednesday, 3 July 2013 at 06:38:04 UTC, deadalnix wrote:
> On Wednesday, 3 July 2013 at 03:13:59 UTC, Mehrdad wrote:
>> In other words, I know C++ is _painful_ to write fast code in, but that doesn't make it slower; it just makes it more painful. On the other hand, if you could demonstrate that e.g. the GC is faster than manual memory management, then I'd totally agree D is faster than C++.
>
> Slice + immutability + GC is awesomeness. You need the 3 to get the full efficiency, or you'll ends up doing quite a lot of book keeping.


No doubt about awesomeness :) but that's not a number I can compare to C++.

On Thursday, July 04, 2013 21:26:21 Mehrdad wrote:
> On Wednesday, 3 July 2013 at 07:12:54 UTC, Joseph Rushton
> 
> Wakeling wrote:
> > On 07/03/2013 05:13 AM, Mehrdad wrote:
> >> That doesn't mean D is "faster". It just means it's less
> >> painful to get the same
> >> performance.
> > 
> > That would be ... kind of the point.  If we didn't care about
> > the pain, we'd all
> > be programming using assembly.  Or butterflies:
> > https://xkcd.com/378/
> > 
> > But faster performance with less pain and more safety?  Yes please. :-)
> 
> Not really. For example, no matter how much C++ code you feel like writing, it'll be _impossible_ for you to replicate the behavior of a GC in C++.
> 
> So it's not a matter of how much pain you're willing to go through -- it's literally a matter of language capabilities.

It's perfectly possible to implement a GC - even D's GC - in C++. You could even make it work with new by overriding the global new (as stupid a thing as that would arguably be). Given enough time and effort, you can do almost anything in C++ that you can do in D. There are some things relating to type introspection, code generation, and CTFE which you can't do directly in C++, but even then, you could just add something to your build process which generated the C++ code that you wanted. So, while you can't do that stuff directly in the language, you can still generate the C++ code that it would have generated if C++ had those capabilities.

So, given enough time and effort, you can _always_ make C++ match D for speed. Given enough time and effort, you can _always_ make D match C++ for speed. It's just a question of how much time and effort you want to go to and how much of a pain it is to do so.

The real question is how idiomatic C++ compares with idiomatic D for speed, and how much programming effort is required to make one match the other when it's slower.

In general, idiomatic D should be comparable to idiomatic C++ for speed, and where it isn't, it should be fairly easy to write the equivalent of the idiomatic C++ code and get the same efficiency. However, it's frequently the case that writing the C++ equivalent of idiomatic D code is a royal pain, so it's unlikely that anyone is going to write their C++ code in a manner which will beat such D code. Most anything involving a lot of slicing is likely to fall into that category.

But ultimately, C++ and D are both systems languages and provide enough capabilities that given enough time and effort neither can possibly beat the other for speed.

- Jonathan M Davis

On Thursday, 4 July 2013 at 19:51:34 UTC, Jonathan M Davis wrote:
> It's perfectly possible to implement a GC - even D's GC - in C++.


I don't see how.

There is no way to inspect the stack, static data segments, etc. for GC roots in standard C++.

How would you possibly be able to find the roots?

On Thursday, July 04, 2013 22:46:12 Mehrdad wrote:
> On Thursday, 4 July 2013 at 19:51:34 UTC, Jonathan M Davis wrote:
> > It's perfectly possible to implement a GC - even D's GC - in C++.
> 
> I don't see how.
> 
> There is no way to inspect the stack, static data segments, etc. for GC roots in standard C++.
> 
> How would you possibly be able to find the roots?

By putting all of the same information there that we have in D. It may be clunkier to do in D and generally more of a pain, but you have just as much control over memory in C++ as you do in D. And C++ GCs _do_ exist, even if they're not the norm.

- Jonathan M Davis

On Thursday, 4 July 2013 at 20:58:57 UTC, Jonathan M Davis wrote:
> On Thursday, July 04, 2013 22:46:12 Mehrdad wrote:
>> How would you possibly be able to find the roots?
>
> By putting all of the same information there that we have in D. It may be clunkier to do in D and generally more of a pain, but you have just as much control over memory in C++ as you do in D.
> And C++ GCs _do_ exist


Er, C++ _compilers_ that support (conservative?) GC's do exist.

But you can't write standard C++ code and expect it to garbage-collect itself, you need external help that's not guaranteed by the standard.

D, on the other hand, has a GC built into the language itself; it's not an implementation detail.

On Thursday, 4 July 2013 at 21:03:01 UTC, Mehrdad wrote:
> On Thursday, 4 July 2013 at 20:58:57 UTC, Jonathan M Davis wrote:
>> On Thursday, July 04, 2013 22:46:12 Mehrdad wrote:
>>> How would you possibly be able to find the roots?
>>
>> By putting all of the same information there that we have in D. It may be clunkier to do in D and generally more of a pain, but you have just as much control over memory in C++ as you do in D.
>> And C++ GCs _do_ exist
>
>
> Er, C++ _compilers_ that support (conservative?) GC's do exist.
>
> But you can't write standard C++ code and expect it to garbage-collect itself, you need external help that's not guaranteed by the standard.
>
> D, on the other hand, has a GC built into the language itself; it's not an implementation detail.


To put it another way, _any_ conformant D compiler must necessarily have a GC.

On the other hand, C++ compiler aren't required to, so portable code can't assume they will.

On Thursday, July 04, 2013 23:04:09 Mehrdad wrote:
> On Thursday, 4 July 2013 at 21:03:01 UTC, Mehrdad wrote:
> > On Thursday, 4 July 2013 at 20:58:57 UTC, Jonathan M Davis
> > 
> > wrote:
> >> On Thursday, July 04, 2013 22:46:12 Mehrdad wrote:
> >>> How would you possibly be able to find the roots?
> >> 
> >> By putting all of the same information there that we have in
> >> D. It may be clunkier to do in D and generally more of a pain,
> >> but you have just as much control over memory in C++ as you do
> >> in D.
> >> And C++ GCs _do_ exist
> > 
> > Er, C++ _compilers_ that support (conservative?) GC's do exist.
> > 
> > But you can't write standard C++ code and expect it to garbage-collect itself, you need external help that's not guaranteed by the standard.
> > 
> > D, on the other hand, has a GC built into the language itself; it's not an implementation detail.
> 
> To put it another way, _any_ conformant D compiler must necessarily have a GC.
> 
> On the other hand, C++ compiler aren't required to, so portable code can't assume they will.

Well, of course portable C++ code won't assume that you have a GC. My point was that it's perfectly possible to write C++ code which uses a GC, not that it was normal or easy.

- Jonathan M Davis

On Thursday, 4 July 2013 at 21:11:57 UTC, Jonathan M Davis wrote:
> Well, of course portable C++ code won't assume that you have a GC.


But portable D code will, so it really _is_ an advantage of the language, not just the compiler...


> My point was that it's perfectly possible to write C++ code which uses a GC, not that it was normal or easy.

No, the point is that it would only with a particular C++ compiler.
It's not "C++" code if a C++ compiler can't run it correctly.
That would make it "a vendor-specific language similar to C++" code.

On Thursday, July 04, 2013 23:20:47 Mehrdad wrote:
> On Thursday, 4 July 2013 at 21:11:57 UTC, Jonathan M Davis wrote:
> > Well, of course portable C++ code won't assume that you have a GC.
> 
> But portable D code will, so it really _is_ an advantage of the language, not just the compiler...

Sure. There's lots of stuff (like slices) which are an advantage of the language, because they're built-in and/or just easier to do. My point was that given enough time and effort, you can do anything in C++ that you can do in D. So, if you only want to consider things that _can't_ be done in C++ as relevant when comparing the speed of the languages (which seems to be what you were arguing for), then I don't believe that there is any difference in what you can do or how fast it will be. They are both turing complete languages and both give you the same level of access to the hardware. The entire difference lies in how easy they make it to write programs and what paradigms and idioms are easiest to write and use in them.

There's no point in even trying to compare the two languages for speed if you're trying to compare possible speeds (ignoring what paradigms and idioms they use) rather than comparing their relative speeds when using the normal idioms and paradigms that they use simply because they ultimately give you the same capabilities if you work hard enough at it.

> > My point was that it's perfectly possible to write C++ code which uses a GC, not that it was normal or easy.
> 
> No, the point is that it would only with a particular C++
> compiler.
> It's not "C++" code if a C++ compiler can't run it correctly.
> That would make it "a vendor-specific language similar to C++"
> code.

Maybe I'm not well-enough informed, but I'm not aware of any reason that you can't implement a GC in C++. Maybe you can't do it with new without the compiler's help, and it may be a royal pain, but you have control over the memory layout and can put whatever extra information you want there in order to facilitate a GC.

- Jonathan M Davis

Am 04.07.2013 23:20, schrieb Mehrdad:
> On Thursday, 4 July 2013 at 21:11:57 UTC, Jonathan M Davis wrote:
>> Well, of course portable C++ code won't assume that you have a GC.
>
>
> But portable D code will, so it really _is_ an advantage of the
> language, not just the compiler...
>
>
>> My point was that it's perfectly possible to write C++ code which uses
>> a GC, not that it was normal or easy.
>
> No, the point is that it would only with a particular C++ compiler.
> It's not "C++" code if a C++ compiler can't run it correctly.
> That would make it "a vendor-specific language similar to C++" code.

Yeah, it is called Managed C++ in .NET 1.x, C++/CLI starting in .NET 2.0 and C++/CX in WinRT.

Managed C++ and C++/CLI can be JITed or compiled to machine code via NGEN. They make use of .NET GC for ref data types. There is a standard defined for C++/CLI, ECMA-372.

C++/CX compiles to native code, while making use of COM reference counting, the usual first level of GC algorithms.

--
Paulo