www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs C++ - Where are the benchmarks?

reply "Gabi" <galim120 bezeqint.net> writes:
Hi D community,

I am new to D and got impressed with the language so much that I 
was thinking on introducing D it my workplace as an alternative 
to C++ which is heavily used on our projects.

The first question that came up was how it stands up with C++ 
performance wise ?

I didn't find D on the shootout site (why?) and didn't find 
almost any benchmarks comparisons.

Are there any good comparisons out there ?

Gabi
Jun 30 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Hi D community,

 I am new to D and got impressed with the language so much that 
 I was thinking on introducing D it my workplace as an 
 alternative to C++ which is heavily used on our projects.

 The first question that came up was how it stands up with C++ 
 performance wise ?


It's comparable.


 I didn't find D on the shootout site (why?) and didn't find 
 almost any benchmarks comparisons.


It used to be in there and used to dominate the shootout.  D and 
Free Pascal used to be neck and neck for the top spot, if you 
weighted speed, memory, and code size the same.  But the guy who 
runs those benchmarks apparently didn't want to spend time on the 
D examples anymore, from what I can tell from this cryptic 
comment:

http://www.digitalmars.com/d/archives/digitalmars/D/The_Computer_Languages_Shootout_Game_120840.html

That site and D's dominance was one of the reasons I came to D 
early on.  It would be nice if he would take D back, but I 
haven't looked at that site in many years, so I'm not sure if it 
even matters anymore.


 Are there any good comparisons out there ?


Not that I know of, but then I'm not looking to justify the use 
of D anymore. ;)
Jun 30 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Sunday, 30 June 2013 at 20:05:16 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Are there any good comparisons out there ?


 Not that I know of, but then I'm not looking to justify the use 
 of D anymore. ;)


When I just googled for "d programming language benchmark," this 
post was two clicks from the first page of search results:

http://attractivechaos.wordpress.com/2011/06/22/my-programming-language-benchmark-analyses/
Jun 30 2013
parent reply "Gabi" <galim120 bezeqint.net> writes:
On Sunday, 30 June 2013 at 20:26:38 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 20:05:16 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Are there any good comparisons out there ?


 Not that I know of, but then I'm not looking to justify the 
 use of D anymore. ;)


 When I just googled for "d programming language benchmark," 
 this post was two clicks from the first page of search results:

 http://attractivechaos.wordpress.com/2011/06/22/my-programming-language-benchmark-analyses/


Thanks for that. Unfortunately it doesn't contain dmd benchmarks 
which I most interested in because our main platform is windows.
Jun 30 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 30 June 2013 at 21:06:37 UTC, Gabi wrote:

 On Sunday, 30 June 2013 at 20:26:38 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 20:05:16 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Are there any good comparisons out there ?


 Not that I know of, but then I'm not looking to justify the 
 use of D anymore. ;)


 When I just googled for "d programming language benchmark," 
 this post was two clicks from the first page of search results:

 http://attractivechaos.wordpress.com/2011/06/22/my-programming-language-benchmark-analyses/


 Thanks for that. Unfortunately it doesn't contain dmd 
 benchmarks which I most interested in because our main platform 
 is windows.


Let's just say "comparable": sometimes you'll get better, 
sometimes you'll get less. You have to keep in mind benchmarks 
are "synthetic", meaning they won't give you a good "real world 
view" of what you'll get in the end. Worst case scenario, D links 
with C and C++, so if you have some really nice "hand carved" C 
or C++ code, you can just link it in "as-is" (disclaimer, a bit 
complicated)

If you guys are already doing C++, then the shift should be 
relatively easy. The final experience with D (IMO) is that it is 
much simpler, much more enjoyable, and faster to develop. The 
drawbacks is that it is still buggy, not so stable (a bit of 
breakage every version, nothing major, but it's there). Another 
"problem" is that the "design patterns" for D are still being 
researched, and today's recommendation might be tomorrow's 
no-no...

I think the bottom line is that raw performance should not be 
your primary concern. As Marshall Cline states in his "big 
picture issues": "Choosing a language is a *business* decision". 
Evaluate the time/money you and your team will lose learning D, 
making the shift and maintaining code against a changing 
standard, then weight that against the time/money you'll gain 
using a higher level language like D. Once you've evaluated that, 
benchmark.
Jun 30 2013
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 30 June 2013 at 21:06:37 UTC, Gabi wrote:

 On Sunday, 30 June 2013 at 20:26:38 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 20:05:16 UTC, Joakim wrote:

 On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Are there any good comparisons out there ?


 Not that I know of, but then I'm not looking to justify the 
 use of D anymore. ;)


 When I just googled for "d programming language benchmark," 
 this post was two clicks from the first page of search results:

 http://attractivechaos.wordpress.com/2011/06/22/my-programming-language-benchmark-analyses/


 Thanks for that. Unfortunately it doesn't contain dmd 
 benchmarks which I most interested in because our main platform 
 is windows.


