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!

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!

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.

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!

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!

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.

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.

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

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.

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