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