If you're concerned about performance, I'd recommend against 
using DMD for your release builds. GDC and LDC will give much 
better performance, and GDC works perfectly fine on Windows. LDC 
has some problems with exception handling AFAIK on Windows.
Jun 30 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 01.07.2013 03:07, schrieb Kapps:

 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.


GDC got the same Exception problems like LDC - no support for SEH
but Exceptions are working - only the Windows-internal-Exception -> 
D-Exception transition is not working properbly

but even using Visual Studio you need to add special flags or using 
__try, __catch to get these - so normaly not a problem
Jun 30 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz gmx.net> wrote:

 Am 01.07.2013 03:07, schrieb Kapps:


 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.



 GDC got the same Exception problems like LDC - no support for SEH
 but Exceptions are working - only the Windows-internal-Exception ->


D-Exception transition is not working properbly

 but even using Visual Studio you need to add special flags or using


__try, __catch to get these - so normaly not a problem


Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
AFAIK, structured exception handling support in gcc is being developed to
overcome the weaknesses of both dw2 and sjlj.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 01 2013



  parent reply dennis luehring <dl.soluz gmx.net>  writes:


Am 01.07.2013 10:14, schrieb Iain Buclaw:

 On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz gmx.net> wrote:

 Am 01.07.2013 03:07, schrieb Kapps:


 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.



 GDC got the same Exception problems like LDC - no support for SEH
 but Exceptions are working - only the Windows-internal-Exception ->


 D-Exception transition is not working properbly

 but even using Visual Studio you need to add special flags or using


 __try, __catch to get these - so normaly not a problem


 Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
 AFAIK, structured exception handling support in gcc is being developed to
 overcome the weaknesses of both dw2 and sjlj.


"...is being developed" thats means gcc got Windows-SEH support?



 Jul 01 2013



 next sibling parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 1 July 2013 12:02, dennis luehring <dl.soluz gmx.net> wrote:

 Am 01.07.2013 10:14, schrieb Iain Buclaw:

 On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz gmx.net> wrote:

 Am 01.07.2013 03:07, schrieb Kapps:


 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.




 GDC got the same Exception problems like LDC - no support for SEH
 but Exceptions are working - only the Windows-internal-Exception ->


 D-Exception transition is not working properbly

 but even using Visual Studio you need to add special flags or using


 __try, __catch to get these - so normaly not a problem


 Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
 AFAIK, structured exception handling support in gcc is being developed to
 overcome the weaknesses of both dw2 and sjlj.



 "...is being developed" thats means gcc got Windows-SEH support?


No, it hasn't.  If there are any patches, I can't see them after a cursory look.

There a wiki for discussion at least:
http://gcc.gnu.org/wiki/WindowsGCCImprovements


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 01 2013



prev sibling  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 1 July 2013 12:38, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 1 July 2013 12:02, dennis luehring <dl.soluz gmx.net> wrote:

 Am 01.07.2013 10:14, schrieb Iain Buclaw:

 On Jul 1, 2013 7:16 AM, "dennis luehring" <dl.soluz gmx.net> wrote:

 Am 01.07.2013 03:07, schrieb Kapps:


 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.




 GDC got the same Exception problems like LDC - no support for SEH
 but Exceptions are working - only the Windows-internal-Exception ->


 D-Exception transition is not working properbly

 but even using Visual Studio you need to add special flags or using


 __try, __catch to get these - so normaly not a problem


 Right, gcc (thus, gdc) uses sjlj (setjmp/longjmp) exceptions on Windows.
 AFAIK, structured exception handling support in gcc is being developed to
 overcome the weaknesses of both dw2 and sjlj.



 "...is being developed" thats means gcc got Windows-SEH support?


 No, it hasn't.  If there are any patches, I can't see them after a cursory
look.

 There a wiki for discussion at least:
 http://gcc.gnu.org/wiki/WindowsGCCImprovements


Which after a few clicks brings you to this page:
http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008#General_Information

Though, that was support as of 2008... there might have been a few
changes since then to improve it. =)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 01 2013



prev sibling  parent reply "Gabi" <galim120 bezeqint.net>  writes:


On Monday, 1 July 2013 at 06:11:20 UTC, dennis luehring wrote:

 Am 01.07.2013 03:07, schrieb Kapps:

 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. 
 LDC
 has some problems with exception handling AFAIK on Windows.


 GDC got the same Exception problems like LDC - no support for 
 SEH
 but Exceptions are working - only the 
 Windows-internal-Exception -> D-Exception transition is not 
 working properbly

 but even using Visual Studio you need to add special flags or 
 using __try, __catch to get these - so normaly not a problem


