Optimizations and performance

poliklosio via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 9 00:26:16 PDT 2016


On Thursday, 9 June 2016 at 07:02:26 UTC, default0 wrote:
> On Thursday, 9 June 2016 at 06:51:53 UTC, poliklosio wrote:
>> On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote:
>>> On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad
>>>> I wouldn't put too much emphasis on that benchmark as the 
>>>> implementations appear different? Note that Felix compiles 
>>>> to C++, yet beats C++ in the same test? Yes, Felix claims to 
>>>> do some high level optimizations, but doesn't that just tell 
>>>> us that the C++ code tested wasn't optimal?
>>>
>>> Languages should be fast by default. I always find it missing 
>>> the point when people go crazy during these benchmarking 
>>> tests trying to make the code as fast as possible by tweaking 
>>> both the code and the compiler flags. Go through that effort 
>>> with a 2 million line app. Tell me how long that takes.
>>
>> YES +1000
>
> I agree with the sentiment, but you often do want to spend time 
> finding hot paths in your app and optimizing those. In a 2 
> million line app, there will not be 2 million lines of code in 
> the hot path. So figuring out how many tricks you can do to get 
> something going fast does have quite a bit of value, even for 
> large apps.

First of all, there is not much point optimizing the language for 
people who are capable of optimizing everything to the extreme 
themselves. D already has as much power as C/C++ for them.
Second, yes, anyone should excercise some basic optimization 
attempts before calling a language slow. Yet, not everyone will 
come up with the same ways to optimize and some people will 
invariably fail. Moreover, the same person may fail, depending on 
what he was writing the week before and how much coffee he had. 
But even assuming that you optimize some hot paths, there are 
going to be the rest of the code that is slow if the language 
leads you to slow solutions by default.

More importantly, the slow software is usually a product of 
write-it-ASAP mentallity, and of people who are *not* good 
programmers. Optimizing their products automatically means that 
80% of software that you use everyday (photoshop plugins, office 
programs, mobile apps) is going to either run much faster or get 
released to the marked sooner, which is a big selling point for 
the language.



More information about the Digitalmars-d mailing list