www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The nail in the coffin of C++ or why don't GO there...

reply Ervin Bosenbacher <ervin.bosenbacher gmail.com> writes:
Just would like to share something. For months I couldn't decide 
what language to use for my pet project, analysed dozens of 
languages from rust to go and I always fell back to C++ 
(performance is critical for me). After rust I had a look at 
DLang but as a C++ veteran I had my (wrong) feelings, prejudices 
etc but I got infected and started to go down a long route of 
trying to accept it and trying to love it. I am a slow learner 
but forced to open my mind. I am also a Python dev so I kinda 
liked the syntax and the simplicity of the language, the speed of 
compilation and execution was also appealing but still... But 
then something has happened which basically helped to make up my 
mind and to go with D finally.

 From the  Programming in D book i  typed in the below code, I use 
Sublime.

```
import std.stdio : writeln;

void main()
{
     int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 
30, 31 ];
     int[] first = months[0 .. 3];
     int[] second = months[3 .. 6];
     int[] third = months[6 .. 9];
     int[] fourth = months[9 .. 12];
     writeln(first);
     writeln(second);
     writeln(third);
     writeln(fourth);
}
```

Then I have decided to reimplement this in C++. The code is not 
perfect hacked it together on the train. The length and the 
complexity is already on the negative side.

#include <iostream>
#include <array>
#include <iterator>

using namespace std;

template<class X, class Y>
X slice(const Y& src, const size_t start, const size_t end)
{
     X dst;
     std::copy(src.begin() + start, src.begin() + end, 
dst.begin());
     return dst;
}

template <class T, std::size_t N>
ostream& operator<<(ostream& o, const array<T, N>& arr)
{
         std::cout << "[";
         for (auto& elem : arr) {
                 std::cout << elem;
                 if (&elem != &arr.back()) printf(", ");
         }
         std::cout << "]";
         return o;
}

int main() {

         array<int, 12> _arr = { 31, 28, 31, 30, 31, 30, 31, 31, 
30, 31, 30, 31 };
         array<int, 3> first = slice<decltype(first)>(_arr, 0, 3);
         array<int, 3> second = slice<decltype(second)>(_arr, 3, 
6);
         array<int, 3> third = slice<decltype(third)>(_arr, 6, 9);
         array<int, 3> fourth = slice<decltype(fourth)>(_arr, 9, 
12);

         cout << first << endl;
         cout << second << endl;
         cout << third << endl;
         cout << fourth << endl;
}

Then  came the performance test, here we go:

Performance test:
rvinMacBookProLimegg:source ervinbosenbacher$ time ./app
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real	0m0.004s
user	0m0.001s
sys	0m0.001s

ErvinMacBookProLimegg:source ervinbosenbacher$ time ./a.out
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real	0m0.004s
user	0m0.001s
sys	0m0.002s

That is the same, that came as a shock to me.

Happy coding al!
Mar 29
next sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Thursday, 30 March 2017 at 06:58:30 UTC, Ervin Bosenbacher 
wrote:
 
 That is the same, that came as a shock to me.
I believe for this slicing D might be even faster for a larger example/megaloop, because slicing does not necessarily copy unless needed. As you say the key is being able to write better, shorter code. Happy coding!
Mar 30
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:
 That is the same, that came as a shock to me.
most compilers (for many languages) can optimize your super-trivial example down to nothing - for at least the last 10 years or more so whats the point? you're talkin about "performance is critical for me" but missing even minor knowledge about todays compiler powers? for a benchmark you need: -loops, running millions of times, preventing IO and do now fall into the completely-optimized-to-nothing-trap etc.
Mar 30
next sibling parent Ervin Bosenbacher <ervin.bosenbacher gmail.com> writes:
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:
 Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:
 That is the same, that came as a shock to me.
most compilers (for many languages) can optimize your super-trivial example down to nothing - for at least the last 10 years or more so whats the point? you're talkin about "performance is critical for me" but missing even minor knowledge about todays compiler powers? for a benchmark you need: -loops, running millions of times, preventing IO and do now fall into the completely-optimized-to-nothing-trap etc.
yes it was a quick hack. I try it again. Optimizations were turned on -O3 in case of gcc -O i case of dmd. But I am convinced that D language and is sufficiently good case for myself. First I wanted to go with C++/C/Python trio but that I ca replace with one language getting rid of additional complexities and other stuff. I agree compilers are not my thing so I will have a look deeper. Thx for the comment. Happy coding!
Mar 30
prev sibling next sibling parent reply Ervin Bosenbacher <ervin.bosenbacher gmail.com> writes:
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:
 Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:
 That is the same, that came as a shock to me.