Could you please elaborate on this? What should I beware/avoid of 
when using GDC under Windows ?



 Jul 01 2013



  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 1 July 2013 11:18, Gabi <galim120 bezeqint.net> wrote:

 On Monday, 1 July 2013 at 06:11:20 UTC, dennis luehring wrote:

 Am 01.07.2013 03:07, schrieb Kapps:

 If you're concerned about performance, I'd recommend against
 using DMD for your release builds. GDC and LDC will give much
 better performance, and GDC works perfectly fine on Windows. LDC
 has some problems with exception handling AFAIK on Windows.



 GDC got the same Exception problems like LDC - no support for SEH
 but Exceptions are working - only the Windows-internal-Exception ->
 D-Exception transition is not working properbly

 but even using Visual Studio you need to add special flags or using __try,
 __catch to get these - so normaly not a problem



 Could you please elaborate on this? What should I beware/avoid of when using
 GDC under Windows ?


Mixing MSVC and GCC when C++ linkage is involved. :)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 01 2013



prev sibling next sibling parent reply "SomeDude" <lovelydear mailmetrash.com>  writes:


On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 Hi D community,

 I am new to D and got impressed with the language so much that 
 I was thinking on introducing D it my workplace as an 
 alternative to C++ which is heavily used on our projects.

 The first question that came up was how it stands up with C++ 
 performance wise ?

 I didn't find D on the shootout site (why?) and didn't find 
 almost any benchmarks comparisons.

 Are there any good comparisons out there ?

 Gabi


D used to be in the shootout, and was doing very good, right on 
par with g++. That was before Isaac Gouy, the maintainer of the 
shootout/benchmark game, decided to remove a number of languages, 
among which D. Don't ask us what his criteria are, noone knows 
for sure.

Overall, the performance of D can be extremely good. It is most 
often largely superior to Java, and it can even be better than 
C++ in non trivial programs, if one cares about not allocating 
too much on the heap. It seems indeed that the automatic memory 
management is a major performance killer, and it's not always 
easy to know in advance what the overall performance of D code 
will be. But the less work for the GC, the better.

To illustrate this, in one recent thread, one guy did a direct 
translation of his C++ raytracer to D. His first attempt wasn't 
very good, as the D version was almost 10x slower than the C++ 
version (with the same gcc backend), which is abnormal. A few 
simple optimizations later (without changing the algorithm), the 
D version was 40% faster than the g++ -O2 version. Another 
example of high performance is the std.regex library, which is 
known to be faster than all other implementations that we've 
heard of, in any language. So yes, one can get stellar 
performance out of D, but I would say right out of the box, it's 
not automatic, it does require some work where high performance 
is needed. However, out of all the existing languages, it's 
probably second only to C++.

Up until fairly recently, memory allocation was not considered a 
primary concern, so that some parts of the Phobos standard 
library do allocate memory behind the scene. But today, a lot of 
attention is being paid not to allocate when it's not absolutely 
necessary, and the standard library is slowly being expurged of 
unnecessary allocations. This is largely a manual process, 
though. In a not too distant future (say before 2014), some 
tooling will help detecting spurious memory allocations, so that 
there is good hope that the Phobos library will be essentially 
clean in that regard. Also, there is some work going on for a 
concurrent GC.



 Jun 30 2013



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:

 It seems indeed that the automatic memory management is a major 
 performance killer


Eh, I'd say it is D's gc implementation specifically that is the 
biggest worry rather than the concept. I think the .net gc is 
seriously like 10x faster than D's implementation.



 Jun 30 2013



  parent reply "SomeDude" <lovelydear mailmetrash.com>  writes:


On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:

 On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:

 It seems indeed that the automatic memory management is a 
 major performance killer


 Eh, I'd say it is D's gc implementation specifically that is 
 the biggest worry rather than the concept. I think the .net gc 
 is seriously like 10x faster than D's implementation.


Yes, yes, you're right. However, not allocating at least in 
Phobos is one of the surest way to get near optimal performance, 
not to mention it's always more satisfying when you know that 
your program doesn't monopolize Mb of RAM to do even the simplest 
task.



 Jun 30 2013



  parent reply David <d dav1d.de>  writes:


Am 30.06.2013 22:53, schrieb SomeDude:

 On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:

 On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:

 It seems indeed that the automatic memory management is a major
 performance killer


 Eh, I'd say it is D's gc implementation specifically that is the
 biggest worry rather than the concept. I think the .net gc is
 seriously like 10x faster than D's implementation.


 
 Yes, yes, you're right. However, not allocating at least in Phobos is
 one of the surest way to get near optimal performance, not to mention
 it's always more satisfying when you know that your program doesn't
 monopolize Mb of RAM to do even the simplest task.


Wow, I don't care if it does, especially if it is only a simple task.
Memory is there to be used. If I want to avoid memory useage, I wouldn't
be using D.



 Jun 30 2013



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Monday, July 01, 2013 00:35:45 David wrote:

 Am 30.06.2013 22:53, schrieb SomeDude:

 On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:

 On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:

 It seems indeed that the automatic memory management is a major
 performance killer


 
 Eh, I'd say it is D's gc implementation specifically that is the
 biggest worry rather than the concept. I think the .net gc is
 seriously like 10x faster than D's implementation.


 
 Yes, yes, you're right. However, not allocating at least in Phobos is
 one of the surest way to get near optimal performance, not to mention
 it's always more satisfying when you know that your program doesn't
 monopolize Mb of RAM to do even the simplest task.


 
 Wow, I don't care if it does, especially if it is only a simple task.
 Memory is there to be used. If I want to avoid memory useage, I wouldn't
 be using D.


