Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: About GC: The Future of Rust : GC integration
On Thursday, 9 June 2016 at 05:52:47 UTC, Adam Wilson wrote: But to be fair, that's not a memory management problem but a disk IO problem. Quoting for truth. The single biggest problem large games have is bandwidth, both in terms of offline storage and memory/bus bandwidth. This will only get worse with time as the quality of resources increases at a faster rate than bandwidth increases.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: Interest in Paris area D meetups?
On Wednesday, 8 June 2016 at 16:40:53 UTC, Claude wrote: On Wednesday, 1 June 2016 at 20:33:40 UTC, Guillaume Chatelet wrote: On Wednesday, 1 June 2016 at 19:25:13 UTC, Claude wrote: On Wednesday, 18 May 2016 at 15:05:21 UTC, Guillaume Chatelet wrote: I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Sorry for the later reply, but yes, I'd be interested by a meetup in Paris. Anyone else? Two sounds like a good start ^__^ We can start with a beer somewhere :) Yeah great! I'm up for a beer. I work near Gare de l'Est. We can have a drink after work-time (I'm available around 19h), and share about what we think about that evil auto-decode. Is it ok for you ? Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00?
Re: Optimizations and performance
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/qkonnwtxxtjmjtryr...@forum.dlang.org
Re: Optimizations and performance
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.
Re: GSlice - Re: [OT] About GC: The Future of Rust : GC integration
On Wednesday, 8 June 2016 at 12:38:25 UTC, Andrei Alexandrescu wrote: On 6/8/16 1:59 PM, Nick Treleaven wrote: I wonder if Andrei's allocator API supports freeing with a size argument. Size is required with all deallocations. -- Andrei Thanks. So I suppose it's up to each allocator whether this will work or not: alloc.makeArray!T(5).ptr.Alias!(p => alloc.dispose(p)); I guess it would work for Mallocator.
Re: The Problem With DIPs
On 2016-06-08 22:44, Walter Bright wrote: I agree we should do better, I certainly welcome any efforts you're willing to devote to this. Most of the huge improvements in process in D have come about precisely because someone selected himself to take charge of the matter and make the required sustained effort. Saying others should do this or that has an abysmal track record. I just didn't want to make promises I could not deliver. The problem with the DIP's is that, by definition, it's something that needs your or Andrei's approval. Therefore it's not possible to leave it completely for someone else to deal with. -- /Jacob Carlborg
Re: Optimizations and performance
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
Version identifier for PS4
Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1] https://github.com/dlang/dmd/pull/5850
Re: Version identifier for PS4
On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1] https://github.com/dlang/dmd/pull/5850 "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym.
Re: Version identifier for PS4
On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. Nice suggestion. I don't know about similarities between PlayStation versions, but how about "PlayStation", with 'sub' version "PlayStation4"? Using the spec's "all identifiers derived from the ones listed above [e.g. "PlayStation"] by appending any character(s) are reserved" (Wikipedia says that both PS3 and PS4 are based on FreeBSD)
Re: Version identifier for PS4
On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1] https://github.com/dlang/dmd/pull/5850 "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. As the "author"(?) of that pull request I would love to get a discussion going. PS4 vs Orbis vs PlayStation4 so far. The reason I went for the acronym is that all other tools I could find with a reference to PS4 used the acronym, I guess that is a bad reason though. I am open to making another pullrequest with another identifier as long as we can get a general consensus about which one to use.
Improving style of error pages of this website
Hi! I've just read this post: https://dlang.org/blog/index.php/author/dblogadmin/ and I've a few suggestions to improve this website: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/"; I type "http://tour.dlang.org//";, it gives me a "ugly" 404 error page. That can be definitely improved. Not only, and this is even more "critical" for new users. If I type "https://dlang.org//asdasd"; instead of "https://dlang.org/";, the server returns us a "ugly" 404 error page. At this point, I guess these problems may exist in other parts of the website. 2. Forums, like this one, could definitely be improved by adding markdown as a markup language to edit and style posts. There should also be the possibility to edit already posted questions and answers, and the edit as well as the original answer or question should be somehow visible and recoverable, similar to SO. 3. The dlang tour is nice but it could still be improved with an auto-completion tool (maybe too much advanced for now). 4. These forums require us to provide an e-mail, even if it's invalid. I don't understand why. We could just do that only registered users can post and that the e-mail address is visible only if the registered user wants to show it. 5. Definitely the style of this form as well as of the inputs to insert our name, e-mail address, etc, are not "pretty"... Of course these are just "my ideas and suggestions". I'm not a D programmer yet, but I'm quite excited with this language, which combines all the nice things of the languages that I use: Java, C, C++, Python... Cheers!
Re: Version identifier for PS4
On Thursday, 9 June 2016 at 13:09:01 UTC, Johan Engelen wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. Nice suggestion. I don't know about similarities between PlayStation versions, but how about "PlayStation", with 'sub' version "PlayStation4"? Using the spec's "all identifiers derived from the ones listed above [e.g. "PlayStation"] by appending any character(s) are reserved" (Wikipedia says that both PS3 and PS4 are based on FreeBSD) Maybe, I doubt a lot of code will be reusable between Playstation consoles though judging from the past.
Re: Improving style of error pages of this website
On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: Hi! I've just read this post: https://dlang.org/blog/index.php/author/dblogadmin/ and I've a few suggestions to improve this website: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/"; I type "http://tour.dlang.org//";, it gives me a "ugly" 404 error page. That can be definitely improved. Not only, and this is even more "critical" for new users. If I type "https://dlang.org//asdasd"; instead of "https://dlang.org/";, the server returns us a "ugly" 404 error page. At this point, I guess these problems may exist in other parts of the website. 2. Forums, like this one, could definitely be improved by adding markdown as a markup language to edit and style posts. There should also be the possibility to edit already posted questions and answers, and the edit as well as the original answer or question should be somehow visible and recoverable, similar to SO. 3. The dlang tour is nice but it could still be improved with an auto-completion tool (maybe too much advanced for now). 4. These forums require us to provide an e-mail, even if it's invalid. I don't understand why. We could just do that only registered users can post and that the e-mail address is visible only if the registered user wants to show it. 5. Definitely the style of this form as well as of the inputs to insert our name, e-mail address, etc, are not "pretty"... Of course these are just "my ideas and suggestions". I'm not a D programmer yet, but I'm quite excited with this language, which combines all the nice things of the languages that I use: Java, C, C++, Python... Cheers! Another thing I've just noticed is that there's not "forgot password" feature when login to this website. I think I once registered to this website, but I forgot my password, and now there's no way of recovering it. Another issue that may exist is that there's no notification and also subscription system that would tell you about news regarding a post (but not just necessarily a post) where you're involved because you had subscribed to it...
Re: Version identifier for PS4
On 6/9/16 9:09 AM, Markus Pursche wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1] https://github.com/dlang/dmd/pull/5850 "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. As the "author"(?) of that pull request I would love to get a discussion going. PS4 vs Orbis vs PlayStation4 so far. The reason I went for the acronym is that all other tools I could find with a reference to PS4 used the acronym, I guess that is a bad reason though. I am open to making another pullrequest with another identifier as long as we can get a general consensus about which one to use. The precedent is to use whatever the OS defines for the host C compiler. This is the reason we have lower case "linux" for version, which is inconsistent with other version identifiers, but consistent with Linux's #define in C code. So if Sony uses PS4 as a define, I think that's logical to use for the version statement. -Steve
Re: Improving style of error pages of this website
Another issue that may exist is that there's no notification and also subscription system that would tell you about news regarding a post (but not just necessarily a post) where you're involved because you had subscribed to it... Never mind regarding the subscription.
Re: Improving style of error pages of this website
On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 2. Forums, like this one, could definitely be improved by adding markdown as a markup language to edit and style posts. There should also be the possibility to edit already posted questions and answers, and the edit as well as the original answer or question should be somehow visible and recoverable, similar to SO. Currently, the forum is simply a web interface to the D newsgroup server. It is not not a stand alone forum. There is also a mailing list interface to the newsgroups. Implementing editing, markdown, or anything specific to the forums is a bit problematic because of how it would be reflected in the newsgroups and the mailing list. That said, I've got a post coming to the blog tomorrow that will talk about future plans for the forums. 4. These forums require us to provide an e-mail, even if it's invalid. I don't understand why. We could just do that only registered users can post and that the e-mail address is visible only if the registered user wants to show it. Vladimir can answer authoritatively, but I believe this is because of RFC 850, which requires an email in USENET message headers.
Re: Version identifier for PS4
On Thursday, 9 June 2016 at 13:16:58 UTC, Steven Schveighoffer wrote: On 6/9/16 9:09 AM, Markus Pursche wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: [...] As the "author"(?) of that pull request I would love to get a discussion going. PS4 vs Orbis vs PlayStation4 so far. The reason I went for the acronym is that all other tools I could find with a reference to PS4 used the acronym, I guess that is a bad reason though. I am open to making another pullrequest with another identifier as long as we can get a general consensus about which one to use. The precedent is to use whatever the OS defines for the host C compiler. This is the reason we have lower case "linux" for version, which is inconsistent with other version identifiers, but consistent with Linux's #define in C code. So if Sony uses PS4 as a define, I think that's logical to use for the version statement. -Steve I dont think Sony has any official #defines but all game engines I have ever used (proprietary, Unity, Unreal) preferred PLATFORM_PS4 over PLATFORM_PLAYSTATION4 or PLATFORM_ORBIS.
Re: Improving style of error pages of this website
FYI, the newsgroups can be accessed at [1] and the mailing lists at [2]. [1] news://www.digitalmars.com/digitalmars/D [2] http://lists.puremagic.com/cgi-bin/mailman/listinfo/digitalmars-d
Re: Optimizations and performance
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 comparison Java and C# which the upper example would fit well), 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.
Re: Improving style of error pages of this website
On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/"; I type "http://tour.dlang.org//";, it gives me a "ugly" 404 error page. That can be definitely improved. Please file a bug here: http://issues.dlang.org. Thanks 2. Forums, like this one, could definitely be improved by adding markdown as a markup language to edit and style posts. [snip] 4. These forums require us to provide an e-mail, even if it's invalid. Both these things can be addressed by the fact that the forums are actually just an interface to an NNTP server, so the email is required. I know that some people here don't use the web interface at all and just use something like Thunderbird to browse the forums.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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
Re: The Problem With DIPs
On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: A DIP not being dealt with does not mean it is a bad idea. It pretty much means we just aren't ready to deal with it at the moment. It's time may not have come yet. But it's not going away, it'll still be there when needed. I've found mining DIPs to be quite useful in designing the 'return ref' feature. DIPs are a gold mine of ideas that be built upon, and I know where to find them. So DIPs are more like idea pool and what wasn't outright rejected so far can still be of some interest?
Re: Optimizations and performance
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"?
Re: Optimizations and performance
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
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
D's memory-hungry templates
While working on a small PR (https://github.com/dlang/phobos/pull/4420), I noticed that D's template computation system has horrific memory consumption (as well as being very slow). I believe there are several reasons for this: 1) All template instantiations are memoized, even if they're just private internal implementation details. This causes the space complexity for recursive algorithms to generally be just as bad as the time complexity, whereas it should usually be much better. 2) Everything is immutable, which sometimes forces O(N) array algorithms to be replaced with O(N log(N)) tree algorithms. This compounds with (1). 3) Even though D *requires* that all template algorithms be recursive, the recursion limit is actually set very low (500). This forces efficient linear recursion O(N) algorithms to be replaced with wasteful O(N log(N)) binary recursion, unless N is guaranteed to be very small. This compounds with (1), and sometimes (2). The combination of these issues causes very severe memory consumption and speed problems; as an example `staticSort!(aliasSeq!(iota(N)))`, which should have a time complexity of O(N log(N)) and a space complexity of O(N), instead seems to have a complexity of O(N^2 log(N)) for both time and space. This is awful - worse than any normal sorting algorithm, despite the fact that `staticSort` is based on the normally-very-efficient "merge sort" algorithm. On my system, for N = 450 the sort takes about 300 ms and consumes 120 MB of memory. (With my pull request this is reduced to 80 ms and 35 MB, but that's still terrible.) Ultimately, I believe it was a mistake for D to implement a separate, inferior programming language just for templates. However, it is too late to change that now (at least for D2), so I will offer some suggestions as to how memory consumption can be reduced within the current design: A) Members of a template instantiation should be eagerly evaluated. Once a template has been fully evaluated, any private member which is not referenced by a public one should be deleted. B) Template instantiations should be deleted after they are no longer accessible (even indirectly) via a top-level declaration. C) The compiler should store `T...` in such a way that recursively appending N items to the beginning or end of an AliasSeq does not allocate more than O(N log(N)) additional memory. (O(N) is possible with more indirections.) D) Implement tail recursion optimization for templates. Tail recursion should not count toward the recursion depth limit. E) Consider eliminating the recursion limit entirely. Given that the template system is Turing Complete and mandates heavy use of recursion, there is no reason to think that a depth of 500 means something has gone wrong, any more than for a `while` loop running 500+ iterations. (Implementing this may require fixing the exponential name growth, though.) Implementing A, B, and C should get D's template memory consumption under control. Implementing D and E will make template computation more flexible, encouraging people to use it more and find new things to complain about. :-P Thoughts?
Re: Optimizations and performance
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
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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".
Re: Optimizations and performance
All of this goes back to knowing what you are truly benchmarking.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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.
Re: Interest in Paris area D meetups?
On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great!
Re: Improving style of error pages of this website
On Thursday, 9 June 2016 at 13:33:43 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/"; I type "http://tour.dlang.org//";, it gives me a "ugly" 404 error page. That can be definitely improved. Please file a bug here: http://issues.dlang.org. Thanks The tour is currently managed here, but I filled an issue https://github.com/stonemaster/dlang-tour/issues/215 Maybe we should move it also to the official Github namespace? Dlang.org issue: https://issues.dlang.org/show_bug.cgi?id=16147 @nbro: Thanks a lot for sharing your feedback with us! Highly appreciated!
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: Andrei posted this on another thread. I felt it deserved its own thread. It's very important. - I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons: * The garbage collector eliminates probably 60% of potential users right off. * Tooling is immature and of poorer quality compared to the competition. * Safety has holes and bugs. * Hiring people who know D is a problem. * Documentation and tutorials are weak. * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest. * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist. * Let's wait for the "herd effect" (corporate support) to start. * Not enough advantages over the competition to make up for the weaknesses above. Hello, I have to stress I am beginner in programming, mainly interested in number crunching in academia (at least so far). I started to write a small project in D, but had to switch to C for few reasons: 1) Importance for my CV. I know Python, if I add also C - it sounds, and could be useful since the C language is, apart from the other reasons, is popular and could help me wit the future job, both in academia and industry, since there are many C/C++ projects. 2) The libraries - in the scientific world you can find practically everything which has already been coded in C, => many C libraries. To link it to be used within D code requires some work/efforts, and since I am not that confident in my IT skills, I decided that C code calling C libraries is much safer. 3) For C - a lot of tutorials, everything has been explained at stack overflow many times, huge community of people. E.g. you want to use OpenMP, Open MPI - everything is there, explained many times, etc. 4) The C language is well tested and rock solid stable. However, if you encounter a potential bug in D, I am not sure how long would it take to fix. 5) Garbage collector - it will slow my number crunching down. Please, do not take it as criticism, I like D language, I tried it before C and I find it much much easier, and user friendly. I feel it is more similar to Python. On the other hand C++ is too complex for me, and D would be the perfect option for the scientific community, if the above points would be fixed somehow.. Best luck with your work!
Re: Optimizations and performance
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?
Re: Optimizations and performance
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?
Re: Interest in Paris area D meetups?
On Thursday, 9 June 2016 at 16:27:41 UTC, Claude wrote: On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great! FYI my email address: chatelet.guillaume at gmail
Re: Optimizations and performance
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
Re: Optimizations and performance
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.
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: 5) Garbage collector - it will slow my number crunching down. You are a scientist, so try to measure. GC generally improves throughput at the cost of latency.
Re: Optimizations and performance
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.
Re: Optimizations and performance
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).
Re: std.experimental.checkedint is ready for comments!
On Tuesday, 7 June 2016 at 08:50:07 UTC, Robert burner Schadek wrote: ... I left my commentary in the PR. Overall it looks pretty good design wise, and I would totally vote for it's inclusion in Phobos.
Re: Optimizations and performance
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."
Re: Optimizations and performance
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.
Re: D's memory-hungry templates
On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote: While working on a small PR (https://github.com/dlang/phobos/pull/4420), I noticed that D's template computation system has horrific memory consumption (as well as being very slow). [...] I run into the same issues with https://maikklein.github.io/2016/03/01/metaprogramming-typeobject/ I think doing metaprogramming that way is really neat but the memory consumption if I remember correctly was around 50 times worse than doing it without "type objects". Also C++ beat D in every compile time meta programming benchmark that I have tested. The only time when D was roughly as fast as C++ was with string mixins but they are even more memory hungry. Stuff like filtering odd integers from an AliasSeq of 100k elements etc. I mostly recreated those benchmarks in D https://github.com/boostorg/hana/tree/master/benchmark The only time when D compiled roughly as fast as C++ was with string mixins and they are even more memory hungry.
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves "computer scientists" while many write a lot of their programs without tests.
I implemented delegates in D
I am currently writing a task system and I have this case where I want to send a delegate to a different thread but this delegate also captures a variable. I use this to implement a "future". Now as far as I know this delegate will allocate GC memory and I just wanted to avoid that, just for fun. Here is the code https://dpaste.dzfl.pl/cd77fce99a5b I have only worked on it a couple of hours and I am sure there are many problems with it. Basically the idea is that you can use normal lambda syntax. If you want a function that returns and int and takes an int, you can write it like this: (int i) => i If you want a function that returns an int, takes an int, but also captures and int you would write it like this (int i, int captured) => i + captured But you also have to declare the base function type without the captured variables beforehand. Fn!(FnType!(int, int), (int i, int captured) => i + captured)(42); That is how I know what the captured variables are. The only part that is currently missing are polymorphic delegates. They are not too useful if I can't pack them into the same array. I guess I have to do this with classes/interfaces. Thoughts? Has this been done before?
Re: I implemented delegates in D
On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote:
Has this been done before?
Well, yes, the entire point of delegates is to be able to capture
variables (as opposed to function pointers, which cannot).
auto createADelegate(int captured) {
return (int a) => captured + a;
}
void main() {
auto dg1 = createADelegate(5);
auto dg2 = createADelegate(32);
assert(dg1(5) == 10);
assert(dg1(10) == 15);
assert(dg2(8) == 40);
assert(dg2(32) == 64);
}
https://dpaste.dzfl.pl/90ebc29651f6
(Unfortunately template delegates, like the ones used with map,
don't keep their captured variables alive after the captured
variables go out of scope, but it doesn't sound like you need
those)
Re: The Problem With DIPs
On 6/9/2016 4:49 AM, Jacob Carlborg wrote: The problem with the DIP's is that, by definition, it's something that needs your or Andrei's approval. Therefore it's not possible to leave it completely for someone else to deal with. That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc.
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 20:38:30 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves "computer scientists" while many write a lot of their programs without tests. A ton of computer science, even the one that is peer reviewed, do not publish code. It's garbage... And then you look at https://twitter.com/RealPeerReview and conclude it maybe isn't that bad.
Re: The Problem With DIPs
On 6/9/2016 6:54 AM, Kagamin wrote: On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: A DIP not being dealt with does not mean it is a bad idea. It pretty much means we just aren't ready to deal with it at the moment. It's time may not have come yet. But it's not going away, it'll still be there when needed. I've found mining DIPs to be quite useful in designing the 'return ref' feature. DIPs are a gold mine of ideas that be built upon, and I know where to find them. So DIPs are more like idea pool and what wasn't outright rejected so far can still be of some interest? Of course. For example, there have been many ref counting proposals for D (not remotely all of them are DIPs). They've all had problems of one sort or another, but by reviewing existing work one has a hope of coming up with a better proposal than repeating a flawed one. Or one can take the "best of" the various proposals to produce a better one. It becomes part of the collective knowledge around D.
Re: Andrei's list of barriers to D adoption
On 6/9/2016 9:44 AM, Yura wrote: 4) The C language is well tested and rock solid stable. However, if you encounter a potential bug in D, I am not sure how long would it take to fix. Thanks for taking the time to post here. Yes, there are bugs in D. Having dealt with buggy compilers from every vendor for decades, I can speak from experience that almost every bug has workarounds that will keep the project moving. Also, bugs in D tend to be with the advanced features. But there's a C-ish subset that's nearly a 1:1 correspondence to C, and if you are content with C style it'll serve you very well.
Re: Andrei's list of barriers to D adoption
On 6/9/2016 1:38 PM, Jack Stouffer wrote: On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves "computer scientists" while many write a lot of their programs without tests. A scientist is someone who does research to make discoveries, while an engineer puts scientific discoveries to work. Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei is.
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei is. Unfortunately, the term "software engineer" is a LOT less popular than "computer scientist".
Re: I implemented delegates in D
On Thursday, 9 June 2016 at 21:32:33 UTC, Alex Parrill wrote:
On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote:
Has this been done before?
Well, yes, the entire point of delegates is to be able to
capture variables (as opposed to function pointers, which
cannot).
auto createADelegate(int captured) {
return (int a) => captured + a;
}
void main() {
auto dg1 = createADelegate(5);
auto dg2 = createADelegate(32);
assert(dg1(5) == 10);
assert(dg1(10) == 15);
assert(dg2(8) == 40);
assert(dg2(32) == 64);
}
https://dpaste.dzfl.pl/90ebc29651f6
(Unfortunately template delegates, like the ones used with map,
don't keep their captured variables alive after the captured
variables go out of scope, but it doesn't sound like you need
those)
I meant, "has this been implement as a library before". I am well
aware that delegates exist in the language but as far as I know
you can not do manual allocation with delegates (to avoid the GC).
Re: D's memory-hungry templates
On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote: Ultimately, I believe it was a mistake for D to implement a separate, inferior programming language just for templates. However, it is too late to change that now (at least for D2), so I will offer some suggestions as to how memory consumption can be reduced within the current design: If you have a design in mind, I'd be interested in hearing your proposals for an alternative.
Re: I implemented delegates in D
To avoid the delegate being GC allocated, use `scope foo = (int i) { ... }`
at call site.
You can also make your function signature as `void func(scope void
delegate() dg)` in which case it won't allocate if you pass a literal
directly.
2016-06-09 23:57 GMT+02:00 maik klein via Digitalmars-d <
digitalmars-d@puremagic.com>:
> On Thursday, 9 June 2016 at 21:32:33 UTC, Alex Parrill wrote:
>
>> On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote:
>>
>>> Has this been done before?
>>>
>>
>> Well, yes, the entire point of delegates is to be able to capture
>> variables (as opposed to function pointers, which cannot).
>>
>>
>> auto createADelegate(int captured) {
>> return (int a) => captured + a;
>> }
>>
>> void main() {
>> auto dg1 = createADelegate(5);
>> auto dg2 = createADelegate(32);
>> assert(dg1(5) == 10);
>> assert(dg1(10) == 15);
>> assert(dg2(8) == 40);
>> assert(dg2(32) == 64);
>> }
>>
>> https://dpaste.dzfl.pl/90ebc29651f6
>>
>> (Unfortunately template delegates, like the ones used with map, don't
>> keep their captured variables alive after the captured variables go out of
>> scope, but it doesn't sound like you need those)
>>
>
> I meant, "has this been implement as a library before". I am well aware
> that delegates exist in the language but as far as I know you can not do
> manual allocation with delegates (to avoid the GC).
>
Re: I implemented delegates in D
On 6/9/16 6:06 PM, Mathias Lang via Digitalmars-d wrote:
To avoid the delegate being GC allocated, use `scope foo = (int i) { ...
}` at call site.
Is that true? At one point in D's past, this ONLY worked if you passed a
delegate to a function accepting a scope delegate. Maybe it's been fixed.
-Steve
Re: I implemented delegates in D
It's even part of DMD testsuite:
https://github.com/dlang/dmd/blob/38c1bad2f41ad8e6bc7c08deae26e30c9c7d7704/test/runnable/nogc.d#L20
At DConf, Dicebot mention that he had some problems in the past and it
doesn't work in some places. The Weka people seemed to have similar
experience.
I did some experiment and so far the only related issue I've found is
https://issues.dlang.org/show_bug.cgi?id=16037 . If you happen to come
accross a case where it doesn't work, I would very like to be CC'ed on that
issue :)
2016-06-10 0:17 GMT+02:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d@puremagic.com>:
> On 6/9/16 6:06 PM, Mathias Lang via Digitalmars-d wrote:
>
>> To avoid the delegate being GC allocated, use `scope foo = (int i) { ...
>> }` at call site.
>>
>
> Is that true? At one point in D's past, this ONLY worked if you passed a
> delegate to a function accepting a scope delegate. Maybe it's been fixed.
>
> -Steve
>
Re: I implemented delegates in D
On Thursday, 9 June 2016 at 22:06:24 UTC, Mathias Lang wrote:
To avoid the delegate being GC allocated, use `scope foo = (int
i) { ... }`
at call site.
You can also make your function signature as `void func(scope
void
delegate() dg)` in which case it won't allocate if you pass a
literal
directly.
2016-06-09 23:57 GMT+02:00 maik klein via Digitalmars-d <
digitalmars-d@puremagic.com>:
On Thursday, 9 June 2016 at 21:32:33 UTC, Alex Parrill wrote:
On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote:
Has this been done before?
Well, yes, the entire point of delegates is to be able to
capture variables (as opposed to function pointers, which
cannot).
auto createADelegate(int captured) {
return (int a) => captured + a;
}
void main() {
auto dg1 = createADelegate(5);
auto dg2 = createADelegate(32);
assert(dg1(5) == 10);
assert(dg1(10) == 15);
assert(dg2(8) == 40);
assert(dg2(32) == 64);
}
https://dpaste.dzfl.pl/90ebc29651f6
(Unfortunately template delegates, like the ones used with
map, don't keep their captured variables alive after the
captured variables go out of scope, but it doesn't sound like
you need those)
I meant, "has this been implement as a library before". I am
well aware that delegates exist in the language but as far as
I know you can not do manual allocation with delegates (to
avoid the GC).
But that means that the closure will be allocated on the stack
right? What happens when I send it with
http://dpldocs.info/experimental-docs/std.concurrency.send.html
Will it copy the function or will it only send the pointer?
Also scope on local vars is marked to be deprecated, see
http://stackoverflow.com/a/4713064/944430
I don't think that I can use delegates (without the gc), what I
basically do is send a delegate to a thread, create a fiber on
that thread and put it in a thread local array.
The delegate contains a "future" that I can access on a different
thread. I use it as mechanism to share results. (Its synchronized
with atomics)
I mean currently I just use gc delegates, but I am exploring some
alternatives.
Re: I implemented delegates in D
On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote:
I am currently writing a task system and I have this case where
I want to send a delegate to a different thread but this
delegate also captures a variable. I use this to implement a
"future".
Now as far as I know this delegate will allocate GC memory and
I just wanted to avoid that, just for fun.
Here is the code https://dpaste.dzfl.pl/cd77fce99a5b
I have only worked on it a couple of hours and I am sure there
are many problems with it.
Basically the idea is that you can use normal lambda syntax. If
you want a function that returns and int and takes an int, you
can write it like this:
(int i) => i
If you want a function that returns an int, takes an int, but
also captures and int you would write it like this
(int i, int captured) => i + captured
But you also have to declare the base function type without the
captured variables beforehand.
Fn!(FnType!(int, int), (int i, int captured) => i +
captured)(42);
That is how I know what the captured variables are.
The only part that is currently missing are polymorphic
delegates. They are not too useful if I can't pack them into
the same array.
I guess I have to do this with classes/interfaces.
Thoughts?
Has this been done before?
What you have here is more functor, to the extent that you can
memorize the parameters. The problem is that it's not compatible
with the delegates as defined in the language.
Actual D delegates get collected when we take the address and the
context of a member function with "&". To allocate the delegate
itself in the non GC heap is easy (with a struct that contains
two pointers).
Your message has motivated me to make this, thanks to a union
true nogc delegates are possible:
=
module runnable;
union Delegate(FT)
{
// delegate layout as defined in the D ABI
struct DgMembers
{
void* ptr;
FT funcptr;
}
DgMembers members;
// the 2nd member is "true" D delegate type
import std.array: replace;
mixin("alias DT = " ~ FT.stringof.replace("function",
"delegate") ~ ";");
DT dg;
}
void main() @nogc
{
static struct Foo
{
@nogc string delegate() test;
@nogc string source() {return "test";}
}
import std.experimental.allocator.mallocator;
import std.experimental.allocator;
Foo foo;
alias DelegateT = Delegate!(typeof(&Foo.source));
// &Foo.source takes the static address, i.e in the data
segment
DelegateT* dg = make!DelegateT(Mallocator.instance);
dg.members.ptr = &foo;
dg.members.funcptr = &Foo.source;
foo.test = dg.dg;
assert(foo.test() == "test");
}
=
Here you have a true D delegate that's conform with the language.
Re: The Problem With DIPs
On Thursday, 9 June 2016 at 21:34:00 UTC, Walter Bright wrote: On 6/9/2016 4:49 AM, Jacob Carlborg wrote: The problem with the DIP's is that, by definition, it's something that needs your or Andrei's approval. Therefore it's not possible to leave it completely for someone else to deal with. That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. It is not clear where to comment to begin with.
Re: I implemented delegates in D
2016-06-10 1:20 GMT+02:00 maik klein via Digitalmars-d <
digitalmars-d@puremagic.com>:
> But that means that the closure will be allocated on the stack right? What
> happens when I send it with
> http://dpldocs.info/experimental-docs/std.concurrency.send.html
>
> Will it copy the function or will it only send the pointer?
>
Yes it will be stack allocated.
But if you wish to `send` something, I think you're better off using a
function in an object (disclaimer: never tried).
Functions are not copied, so I guess you are refering to the context
pointer ?
> Also scope on local vars is marked to be deprecated, see
> http://stackoverflow.com/a/4713064/944430
>
>
Yeah and they are not going away anytime soon. There's a reason why the
compiler won't even warn about them. They are extremely useful and there is
currently no replacement for them.
> I don't think that I can use delegates (without the gc), what I basically
> do is send a delegate to a thread, create a fiber on that thread and put it
> in a thread local array.
>
Did you try to send a native delegate ? I would be very surprised if you
were allowed to do so.
> The delegate contains a "future" that I can access on a different thread.
> I use it as mechanism to share results. (Its synchronized with atomics)
>
> I mean currently I just use gc delegates, but I am exploring some
> alternatives.
>
>
Note that not all delegates allocate. Function local delegate refering to
variable do, but the one refering to aggregate never do.
E.g. the following compiles and run:
```
struct Foobar { string toString() @nogc { return "Foobar"; } }
void func (string delegate() ts) @nogc {}
void main () @nogc
{
scope c = new Object;
Foobar s;
func(&c.toString); // ptr=c funcptr=toString
func(&s.toString); //ptr =s funcptr=toString
string delegate() @nogc dg;
dg.funcptr = (&s.toString).funcptr; // There might be a better way to
do that
dg.ptr = &s;
assert("Foobar" == dg());
}
```
Re: The Problem With DIPs
On 6/9/2016 5:10 PM, deadalnix wrote: It is not clear where to comment to begin with. There's a space in the table for a link to n.g. discussion.
Re: Optimizations and performance
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?
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 21:54:05 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei is. Unfortunately, the term "software engineer" is a LOT less popular than "computer scientist". How so? I only hear people use the term "programmer" or "informatics". Computer Science -> pure math / classification / concepts. Software Engineering -> process of developing software. At my uni we had the term "informatics" which covers both comps.sci., software engineering and requirements analysis, human factors etc. But it IS possible to be a computer scientist and only know math and no actual programming. Not common, but possible. But yes, sometimes people who have not studied compsci, but only read stuff on wikipedia engage in debates as if they knew the topic and then the distinction matters. There are things you never have to explain to a person who knows compsci, but you almost always have trouble explaining to people who don't know it (but think they do, because they are programmers and have seen big-oh notation in documentation). It is like a car engineering listening to a driver claiming that you should pour oil on your breaks if they make noise. Or a mathematician having to explain what infinity entails. At some point it is easier to just make a distinction between those who know the fundamental things about how brakes actually are constructed, and those who know how to drive a car. The core difference as far as debates goes, is that comp sci is mostly objective (proofs) and software engineering is highly subjective (contextual practice). So, if the topic is compsci then you usually can prove that the other person is wrong in a step-by-step irrefutable fashion. Which makes a big difference, actually. People who know compsci usually think that is ok, because they like to improve their knowledge and are used to getting things wrong (that's how you learn). People who don't know compsci usually don't like it becuase they are being told that they don't know something they like to think they know (but actually don't and probably never will). That's just the truth... ;-)
Re: Andrei's list of barriers to D adoption
On Friday, June 10, 2016 02:38:28 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Thursday, 9 June 2016 at 21:54:05 UTC, Jack Stouffer wrote: > > On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: > >> Programming is a mix of engineering and craft. There are > >> people who do research into programming theory, and those are > >> computer scientists. I'm not one of them. Andrei is. > > > > Unfortunately, the term "software engineer" is a LOT less > > popular than "computer scientist". > > How so? I only hear people use the term "programmer" or > "informatics". I assume that you're not from the US? In the US at least, professional programmers are almost always referred to officially as software engineers (though they use the term programmers informally all the time), whereas the terms computer science and computer scientist are generally reserved for academics. And while the term informatics (or very similar terms) are used in several other languages/countries, I've never heard the term used in the US except to mention that some other languages/countries use the term informatics for computer science, and I'm willing to bet that relatively few programmers in the US have ever even heard the term informatics. - Jonathan M Davis
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: 4) The C language is well tested and rock solid stable. loool.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 06:25:55 UTC, ketmar wrote: On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: 4) The C language is well tested and rock solid stable. loool. ah, sorry, let me explain myself. i hit ALOT of gcc bugs in my life. and i never fixed any of them myself, 'cause gcc is very huge, and i don't feel that it worth it. even with bugs that blocked my work i used workarounds and hand-written asm. i hit some bugs in D too. curiously, it comparable with gcc in numbers (maybe this tells us something, and maybe it is just a coincidence). some of them i was able not only report, but fix. usually, official fix comes later, and was better than mine hacky patch, but hey... DMD compiler is less complex than gcc, *alot* less complex. now, why i loled: i thinked about what you wrote, and found that gcc bugs blocks my work/pet projects more often than dmd bugs. it may sounds strange, but dmd bug is usually either fixed fast enough (and building new dmd+druntime+phobos from sources takes less than two minutes on my PC), or i know a workaround. contrary to that, even if gcc bug was fixed fast (and usually they don't), rebuilding gcc takes 20‒30 minutes. and most of the time i can't even understand what fix does, due to huge and unknown codebase. so no, C languange is not "rock solid stable". it just has alot less features, and if you will use the same feature set in DMD, you will hardly hit a bug too.
