www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Optimizations and performance

reply Bauss <jj_1337 live.dk> writes:
D definitely needs some optimizations, I mean look at its 
benchmarks compared to other languages: 
https://github.com/kostya/benchmarks

I believe the first step towards better performance would be 
identifying the specific areas that are slow.

I definitely believe D could do much better than what's shown.

Let's find D's performance weaknesses and crack them down.
Jun 08 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


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?
Jun 08 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


 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?


While I appreciate that someone puts the time and effort in such 
benchmarks, what do they really say?
In the brainfuck example the most expensive function call is the 
hash function, which is not needed at all!
We can just allocate an array on demand and we beat the Cpp 
implemention by the factor of 2! (and use less memory).

https://github.com/kostya/benchmarks/pull/87
(n.b. that this small change makes D by far the fastest for this 
benchmark)

So what do we learn?

1) Don't trust benchmarks!
2) D's dictionary hashing should be improved
Jun 08 2016
next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 9.6.2016 v 02:25 Seb via Digitalmars-d napsal(a):

 While I appreciate that someone puts the time and effort in such 
 benchmarks, what do they really say?
 In the brainfuck example the most expensive function call is the hash 
 function, which is not needed at all!


It is more about AA performance. I was able to write my own AA 
implementation which beats nim. Hash function was only one part of 
problem :).
Jun 08 2016
prev sibling parent reply Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 00:25:28 UTC, Seb wrote:

 On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad 
 wrote:

 On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


 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?


 While I appreciate that someone puts the time and effort in 
 such benchmarks, what do they really say?
 In the brainfuck example the most expensive function call is 
 the hash function, which is not needed at all!
 We can just allocate an array on demand and we beat the Cpp 
 implemention by the factor of 2! (and use less memory).

 https://github.com/kostya/benchmarks/pull/87
 (n.b. that this small change makes D by far the fastest for 
 this benchmark)

 So what do we learn?

 1) Don't trust benchmarks!
 2) D's dictionary hashing should be improved


I think you can trust benchmark. I think the bigger key is 
understanding what you are truly benchmarking. Most of the time 
it's actually just the compilers more than the language. From 
what I see it's very difficult to actually 'benchmark' a 
language. Especially when you shy away from the ways the language 
was designed to be used.

A good example I see almost all of the time is declaring classes 
in most languages. Which generally involves the class itself 
being created to be inherited and to utilize polymorphism. But 
the first thing you see people doing in benchmarking tests is 
slap 'final' or 'sealed' onto the class to eliminate the overhead 
in setting up a traditional OOP class, to get that extra 
performance. But that is not how the language is generally used...