For simple stuff, I really don't care much about how much memory a program uses 
as long as it's not an outrageous amount. So personally, I don't find it more 
satisfying to know that my program doesn't monopolize MB of RAM. And honestly, 
I have enough RAM on my system, that you _can't_ monopolize RAM if you're not 
talking in GB. However, memory usage matters a _lot_ for programs that need to 
be really performant (especially when they're larger programs), and having the 
GC kick in a lot due to how much memory you're using can be a real performance 
killer. So, being able to minimize the memory footprint of your program is 
critical, because there are cases where you _really_ care, but there are also 
plenty of cases where you really don't.

- Jonathan M Davis



 Jun 30 2013



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 30 Jun 2013 18:35:45 -0400, David <d dav1d.de> wrote:


 Am 30.06.2013 22:53, schrieb SomeDude:

 On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote:

 On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote:

 It seems indeed that the automatic memory management is a major
 performance killer


 Eh, I'd say it is D's gc implementation specifically that is the
 biggest worry rather than the concept. I think the .net gc is
 seriously like 10x faster than D's implementation.


 Yes, yes, you're right. However, not allocating at least in Phobos is
 one of the surest way to get near optimal performance, not to mention
 it's always more satisfying when you know that your program doesn't
 monopolize Mb of RAM to do even the simplest task.


 Wow, I don't care if it does, especially if it is only a simple task.
 Memory is there to be used. If I want to avoid memory useage, I wouldn't
 be using D.


The difference between using 300 MB of ram and 1GB of ram on an online  
virtual private server can be about $30/month.

I recently figured out that vibe.d's idea of "just in time" compile and  
module load would not work on my VPS because dmd takes 500MB to compile  
simple vibe.d hello world.

I think memory usage is still important.  Many people don't consider that  
their computer is running hundreds of programs at a time.  If each one of  
those "didn't care" about memory usage, the one that you are currently  
interested in would not have any breathing room.

-Steve



 Jun 30 2013



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2013-07-01 01:14, Steven Schveighoffer wrote:


 I think memory usage is still important.  Many people don't consider
 that their computer is running hundreds of programs at a time.  If each
 one of those "didn't care" about memory usage, the one that you are
 currently interested in would not have any breathing room.


I quite often run out of memory at work on my machine with 6GB of RAM 
when coding Ruby on Rails. I don't know if there's something I do with 
the code but sometimes something happens in the Ruby code making the 
Rails server take over 1GB of RAM from 300MB, the same thing happens 
with the web browser at the same time. Suddenly it decided to eat 2GB of 
extra RAM.

-- 
/Jacob Carlborg



 Jul 01 2013



  parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 1 July 2013 at 09:14:07 UTC, Jacob Carlborg wrote:

 On 2013-07-01 01:14, Steven Schveighoffer wrote:


 I think memory usage is still important.  Many people don't 
 consider
 that their computer is running hundreds of programs at a time.
  If each
 one of those "didn't care" about memory usage, the one that 
 you are
 currently interested in would not have any breathing room.


 I quite often run out of memory at work on my machine with 6GB 
 of RAM when coding Ruby on Rails. I don't know if there's 
 something I do with the code but sometimes something happens in 
 the Ruby code making the Rails server take over 1GB of RAM from 
 300MB, the same thing happens with the web browser at the same 
 time. Suddenly it decided to eat 2GB of extra RAM.


My 4 gig machine needs swap space... just to surf on internet.

I think one of the biggest culprits are not the programs, but 
today's *shiny* and *exciting* websites...



 Jul 01 2013



  parent reply David <d dav1d.de>  writes:


 My 4 gig machine needs swap space... just to surf on internet.
 
 I think one of the biggest culprits are not the programs, but today's
 *shiny* and *exciting* websites...


Wow!
Then you must be running Windows...

I have currently 1.5Gb used, with ~30 tabs open, Kdevelop, a few
terminals and Thunderbird (and thunderbird takes the most ram!)



 Jul 01 2013



  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Monday, 1 July 2013 at 14:11:50 UTC, David wrote:

 My 4 gig machine needs swap space... just to surf on internet.
 
 I think one of the biggest culprits are not the programs, but 
 today's
 *shiny* and *exciting* websites...


 Wow!
 Then you must be running Windows...

 I have currently 1.5Gb used, with ~30 tabs open, Kdevelop, a few
 terminals and Thunderbird (and thunderbird takes the most ram!)


Firefox with ~70 tabs including an hour long youtube video, 
matlab and ipython all running at once: Used memory + swap still 
under 4GB.

It's worth bearing in mind that just because you've got swap 
space being used, doesn't mean you're actually short on memory.



 Jul 01 2013



prev sibling  parent  "Gabi" <galim120 bezeqint.net>  writes:


 C++ in non trivial programs, if one cares about not allocating 
 too much on the heap. It seems indeed that the automatic memory 
 management is a major performance killer, and it's not always 
 easy to know in advance what the overall performance of D code 
 will be. But the less work for the GC, the better.


I wonder why is that.. Why would deleting 1 million objects in 
C++ (using std::shared_ptr for example) have to be slower than 
the garbage collection freeing a big chunk of million objects all 
at once. I mean, it would probably block the main thread but the 
avg rate of deleting objects shouldn't differ from manually doing 
so right ? So the main issue would be unpredictable pauses 
(what's a typical delay to expect from cleaning 1000000 objects?) 
of the main thread and not avg performance I think..


 So yes, one can get stellar performance out of D, but I would 
 say right out of the box, it's not automatic, it does require 
 some work where high performance is needed.


Any other tips to get high performance besides the GC issue?



 Jun 30 2013



prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com>  writes:


On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:

 The first question that came up was how it stands up with C++ 
 performance wise ?


D, like C++, is a natively ahead-of-time compiled language. D 
also has very similar modelling, abstraction capabilities, and 
idioms to C++. The end result is that D programs are typically as 
fast as C++ programs, sometimes faster, sometimes slower.

It does depend on the compiler though. LDC and GDC will typically 
produce considerably faster code than DMD.

It's also worth mentioned that D's garbage collector isn't quite 
state-of-the-art, so programs that make heavy use of the GC may 
perform poorly. This will definitely improve, and there are 
already existing better GC implementations out there.



 Jun 30 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


Would love an example that demonstrates it!



 Jun 30 2013



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


Anything involving taking a lot of substrings is likely to be faster in D 
thanks to slices (which is one of the main reasons that Tango's xml parser is 
so lightning fast). You could write the same code in C++, but it's harder, 
because slices aren't built-in, and you have no GC, probably forcing you to 
create your own string type that supports slices and does reference counting 
if you want a similar effect. However, you do have to be somewhat careful with 
string processing and Phobos functions, because you could end up doing more 
decoding than you might want, which would slow down the code (as Phobos 
strives to be Unicode correct by default, whereas C++'s STL doesn't). But 
anything which heavily uses slicing stands a good chance of creaming C++ code 
doing the same task. So, in general, well-written parsers written in D should 
beat well-written parsers written in C++.

- Jonathan M Davis



 Jun 30 2013



 next sibling parent reply Marco Leise <Marco.Leise gmx.de>  writes:


Am Sun, 30 Jun 2013 22:55:26 +0200
schrieb "Gabi" <galim120 bezeqint.net>:


 I wonder why is that.. Why would deleting 1 million objects in=20
 C++ (using std::shared_ptr for example) have to be slower than=20
 the garbage collection freeing a big chunk of million objects all=20
 at once.


I have no numbers, but I think especially when you have complex graph
structures linked with pointers, the GC needs a while to follow all
the links and mark the referenced objects as still in use. And this
will be done every now and then when you allocate N new objects.


 I mean, it would probably block the main thread but the=20
 avg rate of deleting objects shouldn't differ from manually doing=20
 so right ? So the main issue would be unpredictable pauses=20
 (what's a typical delay to expect from cleaning 1000000 objects?)=20
 of the main thread and not avg performance I think..


The current implementation is a stop-the-world GC. It freezes all
threads known to the runtime. (Excluding threads created with the
native API and not registered with the runtime.)


 Any other tips to get high performance besides the GC issue?


=46rom the top of my head:

o Mark classes or single methods final when you can, as
  bearophile pointed out. (shaves off a few % in object heavy
  code)
o See if you can use structs instead of classes, they don't
  have virtual methods and are simpler to allocate/return on
  the stack.
o When working with strings, be aware that foreach iterates
  them by byte, whereas Phobos - in an attempt to do the right
  thing - iterates them by dchar (UTF-32 code point), which
  means a UTF-8 decoding process.
o Some of Phobos is very fast, some is very slow. If you care
  much about performance evaluate different approaches before
  jumping to conclusions.

As an example of the two last points combined, take finding
a '\0' in a string (compiled with DMD):
algorithm.countUntil:     355213 per second
std.string.indexOf  :   33121530 per second (~100x faster)


Am Sun, 30 Jun 2013 19:53:05 -0700
schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


=20
 Would love an example that demonstrates it!


=20
 Anything involving taking a lot of substrings is likely to be faster in D=


=20

 thanks to slices (which is one of the main reasons that Tango's xml parse=


r is=20

 so lightning fast).


I think he referred to the DMD backend being faster than
GDC/LDC sometimes, no ?

--=20
Marco



 Jun 30 2013



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Monday, July 01, 2013 06:27:15 Marco Leise wrote:

 Am Sun, 30 Jun 2013 22:55:26 +0200
 
 schrieb "Gabi" <galim120 bezeqint.net>:

 I wonder why is that.. Why would deleting 1 million objects in
 C++ (using std::shared_ptr for example) have to be slower than
 the garbage collection freeing a big chunk of million objects all
 at once.


 
 I have no numbers, but I think especially when you have complex graph
 structures linked with pointers, the GC needs a while to follow all
 the links and mark the referenced objects as still in use. And this
 will be done every now and then when you allocate N new objects.


The other thing to consider is that when the GC runs, it has to figure out 
whether anything needs to be collected. And regardless of whether anything 
actually needs to be collected, it has to go through all of the various 
references to mark them and then to sweep them. With deterministic 
destruction, you don't have to do that. If you have a fairly small number of 
heap allocations in your program, it's generally not a big deal. But if you're 
constantly allocating and deallocating small objects, then the GC is going to 
be run a lot more frequently, and it'll have a lot more objects to have to 
examine. So, having lots of small objects which are frequently being created 
and destroyed is pretty much guaranteed to tank your performance if they're 
being allocated by the GC. You really want reference counting for those sorts 
of situations.


 I think he referred to the DMD backend being faster than
 GDC/LDC sometimes, no ?


Maybe someone did, but if that's ever true, it's rare. It's pretty much always 
the case that the dmd backend is inferior with regards to optimizations. It 
just isn't getting worked on like the other backends are. Where it shines is 
compilation speed.

- Jonathan M Davis



 Jun 30 2013



  parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Monday, 1 July 2013 at 04:50:29 UTC, Jonathan M Davis wrote:

 On Monday, July 01, 2013 06:27:15 Marco Leise wrote:

 Am Sun, 30 Jun 2013 22:55:26 +0200
 
 schrieb "Gabi" <galim120 bezeqint.net>:

 I wonder why is that.. Why would deleting 1 million objects 
 in
 C++ (using std::shared_ptr for example) have to be slower 
 than
 the garbage collection freeing a big chunk of million 
 objects all
 at once.


 
 I have no numbers, but I think especially when you have 
 complex graph
 structures linked with pointers, the GC needs a while to 
 follow all
 the links and mark the referenced objects as still in use. And 
 this
 will be done every now and then when you allocate N new 
 objects.


 The other thing to consider is that when the GC runs, it has to 
 figure out
 whether anything needs to be collected. And regardless of 
 whether anything
 actually needs to be collected, it has to go through all of the 
 various
 references to mark them and then to sweep them. With 
 deterministic
 destruction, you don't have to do that. If you have a fairly 
 small number of
 heap allocations in your program, it's generally not a big 
 deal. But if you're
 constantly allocating and deallocating small objects, then the 
 GC is going to
 be run a lot more frequently, and it'll have a lot more objects 
 to have to
 examine. So, having lots of small objects which are frequently 
 being created
 and destroyed is pretty much guaranteed to tank your 
 performance if they're
 being allocated by the GC. You really want reference counting 
 for those sorts
 of situations.


This is only true in the current D GC's situation.

Modern parallel compacting GCs don't suffer from this.

--
Paulo



 Jun 30 2013



prev sibling  parent  "Joakim" <joakim airpost.net>  writes:


On Monday, 1 July 2013 at 04:27:46 UTC, Marco Leise wrote:

 Am Sun, 30 Jun 2013 19:53:05 -0700
 schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander 
 wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


 
 Anything involving taking a lot of substrings is likely to be 
 faster in D thanks to slices (which is one of the main reasons 
 that Tango's xml parser is so lightning fast).


 I think he referred to the DMD backend being faster than
 GDC/LDC sometimes, no ?


No, he was talking about D being sometimes faster than C++, from 
this quote, "The end result is that D programs are typically as 
fast as C++ programs, sometimes faster, sometimes slower."  So 
Jonathan got the comparison right.



 Jun 30 2013



prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:

 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


 Anything involving taking a lot of substrings is likely to be 
 faster in D
 thanks to slices (which is one of the main reasons that Tango's 
 xml parser is
 so lightning fast). You could write the same code in C++, but 
 it's harder,
 because slices aren't built-in, and you have no GC, probably 
 forcing you to
 create your own string type that supports slices and does 
 reference counting
 if you want a similar effect.

 - Jonathan M Davis


Well... in "C++", a slice is called an iterator pair. If you just:
typedef std::pair<std::string::const_iterator, const_itrator> 
string_slice;

Then there is no reason you can't do it... The only "problem" is 
that it is not a standard semantic in C++, so nobody ever thinks 
about doing this, and much less actually ever does it. There is a 
*little* bit of barrier to entry too.

I've done this once about two years ago (before I knew about D) 
because I needed a "subview" of a vector. My typedef's name was 
"shallow_vector". It was a fun experience given I didn't know 
about the range concept back then :)

In any case, if you *do* want to go there, it doesn't really 
require you creating that much new stuff, especially not your own 
string/vector type.



 Jun 30 2013



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Monday, July 01, 2013 08:28:54 monarch_dodra wrote:

 On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:

 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


 
 Anything involving taking a lot of substrings is likely to be
 faster in D
 thanks to slices (which is one of the main reasons that Tango's
 xml parser is
 so lightning fast). You could write the same code in C++, but
 it's harder,
 because slices aren't built-in, and you have no GC, probably
 forcing you to
 create your own string type that supports slices and does
 reference counting
 if you want a similar effect.
 
 - Jonathan M Davis


 
 Well... in "C++", a slice is called an iterator pair. If you just:
 typedef std::pair<std::string::const_iterator, const_itrator>
 string_slice;
 
 Then there is no reason you can't do it... The only "problem" is
 that it is not a standard semantic in C++, so nobody ever thinks
 about doing this, and much less actually ever does it. There is a
 *little* bit of barrier to entry too.
 
 I've done this once about two years ago (before I knew about D)
 because I needed a "subview" of a vector. My typedef's name was
 "shallow_vector". It was a fun experience given I didn't know
 about the range concept back then :)
 
 In any case, if you *do* want to go there, it doesn't really
 require you creating that much new stuff, especially not your own
 string/vector type.


It does if you don't want to code your stuff in a manner that there's a
specific 
piece of code which owns the string, since you've now separated the string 
from the slice. Sure, it's feasible, but it's not the same thing and requires 
you to code differently than you'd do it in D. Regardless, it requires you to 
code very differently from how you'd do it in C++, so while it's quite possible 
to do something similar to slices in C++, pretty much no one does.

- Jonathan M Davis



 Jun 30 2013



prev sibling  parent  "Brad Anderson" <eco gnuk.net>  writes:


On Monday, 1 July 2013 at 06:28:57 UTC, monarch_dodra wrote:

 On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:

 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander 
 wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


 Anything involving taking a lot of substrings is likely to be 
 faster in D
 thanks to slices (which is one of the main reasons that 
 Tango's xml parser is
 so lightning fast). You could write the same code in C++, but 
 it's harder,
 because slices aren't built-in, and you have no GC, probably 
 forcing you to
 create your own string type that supports slices and does 
 reference counting
 if you want a similar effect.

 - Jonathan M Davis


 Well... in "C++", a slice is called an iterator pair. If you 
 just:
 typedef std::pair<std::string::const_iterator, const_itrator> 
 string_slice;

 Then there is no reason you can't do it... The only "problem" 
 is that it is not a standard semantic in C++, so nobody ever 
 thinks about doing this, and much less actually ever does it. 
 There is a *little* bit of barrier to entry too.

 I've done this once about two years ago (before I knew about D) 
 because I needed a "subview" of a vector. My typedef's name was 
 "shallow_vector". It was a fun experience given I didn't know 
 about the range concept back then :)

 In any case, if you *do* want to go there, it doesn't really 
 require you creating that much new stuff, especially not your 
 own string/vector type.


Boost recently added string_ref, "a non-owning reference to a 
string": 
http://www.boost.org/doc/libs/1_53_0/libs/utility/doc/html/string_ref.html

Gets you something similar to slices but is inherently more 
dangerous to use than GC backed slices.



 Jul 01 2013



prev sibling  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


On Monday, 1 July 2013 at 02:53:24 UTC, Jonathan M Davis wrote:

 On Monday, July 01, 2013 04:37:43 Mehrdad wrote:

 On Sunday, 30 June 2013 at 20:49:28 UTC, Peter Alexander wrote:

 sometimes faster


 
 Would love an example that demonstrates it!


 Anything involving taking a lot of substrings is likely to be 
 faster in D thanks to slices



That doesn't mean D is "faster". It just means it's less painful 
to get the same performance.


Regarding what someone else mentioned, I wasn't talking about the 
backend either.

As an example of what I was looking for, consider that people 
claim a GC can be faster than manual memory management. If that's 
the scenario we're talking about, then what I was asking for is 
to see piece of _code_ (not a hand-wavy explanation!) that 
demonstrates GC-based code being faster than non-GC-based code.

If it's a different feature (I don't know what), then I'd like to 
know what it is strictly in terms of performance.


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++.



 Jul 02 2013



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


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.



 Jul 02 2013



  parent  "Mehrdad" <wfunction hotmail.com>  writes:


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++.



 Jul 04 2013



