digitalmars.D - The nail in the coffin of C++ or why don't GO there...
- Ervin Bosenbacher (90/90) Mar 29 2017 Just would like to share something. For months I couldn't decide
- XavierAP (7/9) Mar 30 2017 I believe for this slicing D might be even faster for a larger
- dennis luehring (8/9) Mar 30 2017 most compilers (for many languages) can optimize your super-trivial
- Ervin Bosenbacher (9/20) Mar 30 2017 yes it was a quick hack. I try it again. Optimizations were
- Ervin Bosenbacher (90/101) Mar 30 2017 Tried again, threw in summing up a number 10 million times and
- Jon Degenhardt (6/12) Mar 30 2017 Nice! You might also find these benchmarks I did recently
- Dmitry Olshansky (6/35) Mar 30 2017 Most of this code may be easily eliminated by dead-code removal. So you
- Martin Nowak (4/5) Apr 01 2017 As usual, use gdc or ldc for best results, dmd's backend misses
- Ervin Bosenbacher (18/29) Mar 30 2017 I understand what you are saying, it wasn't a thorough all
- H. S. Teoh via Digitalmars-d (6/7) Mar 30 2017 Welcome aboard!
- rjframe (4/8) Mar 30 2017 You can integrate D and Python with pyd.
- Ervin Bosenbacher (4/14) Mar 30 2017 Brilliant, thank you. Will help to leverage my python code. Also
- bachmeier (5/23) Mar 30 2017 Would be nice for you to blog your learning too (nothing fancy,
- Swoorup Joshi (3/22) Mar 30 2017 I went back to C++ cause integration with existing packages was a
- Shachar Shemesh (7/26) Mar 30 2017 I just finished implementing RAID parity calculations. I don't remember
- =?UTF-8?Q?Ali_=c3=87ehreli?= (5/6) Mar 31 2017 In case it's useful to someone, the source code is available in zipped
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 2017
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 2017
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 2017
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher: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!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 2017
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher: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!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 2017
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 2017
On 3/30/17 1:03 PM, Ervin Bosenbacher wrote:On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote: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 OlshanskyAm 30.03.2017 um 08:58 schrieb Ervin Bosenbacher: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];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 2017
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 2017
On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher: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.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 2017
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 2017
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 2017
On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote: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.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 2017
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: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.On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote: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.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 2017
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:I went back to C++ cause integration with existing packages was a pain and a implicit gcOn Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote: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.On Thu, 30 Mar 2017 11:15:10 +0000, Ervin Bosenbacher wrote: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.[...]You can integrate D and Python with pyd. http://code.dlang.org/packages/pyd --Ryan
Mar 30 2017
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 2017
On 03/29/2017 11:58 PM, Ervin Bosenbacher wrote:From the Programming in D book i typed in the below codeIn 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 2017