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 ?

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

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 ?

of D anymore. ;)
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
parent 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 ->

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


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

of D anymore. ;)

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

Jun 30 2013
prev sibling next sibling parent "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 ?

use of D anymore. ;)

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
prev sibling 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 ?

use of D anymore. ;)

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

use of D anymore. ;)

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

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 parse=

 so lightning fast).

I think he referred to the DMD backend being faster than GDC/LDC sometimes, no ? --=20 Marco
Jun 30 2013
prev sibling next sibling parent 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
prev sibling next 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 ?

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 "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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--e89a8f50352803f6ae04e06ed277
Content-Type: text/plain; charset=ISO-8859-1

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

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


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'; --e89a8f50352803f6ae04e06ed277 Content-Type: text/html; charset=ISO-8859-1 <p><br> On Jul 1, 2013 7:16 AM, &quot;dennis luehring&quot; &lt;<a href="mailto:dl.soluz gmx.net">dl.soluz gmx.net</a>&gt; wrote:<br> &gt;<br> &gt; Am 01.07.2013 03:07, schrieb Kapps:<br> &gt;<br> &gt;&gt; If you&#39;re concerned about performance, I&#39;d recommend against<br> &gt;&gt; using DMD for your release builds. GDC and LDC will give much<br> &gt;&gt; better performance, and GDC works perfectly fine on Windows. LDC<br> &gt;&gt; has some problems with exception handling AFAIK on Windows.<br> &gt;<br> &gt;<br> &gt; GDC got the same Exception problems like LDC - no support for SEH<br> &gt; but Exceptions are working - only the Windows-internal-Exception -&gt; D-Exception transition is not working properbly<br> &gt;<br> &gt; but even using Visual Studio you need to add special flags or using __try, __catch to get these - so normaly not a problem<br> &gt;</p> <p>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.</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) = (c &amp; 0x0f) + &#39;0&#39;;</p> --e89a8f50352803f6ae04e06ed277--
Jul 01 2013
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next 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 next sibling parent "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
prev sibling next sibling 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 next 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling 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
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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next 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 next 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 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