prev sibling  parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


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. :-)



 Jul 03 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


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.



 Jul 04 2013



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Jul 04 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


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?



 Jul 04 2013



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Jul 04 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


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.



 Jul 04 2013



 next sibling parent reply "Mehrdad" <wfunction hotmail.com>  writes:


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.



 Jul 04 2013



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Jul 04 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


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.



 Jul 04 2013



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Jul 04 2013



prev sibling next sibling parent  Paulo Pinto <pjmlp progtools.org>  writes:


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



 Jul 04 2013



prev sibling  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Thu, Jul 04, 2013 at 11:20:47PM +0200, Mehrdad wrote:

 On Thursday, 4 July 2013 at 21:11:57 UTC, Jonathan M Davis wrote:


[...]

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.


Really? I thought there are conservative GC's out there for C++ (and
even C, IIRC). It's not too much different from D's GC, actually. You
just override malloc/free in the library (or operator new and operator
delete, as the case may be), then have a GC thread scan the runtime
stack for roots.

Of course, only a conservative GC is possible, since you don't know
what's a real pointer and what's just an integer value that happens to
look like a pointer. But it's definitely possible.


T

-- 
Без труда не выловишь и рыбку из пруда. 



 Jul 04 2013



  parent reply "Mehrdad" <wfunction hotmail.com>  writes:


