On Monday, 7 September 2015 at 08:33:33 UTC, Dmitry Olshansky wrote:
> On 07-Sep-2015 11:29, qznc wrote:
>> Maybe std.regex has just space for optimization?
>
> Sure thing, see WIP here (~25% faster but not yet complete):
> https://github.com/D-Programming-Language/phobos/pull/3314

It's been over a year since the last commit on that. Any updates?

On Tuesday, 8 September 2015 at 23:20:05 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 8 September 2015 at 21:11:15 UTC, qznc wrote:
>> Yes. I'm not sure how to structure this whole suite. The general goal is "D claims that it can match C/C++ in performance, let's have some actual numbers". So far D mostly disappoints in terms of performance.
>
> The most interesting thing to test is how they fare with high level optimization, not low level optimization. So make sure the implementation is similar...

I'm not sure if I understand you correctly. What is "high level" and "low level" optimization?

What I want to know is a) how fast is "idiomatic" D code (using ranges etc) compared to "idiomatic" C/C++ and b) how do they compare if you push performance to the limits (code beauty be damned).

For a) you want a similar implementation although C/C++ will most certainly always loose in terms of length and convenience.

For b) we don't care. C/C++ is free to use builtins, pragmas, and whatnot. If for loops are faster than ranges in D, then we will use for loops here.

On Wednesday, 9 September 2015 at 07:59:48 UTC, qznc wrote:
> I'm not sure if I understand you correctly. What is "high level" and "low level" optimization?

Low level are local optimizations, which basically will be the same if you use the same backend (like LLVM). It would just measure the programmer's approach and not the compiler.

> What I want to know is a) how fast is "idiomatic" D code (using ranges etc) compared to "idiomatic" C/C++ and b) how do they compare if you push performance to the limits (code beauty be damned).
>
> For a) you want a similar implementation although C/C++ will most certainly always loose in terms of length and convenience.
>
> For b) we don't care. C/C++ is free to use builtins, pragmas, and whatnot. If for loops are faster than ranges in D, then we will use for loops here.

The problem with a) is that in C++ there are many libraries and you'll have a hard time finding comparable alternatives on both sides... People don't stick to the standard libraries in C++.

For b) C++ will be slightly faster because of things like modular arithmetics and OpenMP support.

I think the better approach is to write up the same algorithms in a high level fashion (using generic templates on both sides) from the ground up using the same constructs and measure the ability to optimize.

Otherwise you end up comparing apples and oranges in a rather subjective manner.

On Wednesday, 9 September 2015 at 09:56:10 UTC, Ola Fosheim Grøstad wrote:
> I think the better approach is to write up the same algorithms in a high level fashion (using generic templates on both sides) from the ground up using the same constructs and measure the ability to optimize.

That is a good idea, if you want to measure compiler optimizations. Ideally g++ and gdc should always yield the same performance then?

However, it does answer the wrong question imho.

Suppose you consider using D with C/C++ as the stable alternative. D lures you with its high level features. However, you know that you will have to really optimize some hot spots sooner or later. Will D impose a penalty on you and C/C++ could have provided better performance?

Walter argues that there is no technical reason why D should be slower than C/C++. My experience with the benchmarks says, there seem to be such penalties. For example, there is no __builtin_ia32_cmplepd or __builtin_ia32_movmskpd like gcc has.

On 9 September 2015 at 16:00, qznc via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 9 September 2015 at 09:56:10 UTC, Ola Fosheim Grøstad wrote:
>
>> I think the better approach is to write up the same algorithms in a high level fashion (using generic templates on both sides) from the ground up using the same constructs and measure the ability to optimize.
>>
>
> That is a good idea, if you want to measure compiler optimizations. Ideally g++ and gdc should always yield the same performance then?
>
> However, it does answer the wrong question imho.
>
> Suppose you consider using D with C/C++ as the stable alternative. D lures you with its high level features. However, you know that you will have to really optimize some hot spots sooner or later. Will D impose a penalty on you and C/C++ could have provided better performance?
>
> Walter argues that there is no technical reason why D should be slower than C/C++. My experience with the benchmarks says, there seem to be such penalties. For example, there is no __builtin_ia32_cmplepd or __builtin_ia32_movmskpd like gcc has.
>

