www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Post about comparing C, C++ and D performance with a real world

reply Antonio Corbi <notvalid ggmail.com> writes:
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
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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
parent reply Antonio Corbi <notvalid ggmail.com> writes:
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:
 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.
The code is in the github repo mentioned there. It has several branches. The application is built using meson (http://mesonbuild.com/). Antonio
Dec 07 2017
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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:

 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.
The code is in the github repo mentioned there. It has several branches. The application is built using meson (http://mesonbuild.com/). Antonio
Dec 07 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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 
 author
https://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
parent reply German Diago <germandiago gmail.com> writes:
On Thursday, 7 December 2017 at 14:09:35 UTC, Steven 
Schveighoffer wrote:
 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 author
You can see the compilation command line if you compile with ninja -v
Dec 11 2017
parent Daniel Kozak <kozzi11 gmail.com> writes:
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:

 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
You can see the compilation command line if you compile with ninja -v
Dec 11 2017
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
parent user1234 <user1234 12.nl> writes:
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:
 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.
Yes and the GDC version also explains the 7 leaks. These are quite certainly some old druntime bugs.
Dec 07 2017
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
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
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
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
prev sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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#L57
Wow, 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
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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=
.
 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
Wow, interesting that D uses less memory with that continue new char[1] i=
n
 there!

 Kind of funny that he didn't just use FILE * directly, it's totally
 available in D :)

 -Steve
Dec 07 2017
parent reply Kagamin <spam here.lot> writes:
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
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/9/17 5:55 AM, Kagamin wrote:
 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.
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. -Steve
Dec 09 2017
parent reply unleashy <lakeavenger gmail.com> writes:
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
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/9/17 12:11 PM, unleashy wrote:
 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
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... -Steve
Dec 09 2017
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
 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
Wow, interesting that D uses less memory with that continue new char[1] in there!
I would have thought that it just reuses the same pointer to the GC on each loop.
Dec 07 2017
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
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=
.
 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
Wow, interesting that D uses less memory with that continue new char[1] i=
n
 there!
I would have thought that it just reuses the same pointer to the GC on each loop.
Dec 07 2017
prev sibling next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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:
 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#L57
Wow, interesting that D uses less memory with that continue new char[1]
in
 there!
I would have thought that it just reuses the same pointer to the GC on each loop.
Dec 07 2017
parent reply Mengu <mengukagan gmail.com> writes:
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)Appender
wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Dec 07 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/7/17 8:11 PM, Mengu wrote:
 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)Appender
wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
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. -Steve
Dec 08 2017
next sibling parent Mengu <mengukagan gmail.com> writes:
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer 
wrote:
 On 12/7/17 8:11 PM, Mengu wrote:
 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)Appender
wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
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. -Steve
thanks for the explanation steve.
Dec 08 2017
prev sibling parent helxi <brucewayneshit gmail.com> writes:
On Friday, 8 December 2017 at 15:40:08 UTC, Steven Schveighoffer 
wrote:
 On 12/7/17 8:11 PM, Mengu wrote:
 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)Appender
wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
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. -Steve
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? :D
Dec 09 2017
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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)Appender
Correct. 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
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 12/07/2017 03:07 PM, Iain Buclaw wrote:
 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)Appender
Correct. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
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 Ali
Dec 07 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/7/17 6:07 PM, Iain Buclaw wrote:
 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)Appender
Correct. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
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. -Steve
Dec 08 2017