On Thursday, 4 July 2013 at 22:28:18 UTC, H. S. Teoh wrote:

 Really? I thought there are conservative GC's out there for C++



http://forum.dlang.org/thread/xjvlpegvhcwioqrjhzsn forum.dlang.org?page=5#post-mwnwtdnbglcwoneqqoao:40forum.dlang.org



 Jul 04 2013



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Jul 05, 2013 at 01:45:24AM +0200, Mehrdad wrote:

 On Thursday, 4 July 2013 at 22:28:18 UTC, H. S. Teoh wrote:

Really? I thought there are conservative GC's out there for C++


 
 
 http://forum.dlang.org/thread/xjvlpegvhcwioqrjhzsn forum.dlang.org?page=5#post-mwnwtdnbglcwoneqqoao:40forum.dlang.org


http://en.wikipedia.org/wiki/Boehm_garbage_collector

The GC doesn't need to be part of the language (though it's nice if it
is).


T

-- 
"Uhh, I'm still not here." -- KD, while "away" on ICQ.



 Jul 04 2013



 next sibling parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Thursday, 4 July 2013 at 23:53:21 UTC, H. S. Teoh wrote:

 On Fri, Jul 05, 2013 at 01:45:24AM +0200, Mehrdad wrote:

 On Thursday, 4 July 2013 at 22:28:18 UTC, H. S. Teoh wrote:

