Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 30, 2017 The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
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! |
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ervin Bosenbacher | 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!
|
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ervin Bosenbacher | 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. |
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | 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!
|
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | 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! |
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | 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.
|
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ervin Bosenbacher | 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. |
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ervin Bosenbacher | 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 |
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to rjframe | 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.
|
March 30, 2017 Re: The nail in the coffin of C++ or why don't GO there... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ervin Bosenbacher | 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
|
Copyright © 1999-2021 by the D Language Foundation