<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 September 2015 at 16:00, qznc via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday, 9 September 2015 at 09:56:10 UTC, Ola Fosheim Grøstad wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
That is a good idea, if you want to measure compiler optimizations. Ideally g++ and gdc should always yield the same performance then?<br>
<br>
However, it does answer the wrong question imho.<br>
<br>
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?<br>
<br>
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.<br>
</blockquote></div><br></div><div class="gmail_extra">import gcc.builtins;  // OK, cheating. :-)<br></div></div>