import gcc.builtins;  // OK, cheating. :-)

On Wednesday, 9 September 2015 at 14:09:36 UTC, Iain Buclaw wrote:
> import gcc.builtins;  // OK, cheating. :-)

Thanks, I did not know this. :)

I would not consider it cheating. Using builtins in C is not portable C11 either. It also shows off how D does versions.

On Wednesday, 9 September 2015 at 14:00:07 UTC, qznc wrote:
> That is a good idea, if you want to measure compiler optimizations. Ideally g++ and gdc should always yield the same performance then?

Hopefully, as I understand GCC uses a highlevel IR, but if performance is equal that is a pretty strong argument to get people to adopt, if the rest of the language is polished.

And you could measure regressions.

> Suppose you consider using D with C/C++ as the stable alternative. D lures you with its high level features. However, you know that you will have to really optimize some hot spots sooner or later. Will D impose a penalty on you and C/C++ could have provided better performance?
>
> Walter argues that there is no technical reason why D should be slower than C/C++. My experience with the benchmarks says, there seem to be such penalties. For example, there is no __builtin_ia32_cmplepd or __builtin_ia32_movmskpd like gcc has.

Ok, I see your point. You want to measure maximum throughput for critical applications that might benefit from language specific intrinsics.

Multithreaded applications could probably show some differences too, due to TLS/shared...

Maybe some kind of actor based benchmark. Essentially running thousands of fibers with lots of intercommunication.

On Tuesday, 8 September 2015 at 21:06:26 UTC, qznc wrote:

> Afaik the Erlang runtime does not interrupt processes.

Depends what you mean by "processes" :-)

> In this comparison it is actually interesting, because D has its own bignum implementation in the standard library.

There you go!



On Tuesday, 8 September 2015 at 21:11:15 UTC, qznc wrote:

> The general goal is "D claims that it can match C/C++ in performance, let's have some actual numbers".

- You're only dealing with 3 programming languages, although more than 3 language implementations

- Those programming languages are intended to be used for similar tasks.

- You'll correctly be seen as a D language advocate, so your presentation needs to show that you accept advice on how to improve the C and C++ programs.

- "short idiomatic programs" is difficult because the tradeoff between performance and "idiomatic" is so subjective, and you will correctly be seen as a D language advocate :-)

   When asked, one of the C++ program contributors to the benchmarks game did try to write some "shorter" C++ programs, see:

   http://benchmarksgame.alioth.debian.org/u64/code-used-time-used-shapes.php#shortest

On Tue, 2015-09-08 at 21:11 +0000, qznc via Digitalmars-d wrote:
> 
[…]
> Yes. I'm not sure how to structure this whole suite. The general goal is "D claims that it can match C/C++ in performance, let's have some actual numbers". So far D mostly disappoints in terms of performance.
> 
> […]

Which D compilers are you testing with?

I have found DMD to be OK but often a bit slow compared to C++ codes
using GCC and Clang. However, LDC and GDC generally create executables
from D codes that are at least as fast as C++ with GCC and Clang.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 9 September 2015 at 16:58:41 UTC, Russel Winder wrote:
> On Tue, 2015-09-08 at 21:11 +0000, qznc via Digitalmars-d wrote:
>> 
> […]
>> Yes. I'm not sure how to structure this whole suite. The general goal is "D claims that it can match C/C++ in performance, let's have some actual numbers". So far D mostly disappoints in terms of performance.
>> 
>> […]
>
> Which D compilers are you testing with?

The benchmark records all versions: https://qznc.github.io/d-shootout/

> I have found DMD to be OK but often a bit slow compared to C++ codes
> using GCC and Clang. However, LDC and GDC generally create executables
> from D codes that are at least as fast as C++ with GCC and Clang.

Yes, that is the general opinion. However, I have a hard time to reach the obscenely tuned C++ programs.