most compilers (for many languages) can optimize your super-trivial example down to nothing - for at least the last 10 years or more so whats the point? you're talkin about "performance is critical for me" but missing even minor knowledge about todays compiler powers? for a benchmark you need: -loops, running millions of times, preventing IO and do now fall into the completely-optimized-to-nothing-trap etc.
Tried again, threw in summing up a number 10 million times and repeat the arrays 10 million times, I have used arrays on the stack for the D version. And when I am talking about performance I am curious about CPU bound stuff. The D version: import std.stdio; void main() { long sum = 0; foreach (long i; 0 .. 10000000) { int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 ]; int[3] first = months[0 .. 3]; int[3] second = months[3 .. 6]; int[3] third = months[6 .. 9]; int[3] fourth = months[9 .. 12]; sum += i; } writeln(sum); } The C++11 version: #include <iostream> #include <array> #include <iterator> using namespace std; template<class X, class Y> X CopyArray(const Y& src, const size_t start, const size_t end) { X dst; std::copy(src.begin() + start, src.begin() + end, dst.begin()); return dst; } template <class T, std::size_t N> ostream& operator<<(ostream& o, const array<T, N>& arr) { std::cout << "["; for (auto& elem : arr) { std::cout << elem; if (&elem != &arr.back()) printf(", "); } std::cout << "]"; return o; } int main() { long sum = 0; for (long i = 0; i < 10000000; i++) { array<int, 12> _arr = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; array<int, 3> first = CopyArray<decltype(first)>(_arr, 0, 3); array<int, 3> second = CopyArray<decltype(second)>(_arr, 3, 6); array<int, 3> third = CopyArray<decltype(third)>(_arr, 6, 9); array<int, 3> fourth = CopyArray<decltype(fourth)>(_arr, 9, 12); sum += i; } cout << sum << endl; /*cout << first << endl; cout << second << endl; cout << third << endl; cout << fourth << endl; */ } Test With DMD $ dmd app.d -O $ time ./app 49999995000000 real 0m0.290s user 0m0.282s sys 0m0.003s With LDC $ ldc2 app.d -O $ time ./app 49999995000000 real 0m0.004s user 0m0.001s sys 0m0.002s And then the C++ $ g++ app.cpp -O3 -o app_cpp $ time ./app_cpp 49999995000000 real 0m0.004s user 0m0.001s sys 0m0.002s I am still convinced that D is awesome. Happy coding!
Mar 30
next sibling parent Jon Degenhardt <jond noreply.com> writes:
On Thursday, 30 March 2017 at 11:03:03 UTC, Ervin Bosenbacher 
wrote:
 Tried again, threw in summing up a number 10 million times and 
 repeat the arrays 10 million times, I have used arrays on the 
 stack for the D version. And when I am talking about 
 performance I am curious about CPU bound stuff.

 [...benchmarks snipped...]

 I am still convinced that D is awesome.
Nice! You might also find these benchmarks I did recently interesting: https://github.com/eBay/tsv-utils-dlang/blob/master/docs/Performance.md --Jon
Mar 30
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 3/30/17 1:03 PM, Ervin Bosenbacher wrote:
 On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:
 Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:
 That is the same, that came as a shock to me.
