digitalmars.D - Post about comparing C, C++ and D performance with a real world
- Antonio Corbi (5/5) Dec 07 2017 Hello all,
- Timothee Cour (4/9) Dec 07 2017 is there a link to source code (C++,C,D) nor compile / runtime commands ...
- Antonio Corbi (5/17) Dec 07 2017 The code is in the github repo mentioned there. It has several
- Daniel Kozak (5/27) Dec 07 2017 Not much helpful, still does not know which compiler flags have been use...
- Steven Schveighoffer (6/10) Dec 07 2017 https://github.com/jpakkane/pkg-config/blob/d/meson.build
- German Diago (4/9) Dec 11 2017 You can see the compilation command line if you compile with
- Daniel Kozak (3/13) Dec 11 2017 Thanks, I will try that.
- Jonathan M Davis (16/20) Dec 07 2017 Honestly, I find the results a bit depressing, but a lot of that probabl...
- user1234 (4/16) Dec 07 2017 Yes and the GDC version also explains the 7 leaks. These are
- Daniel Kozak (28/53) Dec 07 2017 On my machine D is faster than his c++ version, so It does look good. I ...
- Russel Winder (11/11) Dec 07 2017 So who is going to do the experiment and write the best D code to solve
- Daniel Kozak (8/18) Dec 07 2017 This is not about write the best D code. It is about similar code to
- Steven Schveighoffer (6/12) Dec 07 2017 Wow, interesting that D uses less memory with that continue new char[1]
- Daniel Kozak (8/21) Dec 07 2017 Yes using FILE* directly could be the way. But using file.rawRead is st...
- Kagamin (7/10) Dec 09 2017 This can reflect absence of middle level resources like basic
- Steven Schveighoffer (8/18) Dec 09 2017 Yes, it would be nice to have a "If you do this in C, here's how you do
- unleashy (3/6) Dec 09 2017 What about this? https://dlang.org/ctod.html
- Steven Schveighoffer (11/18) Dec 09 2017 Haven't read that before, and while it's a nice primer, it's focused
- Iain Buclaw (4/14) Dec 07 2017 I would have thought that it just reuses the same pointer to the GC on
- Daniel Kozak (11/21) Dec 07 2017 Yes, it reuse the same pointer. But it still a little bit slower than
- Daniel Kozak (6/30) Dec 07 2017 The other slowdown is caused by concatenation. Because std::string +=3D ...
- Mengu (3/5) Dec 07 2017 wait, i thought appenders performed better than concatenation. is
- Steven Schveighoffer (8/15) Dec 08 2017 You misunderstood. Appender is faster than ~= to a straight array,
- Iain Buclaw (4/6) Dec 07 2017 Correct. The semantics of ~= mean that the memory is copied around to
- =?UTF-8?Q?Ali_=c3=87ehreli?= (22/31) Dec 07 2017 You must have meant ~, not ~= because luckily, it is assumeSafeAppend
- Steven Schveighoffer (6/15) Dec 08 2017 Slightly incorrect. If an array is not marked with the append bit (or
Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html Antonio.
Dec 07 2017
is there a link to source code (C++,C,D) nor compile / runtime commands used? hard to reach any conclusion without this On Thu, Dec 7, 2017 at 1:55 AM, Antonio Corbi via Digitalmars-d <digitalmars-d puremagic.com> wrote:Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html Antonio.
Dec 07 2017
On Thursday, 7 December 2017 at 10:33:59 UTC, Timothee Cour wrote:is there a link to source code (C++,C,D) nor compile / runtime commands used? hard to reach any conclusion without this On Thu, Dec 7, 2017 at 1:55 AM, Antonio Corbi via Digitalmars-d <digitalmars-d puremagic.com> wrote:The code is in the github repo mentioned there. It has several branches. The application is built using meson (http://mesonbuild.com/). AntonioHello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html Antonio.
Dec 07 2017
Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author On Thu, Dec 7, 2017 at 12:35 PM, Antonio Corbi via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Thursday, 7 December 2017 at 10:33:59 UTC, Timothee Cour wrote:is there a link to source code (C++,C,D) nor compile / runtime commands used? hard to reach any conclusion without this On Thu, Dec 7, 2017 at 1:55 AM, Antonio Corbi via Digitalmars-d < digitalmars-d puremagic.com> wrote:The code is in the github repo mentioned there. It has several branches. The application is built using meson (http://mesonbuild.com/). AntonioHello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and- d-performance-with.html Antonio.
Dec 07 2017
On 12/7/17 6:46 AM, Daniel Kozak wrote:Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original authorhttps://github.com/jpakkane/pkg-config/blob/d/meson.build This should give an idea of the flags. Not sure exactly what it means, but I assume there's a way to increase verbosity and see exactly the flags being sent to gdc. -Steve
Dec 07 2017
On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote:On 12/7/17 6:46 AM, Daniel Kozak wrote:You can see the compilation command line if you compile with ninja -vNot much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author
Dec 11 2017
Thanks, I will try that. On Mon, Dec 11, 2017 at 7:34 PM, German Diago via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote:On 12/7/17 6:46 AM, Daniel Kozak wrote:You can see the compilation command line if you compile with ninja -vNot much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author
Dec 11 2017
On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d wrote:Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-> with.htmlHonestly, I find the results a bit depressing, but a lot of that probably stems from the fact that it's not idiomatic D code, and any time you do more or less direct conversions, you run the risk of things not working as efficiently due to differences in the languages involved. The author does acknowledge that, but without refactoring the code to be more idiomatic, it makes D look bad - though the fact that it does better with memory than C or C++ does make the GC look better than you'd necessarily expect. It's certainly surprising that the GC is the _good_ part of the results. I do wonder what the results would look like with clang and ldc though, particularly since the version of gdc in Ubuntu is going to be pretty old. It might make no difference at all, or there could be a definite improvement, depending on what his code is doing and what has changed since the last gdc release. - Jonathan M Davis
Dec 07 2017
On Thursday, 7 December 2017 at 12:00:00 UTC, Jonathan M Davis wrote:On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d wrote:Yes and the GDC version also explains the 7 leaks. These are quite certainly some old druntime bugs.Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-> with.html[...] I do wonder what the results would look like with clang and ldc though, particularly since the version of gdc in Ubuntu is going to be pretty old.
Dec 07 2017
On my machine D is faster than his c++ version, so It does look good. I use his own repository so I do not know why his results are so different in my case: his c++ version with gcc: real 0m0,021s user 0m0,021s sys 0m0,000s his D version with DMD: real 0m0,018s user 0m0,015s sys 0m0,004s his D version with GDC: real 0m0,015s user 0m0,006s sys 0m0,010s his D version with LDC: real 0m0,030s user 0m0,025s sys 0m0,005s LDC is slower because on my system it use shared phobos library, so it takes some time to load it. all others (gcc,gdc and dmd use static libs) When I use shared phobos for dmd, I get real 0m0,032s user 0m0,024s sys 0m0,009s On Thu, Dec 7, 2017 at 1:00 PM, Jonathan M Davis via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d wrote:Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-> with.html Honestly, I find the results a bit depressing, but a lot of that probably stems from the fact that it's not idiomatic D code, and any time you do more or less direct conversions, you run the risk of things not working as efficiently due to differences in the languages involved. The author does acknowledge that, but without refactoring the code to be more idiomatic, it makes D look bad - though the fact that it does better with memory than C or C++ does make the GC look better than you'd necessarily expect. It's certainly surprising that the GC is the _good_ part of the results. I do wonder what the results would look like with clang and ldc though, particularly since the version of gdc in Ubuntu is going to be pretty old. It might make no difference at all, or there could be a definite improvement, depending on what his code is doing and what has changed since the last gdc release. - Jonathan M Davis
Dec 07 2017
So who is going to do the experiment and write the best D code to solve the problem, write the rebuttal article, and post it? It is good to get emotion going on the email list, but without external action D gets no positive marketing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 07 2017
This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart. One example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 On Thu, Dec 7, 2017 at 3:37 PM, Russel Winder via Digitalmars-d < digitalmars-d puremagic.com> wrote:So who is going to do the experiment and write the best D code to solve the problem, write the rebuttal article, and post it? It is good to get emotion going on the email list, but without external action D gets no positive marketing. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 07 2017
On 12/7/17 1:26 PM, Daniel Kozak wrote:This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart. One example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57Wow, interesting that D uses less memory with that continue new char[1] in there! Kind of funny that he didn't just use FILE * directly, it's totally available in D :) -Steve
Dec 07 2017
Yes using FILE* directly could be the way. But using file.rawRead is still possible. But it is better to use static array with length one. Other problem is with string. It would make sense make it out instead of ref and change it to empty string and use RefAppender. Dne 7. 12. 2017 9:00 odp. napsal u=C5=BEivatel "Steven Schveighoffer via Digitalmars-d" <digitalmars-d puremagic.com>:On 12/7/17 1:26 PM, Daniel Kozak wrote:.This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart=nOne example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57Wow, interesting that D uses less memory with that continue new char[1] i=there! Kind of funny that he didn't just use FILE * directly, it's totally available in D :) -Steve
Dec 07 2017
On Thursday, 7 December 2017 at 21:38:57 UTC, Daniel Kozak wrote:Yes using FILE* directly could be the way. But using file.rawRead is still possible. But it is better to use static array with length one.This can reflect absence of middle level resources like basic optimization techniques for D - it's too complex for tour and too obvious for experts. For interoperability with FILE* one must be really familiar with slices: remember in C arrays just work. And when one hears about memory allocation optimization in D one thinks about ranges, which is a bit involved already.
Dec 09 2017
On 12/9/17 5:55 AM, Kagamin wrote:On Thursday, 7 December 2017 at 21:38:57 UTC, Daniel Kozak wrote:Yes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate. In terms of arrays, they aren't much different in D than in C. Just with better checks for safety. In fact, you can use C arrays (T*) in D just fine, with the same syntax and problems. -SteveYes using FILE* directly could be the way. But using file.rawRead is still possible. But it is better to use static array with length one.This can reflect absence of middle level resources like basic optimization techniques for D - it's too complex for tour and too obvious for experts. For interoperability with FILE* one must be really familiar with slices: remember in C arrays just work. And when one hears about memory allocation optimization in D one thinks about ranges, which is a bit involved already.
Dec 09 2017
On Saturday, 9 December 2017 at 14:00:16 UTC, Steven Schveighoffer wrote:Yes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate.What about this? https://dlang.org/ctod.html
Dec 09 2017
On 12/9/17 12:11 PM, unleashy wrote:On Saturday, 9 December 2017 at 14:00:16 UTC, Steven Schveighoffer wrote:Haven't read that before, and while it's a nice primer, it's focused mostly on the language, not the library (and kind of is a "look what D does better than C" post). However, stuff like i/o, networking, string manipulation, etc would be useful. In fact, a "recipe" guide keyed on what you want to accomplish would be cool. Maybe it already exists :) I'm ashamed to admit I bought Adam Ruppe's book "D Cookbook" when he announced it at dconf 2014, but still haven't read it yet... -SteveYes, it would be nice to have a "If you do this in C, here's how you do it in D" guide. It could be part of the tour, for sure. Just tag it intermediate.What about this? https://dlang.org/ctod.html
Dec 09 2017
On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 12/7/17 1:26 PM, Daniel Kozak wrote:I would have thought that it just reuses the same pointer to the GC on each loop.This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart. One example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57Wow, interesting that D uses less memory with that continue new char[1] in there!
Dec 07 2017
Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory Dne 7. 12. 2017 11:04 odp. napsal u=C5=BEivatel "Iain Buclaw via Digitalmar= s-d" < digitalmars-d puremagic.com>: On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 12/7/17 1:26 PM, Daniel Kozak wrote:.This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart=nOne example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57Wow, interesting that D uses less memory with that continue new char[1] i=there!I would have thought that it just reuses the same pointer to the GC on each loop.
Dec 07 2017
The other slowdown is caused by concatenation. Because std::string +=3D is more simillar to std.array.(Ref)Appender Dne 7. 12. 2017 11:33 odp. napsal u=C5=BEivatel "Daniel Kozak" <kozzi11 gma= il.com:Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory Dne 7. 12. 2017 11:04 odp. napsal u=C5=BEivatel "Iain Buclaw via Digitalm=ars-d"<digitalmars-d puremagic.com>: On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com> wrote:ofOn 12/7/17 1:26 PM, Daniel Kozak wrote:This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port =counterpart.C/C++. He made many mistakes which make it slower than C/C++inOne example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57Wow, interesting that D uses less memory with that continue new char[1]there!I would have thought that it just reuses the same pointer to the GC on each loop.
Dec 07 2017
On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appenderwait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Dec 07 2017
On 12/7/17 8:11 PM, Mengu wrote:On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there. Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance. -SteveThe other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appenderwait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Dec 08 2017
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer wrote:On 12/7/17 8:11 PM, Mengu wrote:thanks for the explanation steve.On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there. Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance. -SteveThe other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appenderwait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Dec 08 2017
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer wrote:On 12/7/17 8:11 PM, Mengu wrote:As a new comer, I find these very educational. I wish there was a documentation or a book to warn D learners about these pitfalls. "Effective D" when? :DOn Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there. Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance. -SteveThe other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appenderwait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Dec 09 2017
On 7 December 2017 at 23:39, Daniel Kozak <kozzi11 gmail.com> wrote:The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)AppenderCorrect. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
Dec 07 2017
On 12/07/2017 03:07 PM, Iain Buclaw wrote:On 7 December 2017 at 23:39, Daniel Kozak <kozzi11 gmail.com> wrote:You must have meant ~, not ~= because luckily, it is assumeSafeAppend when there is just one slice. ~= is not that bad in that case: import std.stdio; void main() { int[] a; foreach (i; 0 .. 10) { a ~= i; writeln(a.ptr); } } 7F621818D020 7F621818D020 7F621818D020 7F621818C100 7F621818C100 7F621818C100 7F621818C100 7F621818B040 7F621818B040 7F621818B040 AliThe other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)AppenderCorrect. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
Dec 07 2017
On 12/7/17 6:07 PM, Iain Buclaw wrote:On 7 December 2017 at 23:39, Daniel Kozak <kozzi11 gmail.com> wrote:Slightly incorrect. If an array is not marked with the append bit (or not even part of the GC), it is copied on the *first* append. However, it is copied to a new GC block that DOES have the bit set. Further appends are amortized. -SteveThe other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)AppenderCorrect. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
Dec 08 2017