Really? I thought there are conservative GC's out there for 
C++


 
 
 http://forum.dlang.org/thread/xjvlpegvhcwioqrjhzsn forum.dlang.org?page=5#post-mwnwtdnbglcwoneqqoao:40forum.dlang.org


 http://en.wikipedia.org/wiki/Boehm_garbage_collector

 The GC doesn't need to be part of the language (though it's 
 nice if it
 is).


 T


And technically since C++11 a GC is part of the language, since 
there is now an official GC API on the runtime, even though it is 
optional to provide a real GC in current standard.



 Jul 04 2013



prev sibling  parent  "Mehrdad" <wfunction hotmail.com>  writes:


On Thursday, 4 July 2013 at 23:53:21 UTC, H. S. Teoh wrote:

 On Fri, Jul 05, 2013 at 01:45:24AM +0200, Mehrdad wrote:

 On Thursday, 4 July 2013 at 22:28:18 UTC, H. S. Teoh wrote:

Really? I thought there are conservative GC's out there for 
C++


 
 
 http://forum.dlang.org/thread/xjvlpegvhcwioqrjhzsn forum.dlang.org?page=5#post-mwnwtdnbglcwoneqqoao:40forum.dlang.org


 http://en.wikipedia.org/wiki/Boehm_garbage_collector

 The GC doesn't need to be part of the language (though it's 
 nice if it
 is).


 T