most compilers (for many languages) can optimize your super-trivial example down to nothing - for at least the last 10 years or more so whats the point? you're talkin about "performance is critical for me" but missing even minor knowledge about todays compiler powers? for a benchmark you need: -loops, running millions of times, preventing IO and do now fall into the completely-optimized-to-nothing-trap etc.
Tried again, threw in summing up a number 10 million times and repeat the arrays 10 million times, I have used arrays on the stack for the D version. And when I am talking about performance I am curious about CPU bound stuff. The D version: import std.stdio; void main() { long sum = 0; foreach (long i; 0 .. 10000000) { int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 ]; int[3] first = months[0 .. 3]; int[3] second = months[3 .. 6]; int[3] third = months[6 .. 9]; int[3] fourth = months[9 .. 12];
Most of this code may be easily eliminated by dead-code removal. So you probably just measure the summing loop alone. To be certain look at disassembly. --- Dmitry Olshansky
Mar 30
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Thursday, 30 March 2017 at 11:03:03 UTC, Ervin Bosenbacher 
wrote:
 I am still convinced that D is awesome.
As usual, use gdc or ldc for best results, dmd's backend misses lots of optimizations.
Apr 01
prev sibling parent reply Ervin Bosenbacher <ervin.bosenbacher gmail.com> writes:
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:
 Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:
 That is the same, that came as a shock to me.
most compilers (for many languages) can optimize your super-trivial example down to nothing - for at least the last 10 years or more so whats the point? you're talkin about "performance is critical for me" but missing even minor knowledge about todays compiler powers? for a benchmark you need: -loops, running millions of times, preventing IO and do now fall into the completely-optimized-to-nothing-trap etc.
I understand what you are saying, it wasn't a thorough all encompassing analysis just wanted a quick POC and convince myself whether D lang is sufficient enough for my case. I have already accepted the fact that if I want to optimize my Python code in certain situations, not all because you can use better algos, data structures, etc then I have to drop down to C++ or C using say pybind11. Instead of that D. And then if I am not happy with something I can drop to C or C++ anyway because its ABI compatible with C and with limitations with C++, right? After I have accepted the fact that I have to use various tools to solve various problems its not much of an issue. But with D i have to less code which is always better. Less code, less complexity, less bugs... etc I am not going to go down this vortex. :) Yes I have much less knowledge of compilers probably than you do but I am happy with these results. On another note my first choice was rust, and I have tried and tried, rejecting it multiple times. I am happy with D.
Mar 30
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Mar 30, 2017 at 11:15:10AM +0000, Ervin Bosenbacher via Digitalmars-d
wrote:
[...]
 I am happy with D.
Welcome aboard! T -- The richest man is not he who has the most, but he who needs the least.
Mar 30
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote:

 I have already accepted the fact that if
 I want to optimize my Python code in certain situations, not all because
 you can use better algos, data structures, etc then I have to drop down
 to C++ or C using say pybind11. Instead of that D.
You can integrate D and Python with pyd. http://code.dlang.org/packages/pyd --Ryan
Mar 30
parent reply Ervin Bosenbacher <ervin.bosenbacher gmail.com> writes:
On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:
 On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote:

 I have already accepted the fact that if
 I want to optimize my Python code in certain situations, not 
 all because
 you can use better algos, data structures, etc then I have to 
 drop down
 to C++ or C using say pybind11. Instead of that D.
You can integrate D and Python with pyd. http://code.dlang.org/packages/pyd --Ryan
Brilliant, thank you. Will help to leverage my python code. Also I might be able to convince others around me to use D instead of C extending Python.
Mar 30
parent reply bachmeier <no spam.net> writes:
On Thursday, 30 March 2017 at 12:27:33 UTC, Ervin Bosenbacher 
wrote:
 On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:
 On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote:

 I have already accepted the fact that if
 I want to optimize my Python code in certain situations, not 
 all because
 you can use better algos, data structures, etc then I have to 
 drop down
 to C++ or C using say pybind11. Instead of that D.
You can integrate D and Python with pyd. http://code.dlang.org/packages/pyd --Ryan
Brilliant, thank you. Will help to leverage my python code. Also I might be able to convince others around me to use D instead of C extending Python.
Would be nice for you to blog your learning too (nothing fancy, just a quick report from time to time) because many others are in your current situation.
Mar 30
parent Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Thursday, 30 March 2017 at 13:59:45 UTC, bachmeier wrote:
 On Thursday, 30 March 2017 at 12:27:33 UTC, Ervin Bosenbacher 
 wrote:
 On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:
 On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote:

 [...]
You can integrate D and Python with pyd. http://code.dlang.org/packages/pyd --Ryan
Brilliant, thank you. Will help to leverage my python code. Also I might be able to convince others around me to use D instead of C extending Python.
Would be nice for you to blog your learning too (nothing fancy, just a quick report from time to time) because many others are in your current situation.
I went back to C++ cause integration with existing packages was a pain and a implicit gc
Mar 30
prev sibling next sibling parent Shachar Shemesh <shachar weka.io> writes:
On 30/03/17 09:58, Ervin Bosenbacher wrote:
 Performance test:
 rvinMacBookProLimegg:source ervinbosenbacher$ time ./app
 [31, 28, 31]
 [30, 31, 30]
 [31, 31, 30]
 [31, 30, 31]

 real    0m0.004s
 user    0m0.001s
 sys    0m0.001s

 ErvinMacBookProLimegg:source ervinbosenbacher$ time ./a.out
 [31, 28, 31]
 [30, 31, 30]
 [31, 31, 30]
 [31, 30, 31]

 real    0m0.004s
 user    0m0.001s
 sys    0m0.002s

 That is the same, that came as a shock to me.

 Happy coding al!
I just finished implementing RAID parity calculations. I don't remember the precise numbers, but I saved a non-insignificant amount of run time (order of 10-20%) by casting from ranges to pointers before running the XORs. Be sure to benchmark. Shachar
Mar 30
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 03/29/2017 11:58 PM, Ervin Bosenbacher wrote:

 From the  Programming in D book i  typed in the below code
In case it's useful to someone, the source code is available in zipped format as well (search for ".zip" on the index page): http://ddili.org/ders/d.en/index.html Ali
Mar 31