And at that point if your implementation performs slower than 
whatever you are benchmarking against (lets say for the sake of 

well...it's most likely not one language being better than the 
other, because they both accomplish the same thing the same way, 
so it's most likely some other feature, or more likely, some 
detail of the compiler or IL language they are using. When the 
clear blemish of the language is showing in both cases, classes 
should be 'final' or 'sealed' unless explicitly stated otherwise. 
So both languages are slower here. And the implementations with 
their workaround is really comparing something else.

Benchmarking is important, but it takes nuance and thought to 
actually find what you benchmarked. For instance the vast 
majority of benchmarking cases I see have nothing to do with the 
language, but more so how a library call was implemented.
Jun 09 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 9 June 2016 at 13:32:14 UTC, Dave wrote:

 I think you can trust benchmark. I think the bigger key is 
 understanding what you are truly benchmarking.


I agree with your general point, but what I find most useful 
about benchmarks is the ability to find the lower bound of 
performance without resorting to inline asm or making the program 
ugly as sin.

If you can find, "In this particular task, D has these tricks it 
can use to make it really fast", I think that's useful as many 
other languages won't have those options. You can see how much 
you as a programmer can optimize the hot points in your code and 
how easy that is to do just by looking at the benchmarked code.

Appender!string is a great example, as it's easy to add and it 
almost always results in measurable speed increases. You can see 
how one simple change using D features can make your program 5% 
faster.

Every language has idiomatic uses to speed up your program, the 
real question is how much faster those make the code and how easy 
it is to implement those in your own code.
Jun 09 2016
next sibling parent Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote:

 On Thursday, 9 June 2016 at 13:32:14 UTC, Dave wrote:

 [...]


 I agree with your general point, but what I find most useful 
 about benchmarks is the ability to find the lower bound of 
 performance without resorting to inline asm or making the 
 program ugly as sin.

 If you can find, "In this particular task, D has these tricks 
 it can use to make it really fast", I think that's useful as 
 many other languages won't have those options. You can see how 
 much you as a programmer can optimize the hot points in your 
 code and how easy that is to do just by looking at the 
 benchmarked code.

 Appender!string is a great example, as it's easy to add and it 
 almost always results in measurable speed increases. You can 
 see how one simple change using D features can make your 
 program 5% faster.

 Every language has idiomatic uses to speed up your program, the 
 real question is how much faster those make the code and how 
 easy it is to implement those in your own code.


Based off what you said, I'm not sure we disagree at all. :)
My main point is no what you are really benchmarking. And just 
because you can make it go away doesn't mean it's not a problem 
still. Especially if it's the way you are supposed to use the 
language.
Jun 09 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote:

 Appender!string is a great example, as it's easy to add and it 
 almost always results in measurable speed increases. You can 
 see how one simple change using D features can make your 
 program 5% faster.

 Every language has idiomatic uses to speed up your program, the 
 real question is how much faster those make the code and how 
 easy it is to implement those in your own code.


I don't think you should benchmark library constructs like 
Appender. That's essentially pointless. I have highly optimized 
libraries for specific purposes, like ring buffers that are 
particularly efficient with specific access patterns.

Benchmark the naked language. If D provides concatenation, 
benchmark concatenation and how the optimizer turns them (or 
don't) into something more efficient.

Otherwise people would benchmark numpy instead of Python etc.
Jun 09 2016
next sibling parent reply Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote:

 Appender!string is a great example, as it's easy to add and it 
 almost always results in measurable speed increases. You can 
 see how one simple change using D features can make your 
 program 5% faster.

 Every language has idiomatic uses to speed up your program, 
 the real question is how much faster those make the code and 
 how easy it is to implement those in your own code.


 I don't think you should benchmark library constructs like 
 Appender. That's essentially pointless.


Why? Maybe not John Doe's library, but certainly the standard 
library should be included in benchmarks as that is supposed to 
be highly reflective of the language...


 Benchmark the naked language. If D provides concatenation, 
 benchmark concatenation and how the optimizer turns them (or 
 don't) into something more efficient.


I don't even see how that's useful. It will help you make a 
better compiler. But not give to much information about the 
language. For instance if you benchmark a while loop in C, C++, 
Rust, and D all with LLVM backends...well the slower language 
really is just pointing towards some ineffectiveness of the 
compiler itself, as in a simple example, there really shouldn't 
be much difference. However, if you want to say "D has this 
feature which produces better performance than what those 
language can provide", that's a different story.


 Otherwise people would benchmark numpy instead of Python etc.
Jun 09 2016
next sibling parent Dave <david.dave dave.com> writes:
All of this goes back to knowing what you are truly benchmarking.
Jun 09 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 15:57:02 UTC, Dave wrote:

 But not give to much information about the language.


All ordinary imperative languages are equal in theoretical 
performance. No point in trying to "benchmark" languages. You 
always benchmark compiler (and runtime) + hardware.


 For instance if you benchmark a while loop in C, C++, Rust, and 
 D all with LLVM backends...well the slower language really is 
 just pointing towards some ineffectiveness of the compiler 
 itself, as in a simple example, there really shouldn't be much 
 difference. However, if you want to say "D has this feature 
 which produces better performance than what those language can 
 provide", that's a different story.


Well, it doesn't and cannot have a feature that inherently is 
performant. It is the compiler's ability to detect opportunities 
for making things simpler or fit the hardware better that matters.

The backend matters, but usually you can do high level 
optimization before you reach that stage. That's why you want to 
benchmark language constructs. To see how well it does high level 
optimization, not only the easier low level optimization.
Jun 09 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad 
wrote:

 Otherwise people would benchmark numpy instead of Python etc.


While it's not a one-to-one analogy due to the fact that Appender 
is in Phobos, I think it would be totally reasonable to benchmark 
numpy instead of Python.

What's the first answer on any SO question about slow python 
code? Usually it's "use numpy". Most of the time, changing to 
numpy takes five minutes and can have a huge impact on your code 
speed with no decrease in readability. This is VERY indicative of 
normal Python use, and therefore it's useful to know that Python 
code can get to a certain speed with idiomatic use, which is what 
programmers should actually care about.

"How fast can my code get" rather than "How fast can my code get 
using this specific subset of the language and libraries".
Jun 09 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 15:58:05 UTC, Jack Stouffer wrote:

 On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad 
 wrote:

 Otherwise people would benchmark numpy instead of Python etc.


 While it's not a one-to-one analogy due to the fact that 
 Appender is in Phobos, I think it would be totally reasonable 
 to benchmark numpy instead of Python.


Well, that makes all benchmarks pointless. C++ would win every 
single one, because you are then benchmarking everything C 
provides, plus everything C++ performance libraries provides, 
plus OpenMP.

C++ would destroy the competition on almost any performance 
benchmark implemented by a group of competent C++ programmers.
Jun 09 2016
next sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad 
wrote:

 C++ would destroy the competition on almost any performance 
 benchmark implemented by a group of competent C++ programmers.


How can it win over assembler? Also what's about cost/benefit 
ratio?
Jun 09 2016
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 9 June 2016 at 17:19:36 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad 
 wrote:

 C++ would destroy the competition on almost any performance 
 benchmark implemented by a group of competent C++ programmers.


 How can it win over assembler? Also what's about cost/benefit 
 ratio?


  I wrote an assembler (which can compile itself) when i was a 
teenager some 20 years ago. The code is probably ugly, a bit 
confusing, and has limited functionality or use as it doesn't 
connect or link to any official tools.

  Writing in assembly can give you some blazing fast code, and do 
things with hardware that requires... well very badly written 
code to get similar effects. (overflow detection, carrying, 
larger type emulation, etc). But it's way too tedious, like using 
tweezers to build a car by putting each individual grain of metal 
in place and welding it in place, your view is so narrow you can 
easily miss the bigger picture.

  Two years writing in assembly was fun, but i certainly wouldn't 
want to do it regularly, especially with anything that needs any 
type of maintenance down the road. (talking big projects, tiny 
ones for PIC chips or specific sections of code are different).
Jun 09 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 17:19:36 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad 
 wrote:

 C++ would destroy the competition on almost any performance 
 benchmark implemented by a group of competent C++ programmers.


 How can it win over assembler?


By language you usually mean a portable language, not machine 
language. Machine language benchmark the hardware, not the 
compiler.

But even then, domain experts are more likely to write higher 
performance code than non-domain experts, so machine language 
isn't sufficient. Therefore a large library-oriented benchmarking 
suite will favour the older language with more high performance 
libraries. Like Fortran and C/C++.


 Also what's about cost/benefit ratio?


How do you benchmark cost/benefit?
Jun 09 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 10 June 2016 at 01:54:21 UTC, Ola Fosheim Grøstad 
wrote:

 By language you usually mean a portable language, not machine 
 language.


I believe there are more platforms that have an assembler, but 
not a C++ compiler and C++ libraries you want to use.


 Machine language benchmark the hardware, not the compiler.


It only means assembler reaches the theoretical limit of 
performance by choosing right language abstractions, that you 
wanted to benchmark.


 But even then, domain experts are more likely to write higher 
 performance code than non-domain experts, so machine language 
 isn't sufficient.


Some domain experts don't know (or don't want) any programming 
language and use matlab instead.


 Also what's about cost/benefit ratio?


 How do you benchmark cost/benefit?


By eyeballing the source.
Jun 10 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 10 June 2016 at 14:25:25 UTC, Kagamin wrote:

 On Friday, 10 June 2016 at 01:54:21 UTC, Ola Fosheim Grøstad 
 wrote:

 By language you usually mean a portable language, not machine 
 language.


 I believe there are more platforms that have an assembler, but 
 not a C++ compiler and C++ libraries you want to use.


Huh? All platforms have an assembler.

You mean inline assembly? That's not really relevant.



 Machine language benchmark the hardware, not the compiler.


 It only means assembler reaches the theoretical limit of 
 performance by choosing right language abstractions, that you 
 wanted to benchmark.


What language abstractions? There are no abstractions in machine 
language.



 Also what's about cost/benefit ratio?


 How do you benchmark cost/benefit?


 By eyeballing the source.


Not objectively measurable in a meaningful way.
Jun 10 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad 
wrote:

 C++ would destroy the competition on almost any performance 
 benchmark implemented by a group of competent C++ programmers.


Ok, so it will win, as it should then. And then people can look 
at the C++ code and say to themselves "Is this something that I 
am capable of or want to write", the answer being most of the 
time, no.
Jun 09 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 18:09:44 UTC, Jack Stouffer wrote:

 And then people can look at the C++ code and say to themselves 
 "Is this something that I am capable of or want to write", the 
 answer being most of the time, no.


Sure, it is largely and increasingly becoming an experts 
language... :-/ More so today, than in the 90s IMO.
Jun 09 2016
prev sibling parent reply Dave <david.dave dave.com> writes:
On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


 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.

In short, the truer metric is how fast does the code run casually 
writing code. Good languages will run fast without having to 
think super detailed about it. Now it is also useful to know how 
fast the language can get when someone dives into the details. 
Don't get me wrong. I just think the casual case is far more 
important.

I've also noticed that during these benchmark wars people tend to 
compare compilers more than languages anyhow. And they tout their 
ability to tweak the compiler and write (at times very esoteric 
code for the sake of performance) as a win for their language. 
That's also missing the point.
Jun 08 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote:

 In short, the truer metric is how fast does the code run 
 casually writing code. Good languages will run fast without 
 having to think super detailed about it. Now it is also useful 
 to know how fast the language can get when someone dives into 
 the details. Don't get me wrong. I just think the casual case 
 is far more important.


Not sure about that, as inner loops where you want to put in the 
most effort often are the bottle neck. But the code should be 
similar and the benchmarks should tests different types of 
optimizations:

- recursion
- loop-unrolling, converting to simd
- compile time evaluation
- converting heap allocations to stack allocations
- heap fragmentation

And so on.


 And they tout their ability to tweak the compiler and write (at 
 times very esoteric code for the sake of performance) as a win 
 for their language. That's also missing the point.


Yes, that is very bad for floating point. Fast can mean 
completely wrong results in the general case (even though it may 
look correct for the benchmark input). The higher probability for 
wrong results, the faster it goes...

Benchmarks for floating point should also test accuracy.
Jun 08 2016
prev sibling next sibling parent reply poliklosio <poliklosio happypizza.com> writes:
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
Jun 08 2016
parent reply default0 <Kevin.Labschek gmx.de> writes:
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.
Jun 09 2016
parent reply poliklosio <poliklosio happypizza.com> writes:
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.
Jun 09 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote:

 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.


No... not if you are talking about specific compilers.
Jun 09 2016
parent reply poliklosio <poliklosio happypizza.com> writes:
On Thursday, 9 June 2016 at 10:00:17 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote:

 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.


 No... not if you are talking about specific compilers.


Get the logic right. The correct statement is:
"Yes... not if you are talking about specific compilers."
Jun 09 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 18:45:48 UTC, poliklosio wrote:

 On Thursday, 9 June 2016 at 10:00:17 UTC, Ola Fosheim Grøstad 
 wrote:

 On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote:

 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.


 No... not if you are talking about specific compilers.


 Get the logic right. The correct statement is:
 "Yes... not if you are talking about specific compilers."


«D already has as much power as C/C++ for them.»

No (D does not already has as much power as C/C++ for them.)... 
not if you are talking about specific (C/C++) compilers.

Please don't twist my words. :-)
Jun 10 2016
parent poliklosio <poliklosio happypizza.com> writes:
On Friday, 10 June 2016 at 08:32:28 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 9 June 2016 at 18:45:48 UTC, poliklosio wrote:

 On Thursday, 9 June 2016 at 10:00:17 UTC, Ola Fosheim Grøstad 
 wrote:

 On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote:

 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.


 No... not if you are talking about specific compilers.


 Get the logic right. The correct statement is:
 "Yes... not if you are talking about specific compilers."


 «D already has as much power as C/C++ for them.»

 No (D does not already has as much power as C/C++ for them.)... 
 not if you are talking about specific (C/C++) compilers.

 Please don't twist my words. :-)


I was thinking that you compared D compilers (dmd vs ldc). If you 
count things like Intel compiler for C/C++, then yes, C++ 
provides more speed.
If that is what you meant, yes, I'm sorry I twisted your words.

But then this becomes a purely academic discussion because only 
financially secure companies in rich countries are going to use 
something as expensive as Intel compiler, and only for some very 
important high-performance projects. Once you talk about spending 
thousands of dollars on a piece of software that can be replaced 
with a free alternative, there are million other ways to spend 
the money **better**, for example hiring more people or better 
people, or paying for longer development, or paying for porting 
algorithms to GPUs or buying better CPUs (if software is to be 
run in house). So then your point has no relevance to optimizing 
the default D performance. It only would if you had to pay 
thousands of $ for using D tools.

If you didn't have Intel compiler in mind, then correct me again 
as I don't have a crystal ball and cannot know what specific 
thing you mean.
Jun 18 2016
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote:

 Languages should be fast by default.


This.  4,000,000,000% this.

If the naïve cases are bad, they're bad and trying to pretend 
that doesn't matter is some insidious denial.  Sure, nearly any 
code can be optimised to be some sort of "fast", but 99% of it 
never will be.

-Wyatt
Jun 09 2016
parent reply Kagamin <spam here.lot> writes:
On Thursday, 9 June 2016 at 12:16:25 UTC, Wyatt wrote:

 On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote:

 Languages should be fast by default.


 This.  4,000,000,000% this.

 If the naïve cases are bad, they're bad and trying to pretend 
 that doesn't matter is some insidious denial.  Sure, nearly any 
 code can be optimised to be some sort of "fast", but 99% of it 
 never will be.


Performance is not the only thing to worry in a language.
Jun 09 2016
parent reply Dave <dave dave.com> writes:
On Thursday, 9 June 2016 at 13:48:36 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 12:16:25 UTC, Wyatt wrote:

 On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote:

 Languages should be fast by default.


 This.  4,000,000,000% this.

 If the naïve cases are bad, they're bad and trying to pretend 
 that doesn't matter is some insidious denial.  Sure, nearly 
 any code can be optimised to be some sort of "fast", but 99% 
 of it never will be.


 Performance is not the only thing to worry in a language.


But it is the point of benchmarking
Jun 09 2016
parent reply Kagamin <spam here.lot> writes:
On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote:

 But it is the point of benchmarking


So it's not "languages should be fast by default", but 
"benchmarks should be fast by default"?
Jun 09 2016
next sibling parent Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote:

 But it is the point of benchmarking


 So it's not "languages should be fast by default", but 
 "benchmarks should be fast by default"?


No. It's languages should be fast by default if you care about 
your language's performance. Benchmarks should be done on the 
more common cases to actually see how your language design 
decisions perform under scrutiny. Otherwise, why not use D's 
inline assembler and you'll probably crush all others. The reason 
is...because that's not what you should be measuring. Nor should 
it be tweaks you make to the common case.

Now I do think it is useful to ask yourself "Ok, can we at least 
get there with the language?", and make the tweaks. But you 
should never forget the case of where your language performed 
using the common case. Unfortunately, I feel people do the tweaks 
and forget the failures discovered during the common case
Jun 09 2016
prev sibling next sibling parent Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote:

 But it is the point of benchmarking


 So it's not "languages should be fast by default", but 
 "benchmarks should be fast by default"?


Also, the last I checked, one of D's selling points is that it is 
'fast'. So it seems to be at least a design goal of this 
particular language.
Jun 09 2016
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote:

 But it is the point of benchmarking


 So it's not "languages should be fast by default", but 
 "benchmarks should be fast by default"?


Well, _this_ took some weird leaps from what I actually said...

The point is this sort of language benchmark should use normal 
code.  The sort of code that people who've never heard of Haskell 
would write.

If it's a "fast" language, "ordinary-looking" code should be 
fast.  If being fast requires weird circumlocutions that barely 
anyone knows, it doesn't matter if experts consider it best 
practice.

-Wyatt
Jun 09 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote:

 On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote:

 But it is the point of benchmarking


 So it's not "languages should be fast by default", but 
 "benchmarks should be fast by default"?


 Well, _this_ took some weird leaps from what I actually said...

 The point is this sort of language benchmark should use normal 
 code.  The sort of code that people who've never heard of 
 Haskell would write.


Well, the golden rule is to benchmark big applications, not 
synthetic benchmarks as they tend not to reflect real world usage 
(and you end up with compilers special case the bench marks in 
the optimizer). However, that makes comparison of compilers for 
different languages impossible.

Also, with concurrent languages things gets messy. Most people 
would write single-threaded code, but some languages/compilers 
will automatically give you multi-threaded code. Is that fair? 
Yes, if you focus on productivity. No, if you focus on what is 
possible.
Jun 09 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote:

 The point is this sort of language benchmark should use normal 
 code.  The sort of code that people who've never heard of 
 Haskell would write.

 If it's a "fast" language, "ordinary-looking" code should be 
 fast.  If being fast requires weird circumlocutions that barely 
 anyone knows, it doesn't matter if experts consider it best 
 practice.


A language optimized for performance of spontaneous code written 
by newbies, who never learned the language and don't use best 
practices?
Jun 09 2016
next sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote:

 A language optimized for performance of spontaneous code 
 written by newbies, who never learned the language and don't 
 use best practices?


Could you stop pretending to completely misunderstand the point?

-Wyatt
Jun 09 2016
parent Dave <david.dave dave.com> writes:
On Thursday, 9 June 2016 at 17:36:28 UTC, Wyatt wrote:

 On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote:

 A language optimized for performance of spontaneous code 
 written by newbies, who never learned the language and don't 
 use best practices?


 Could you stop pretending to completely misunderstand the point?

 -Wyatt


Surely there is something between newbie and specialized expert.
Jun 09 2016
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote:

 On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote:

 The point is this sort of language benchmark should use normal 
 code.  The sort of code that people who've never heard of 
 Haskell would write.

 If it's a "fast" language, "ordinary-looking" code should be 
 fast.  If being fast requires weird circumlocutions that 
 barely anyone knows, it doesn't matter if experts consider it 
 best practice.


 A language optimized for performance of spontaneous code 
 written by newbies, who never learned the language and don't 
 use best practices?


Something like

`void main()
{
     // Replace anything that looks like a real
     // number with the rounded equivalent.
     stdin
         .byLine
         .map!(l => l.replaceAll!(c => c.hit.round)
                                 (reFloatingPoint))
         .each!writeln;
}
`
should be as fast as possible. If we have to tell people that 
yes, it is idiomatic D but, if you want speed you should use

for (size_t i = 0 ...) { /*some magic here*/ }

then we are doing something wrong.
Jun 10 2016
parent Kagamin <spam here.lot> writes:
On Friday, 10 June 2016 at 09:31:42 UTC, Chris wrote:

 Something like

 `void main()
 {
     // Replace anything that looks like a real
     // number with the rounded equivalent.
     stdin
         .byLine
         .map!(l => l.replaceAll!(c => c.hit.round)
                                 (reFloatingPoint))
         .each!writeln;
 }
 `


That's a best practice that requires some learning and discipline 
to use. A newbie won't write such code.
Jun 10 2016
prev sibling next sibling parent poliklosio <poliklosio happypizza.com> writes:
On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


Please, ignore the non-actionable advice of those who criticise 
benchmarks. :) Benchmarks are the way to go as there is no better 
way to optimize things.
Also, given enough of them, they really **are** representative of 
the typical runtime of any program because the numbers of bugs in 
different language implementations even out over the whole set of 
benchmarks. This is particularly true if the authors of D code 
are familiar with the D way of doing things, but even if its not 
the case, the language shouldn't punish beginners too much for 
writing the simplest solution that could possibly work for them.

I think a much better benchmark for actually optimizing would 
stress performance of D in a comprehensive set of corner cases 
(hundreds), because then, during the optimizations, if you tweak 
something in D to get increased performance in one case and 
accidentally slow something down in another case, you will notice 
that you slowed somthing else down.
I would start with something like this if I was optimizing D.
Jun 09 2016
prev sibling next sibling parent reply qznc <qznc web.de> writes:
On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


The previous step is to find a good benchmark. This one isn't.

For example, you should clarify what kind of code you want: Short 
idiomatic elegant code? Or rather optimized to max using every 
trick you can no matter the length?

Carefully check what the benchmark actually measures. It should 
not measure IO or pthread context switching for example, because 
that is not really a distinguishing factor between languages.

Also make sure the benchmarks are fair. For example, "threadring" 
in the shootout measures pthread context switching, except 
languages like Erlang and Haskell, which use user-level 
scheduling. This an apples to oranges comparison.

Sometimes the decision is not clear. Do you want a benchmark of 
regular expressions? It makes sense to compare D's and Rust's 
standard library to others, but many (Python, Ruby, etc) will use 
nearly the same C code underneath.

Another aspect is the statistical stuff. At least measure the 
deviations. Better, do some hypothesis tests.
Jun 09 2016
parent Chris <wendlec tcd.ie> writes:
On Thursday, 9 June 2016 at 08:31:37 UTC, qznc wrote:

 On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks

 I believe the first step towards better performance would be 
 identifying the specific areas that are slow.

 I definitely believe D could do much better than what's shown.

 Let's find D's performance weaknesses and crack them down.


 The previous step is to find a good benchmark. This one isn't.

 For example, you should clarify what kind of code you want: 
 Short idiomatic elegant code? Or rather optimized to max using 
 every trick you can no matter the length?

 Carefully check what the benchmark actually measures. It should 
 not measure IO or pthread context switching for example, 
 because that is not really a distinguishing factor between 
 languages.

 Also make sure the benchmarks are fair. For example, 
 "threadring" in the shootout measures pthread context 
 switching, except languages like Erlang and Haskell, which use 
 user-level scheduling. This an apples to oranges comparison.

 Sometimes the decision is not clear. Do you want a benchmark of 
 regular expressions? It makes sense to compare D's and Rust's 
 standard library to others, but many (Python, Ruby, etc) will 
 use nearly the same C code underneath.

 Another aspect is the statistical stuff. At least measure the 
 deviations. Better, do some hypothesis tests.


As this thread [1] shows, a lot depends on the library. Common 
wisdom has it that one should always use library functions, 
because they're already optimized for speed. This is not 
necessarily the case in D (see [1]). So it is a good idea in 
general to compare libraries, say C/C++ standard libs and Phobos. 
First we have to find the suboptimal spots in Phobos, because 
most of the time, people will use library methods like 
`std.algorithm.find`, `countUntil`, `splitter` etc.

Then of course the language/compiler can help with common idioms 
like Ranges. We should check, if using common idioms slows a 
program down, e.g.

- iterating in range style vs. tight for-loops
- for-loops vs. foreach-loops
- how does D's handling of lambdas affect performance?
- [etc.]

These should be as fast as possible, because what's the point of 
having them, if you have to roll your own C-like for-loops to get 
good performance. It's not about how much performance you can 
squeeze out of D in the extremest of extreme cases, it's about 
making the language as fast as possible for normal use cases.

[1] 
http://forum.dlang.org/post/qkonnwtxxtjmjtryrfax forum.dlang.org
Jun 09 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks


Welp, I tried making it faster and I apparently made it slower: 
https://github.com/kostya/benchmarks/pull/89

Oops.
Jun 17 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 17 June 2016 at 16:51:04 UTC, Jack Stouffer wrote:

 On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:

 D definitely needs some optimizations, I mean look at its 
 benchmarks compared to other languages: 
 https://github.com/kostya/benchmarks


 Welp, I tried making it faster and I apparently made it slower: 
 https://github.com/kostya/benchmarks/pull/89

 Oops.


Fixed: https://github.com/kostya/benchmarks/pull/91

This should be enough to make D the fastest in bench.b and 
second/third after C++ Gcc / Crystal, without changing the 
algorithm, which is not allowed.

Request to future contributors: please benchmark the code and 
make sure there's an improvement in the majority of compilers and 
most importantly in the fastest case (LDC in this instance) 
before submitting changes. Code style / refactoring changes are 
clearly welcome, as long as they don't decrease the performance.

In this particular case ` safe` is a performance pessimization in 
release mode, because it introduces bounds checks. To remedy 
that, one has to compile with `-boundscheck=off`. See 
https://dlang.org/dmd-linux.html#switch-boundscheck for more info.

A note about my changes: as for this piece of code we are only 
interested in performance and code brevity, I decided to omit 
attributes as no combination of them could bring performance 
improvement (and  safe was a pessimization in all of my tests, 
given the build flags). I have more information about the changes 
in the pull request.

Overall DMD completes mandel.b for 75.5% of the time of the 
previous version, LDC for 62.6% and GDC for 88.1%. The code is 
64.9% of the original (in terms of LOC).
Jun 25 2016
parent reply Jadbox <jadit2 gmail.com> writes:
On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:

 Overall DMD completes mandel.b for 75.5% of the time of the 
 previous version, LDC for 62.6% and GDC for 88.1%. The code is 
 64.9% of the original (in terms of LOC).


This is what I love: less code with more performance. Great work 


IMHO, D is fast enough (generally speaking). To me, D is lacking 
clear practical examples (e.g. webserver using sql db), 
libraries, and success stories. The fact that there isn't an AWS 
sdk for D makes it a show stopper for most developers I talk to.
Jun 26 2016
parent ZombineDev <petar.p.kirov gmail.com> writes:
On Sunday, 26 June 2016 at 23:27:41 UTC, Jadbox wrote:

 On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:

 Overall DMD completes mandel.b for 75.5% of the time of the 
 previous version, LDC for 62.6% and GDC for 88.1%. The code is 
 64.9% of the original (in terms of LOC).


 This is what I love: less code with more performance. Great 



Thanks :)
I think that by using ranges we might be able to write a solution 
with 10x less code, but AFAIK, algorithmic changes are not 
accepted, because the idea of the benchmark is to show same 
solution written in different languages.


 IMHO, D is fast enough (generally speaking). To me, D is 
 lacking clear practical examples (e.g. webserver using sql db), 
 libraries, and success stories. The fact that there isn't an 
 AWS sdk for D makes it a show stopper for most developers I 
 talk to.


I am not the right guy to talk about stuff like this, because I 
really enjoy writing things from scratch. If I had the time I 
would probably follow the steps of projects like Trinix and 
PowerNex and I would try to write an OS from scratch :D
Web development is just not my thing. I am glad that there are 
other people pushing those areas with D, because it really shows 
how versatile the language is and makes the lifes of other people 
easier.

For example, see this PR [1] that adds a nice tutorial to Dlang 
Tour [2] about deploying vibe.d on Heroku. I know it's not Amazon 
AWS, but still it might be helpful. Also, I found this [3] forum 
post about AWS Lambda.

BTW have you checked Kai Nacke's book [4] about Web Development 
with D?

[1]: https://github.com/stonemaster/dlang-tour/pull/289
[2]: http://tour.dlang.org/tour/en/vibed/vibe-d-web-framework
[3]: 
http://forum.dlang.org/post/jqotefrswxhaiqteefdq forum.dlang.org
[4]: http://wiki.dlang.org/Books
Jun 26 2016