A _conservative_ GC doesn't. A _precise_ GC does.



 Jul 05 2013



prev sibling  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 4 July 2013 22:04, Mehrdad <wfunction hotmail.com> wrote:

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


Not necessarily true, but your application at runtime may leak surplus
amounts of memory from hidden allocation calls without a GC. ;)


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 05 2013



prev sibling  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 4 July 2013 22:03, Mehrdad <wfunction hotmail.com> wrote:

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


I'd say built into the runtime, rather than language. And it is an
implementation detail on just how the GC tracks, allocates and
collects memory. :)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Jul 05 2013



prev sibling next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Gabi:


 The first question that came up was how it stands up with C++ 
 performance wise ?


In my experience if you write D code very similar to equivalent C 
or C++ code (this means using abstractions with enough care), and 
you use the ldc2 compiler with the right compilation switches 
(some of them are hidden), and you don't make mistakes in D 
coding (like leaving virtual functions, copying fixed static 
arrays when you want just a reference, and so on), then you get 
sufficiently similar performance to C or C++ code compiled with 
Clang.

Bye,
bearophile



 Jun 30 2013



prev sibling  parent  "Suliman" <bubnenkoff gmail.com>  writes:


Few time ago I had open http://versusit.org site about comparison 
of languages and technologies. I have some stuff about D, but 
still not directly compared with C++. If anybody want to help me 
with articles and systematization of material I would very thanks.



 Jun 30 2013