Re: Faster Command Line Tools in D
On Thursday, 25 May 2017 at 22:04:36 UTC, Ali Çehreli wrote: On 05/24/2017 06:39 AM, Mike Parker wrote: Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ Inspired Nim version, found on Reddit: https://www.reddit.com/r/programming/comments/6dct6e/faster_command_line_tools_in_nim/ Ali Wow, the D blog post opened Pandora's box.
Re: Faster Command Line Tools in D
On 05/24/2017 06:39 AM, Mike Parker wrote: Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ Inspired Nim version, found on Reddit: https://www.reddit.com/r/programming/comments/6dct6e/faster_command_line_tools_in_nim/ Ali
Re: Faster Command Line Tools in D
On Thursday, May 25, 2017 14:17:27 Suliman via Digitalmars-d-announce wrote: > > std.string, std.array, and std.algorithm all have > > cross-polination when it comes to array operations. It has to > > do with the history of when the modules were introduced. > > Is there any plan to deprecate all splitters and make one single. > Because now as I understand we have 4 functions that make same > task. I wouldn't expect any of the split-related functions to be going away. We often have a function that operates on arrays or strings and another which operates on more general ranges. It may mainly be for historical reasons, but removing the array-based functions would break existing code, and we'd get a whole other set of complaints about folks not understanding that you need to slap array() on the end of a call to splitter to get the split that they were looking for (especially if they're coming from another language and don't understand ranges yet). And ultimately, the array-based functions continue to serve as a way to have simpler code when you don't care about (or you actually need) the additional memory allocations. Also, splitLines/lineSplitter can't actually be written in terms of split/splitter, because split/splitter does not have a way to provide multiple delimeters (let alone multiple delimeters where one includes the other, which is what you get with "\n" and "\r\n"). So, that distinction isn't going away. It's also a common enough operation that having a function for it rather than having to pass all of the delimeters to a more general function is arguably worth it, just like having the overload of split/splitter which takes no delimiter and then splits on whitespace is arguably worth it over having a more general function where you have to feed it every variation of whitespace. - Jonathan M Davis
Re: Faster Command Line Tools in D
On Thursday, May 25, 2017 08:46:17 Steven Schveighoffer via Digitalmars-d- announce wrote: > std.string, std.array, and std.algorithm all have cross-polination when > it comes to array operations. It has to do with the history of when the > modules were introduced. Not only that, but over time, there has been a push to generalize functions. So, something that might have originally gotten put in std.string (because you'd normally think of it as a string function) got moved to std.array, because it could easily be generalized to work on arrays in general and not just string operations (I believe that split is an example of this). And something which was in std.array or std.string might have been generalized for ranges in general, in which case, we ended up with a new function in std.algorithm (hence, we have splitter in std.algorithm but split in std.array). The end result tends to make sense if you understand that functions that only operate on strings go in std.string, functions that operate on dynamic arrays in general (but not ranges) go in std.array, and functions which could have gone in std.string or std.array except that they operate on ranges in general go in std.algorithm. But if you don't understand that, it tends to be quite confusing, and even if you do, it's often the case that when you want to find a function to operate on a string, you're going to need to look in std.string, std.array, and std.algorithm. So, in part, it's an evolution thing, and in part, it's often just plain hard to find stuff when you're focused on a specific use case, and the library writer is focused on making the function that you need as general as possible. - Jonathan M Davis
Re: Tilix 1.5.8 released
On Wednesday, 24 May 2017 at 10:16:39 UTC, angel wrote: Simply the best ! I concur. I've been playing with several terminal emulators these last few weeks and Tilix was the only one combining features, unicode and full color range with speed and not being to CPU and memory hungry; for example Konsole that was the one I've been using these last years was almost always at the top 5 of CPU and memory usage when doing a "top", Tilix usually wayy below.
GDC Explorer Site Updated
In the downtime of the current bank holiday, I've gotten round to updating the compiler disassembler hosted on gdcproject.org. https://explore.dgnu.org Since the last update[1], there are now 47 new compilers, which includes 7 new ports (bringing the total number of D compilers to 20), and gdc versions 5.4.1, 6.3.0, and 7.1.0. I finally got round to rebasing to the latest version of compiler explorer, which sports a fancy new UI. A working example can be seen here. https://explore.dgnu.org/g/MaqTo0 Until the next announcement. Regards Iain [1]: http://forum.dlang.org/post/pholllvotxtbutisw...@forum.dlang.org
Re: Faster Command Line Tools in D
std.string, std.array, and std.algorithm all have cross-polination when it comes to array operations. It has to do with the history of when the modules were introduced. Is there any plan to deprecate all splitters and make one single. Because now as I understand we have 4 functions that make same task.
Re: Prettify and Resync are now open source too
On Friday, 19 May 2017 at 22:46:07 UTC, aberba wrote: On Friday, 19 May 2017 at 16:22:36 UTC, Ecstatic Coder wrote: I have released a few other tools on Github under the GNU GPL, including : * Resync : a local folder synchronizer. * Prettify : a source code prettifier for D and other languages. https://github.com/senselogic I don't know if some of you will be interested in them, but here they are... Remote folder sync will be awesome for code back up Resync is optimized to do very fast backups on any local drive, including remote drives mounted as local drives. But of course there isn't any form of compression when copying files, like in Rsync.
Re: Faster Command Line Tools in D
On 5/25/17 6:27 AM, Wulfklaue wrote: - Also wondering why one needed std.algorithm splitter, when you expect string split to be the fasted. Even the fact that you need to import std.array to split a string simply felt strange. Because split allocates on every call. The key, in many cases in D, to increasing performance is avoiding allocations. Has been that way for as long as I can remember. Another possibility to "fix" this problem is to simply use an allocator with split that allocates on some predefined stack space. This is very similar to what v3 does with the Appender. Unfortunately, allocator is still experimental, and so split doesn't support using it. - So much effort for relative little gain ( after v2 splitter ). The time spend on finding a faster solution is in business sense not worth it. But not finding a faster way is simply wasting performance, just on this simple function. The answer is always "it depends". If you're processing hundreds of these files in tight loops, it probably makes sense to optimize the code. If not, then it may make sense to focus efforts elsewhere. The point of the article is, this is how to do it if you need performance there. - Started to wonder if Python its PyPy is so optimized that without any effort, your even faster then D. What other D idiomatic functions are slow? split didn't actually seem that slow. I'll note that you could opt for just the AA optimization (the converting char[] to string only when storing a new hash lookup is big, and not that cumbersome) and leave the code for split alone, and you probably still could beat the Python code. Off-topic: Yesterday i was struggling with split but for a whole different reason. Take in account that i am new at D. Needed to split a string. Simple right? Search Google for "split string dlang". Get on the https://dlang.org/phobos/std_string.html page. After seeing the splitLines and start experimenting with it. Half a hour later i realize that the wrong function was used and needed to import std.array split function. Call it a issue with the documentation or my own stupidity. But the fact that Split was only listed as a imported function, in this mass of text, totally send me on the wrong direction. As stated above, i expected split to be part of the std.string, because i am manipulating a string, not that i needed to import std.array what is the end result. std.string, std.array, and std.algorithm all have cross-polination when it comes to array operations. It has to do with the history of when the modules were introduced. I simply find the documentation confusing with the wall of text. When i search for string split, you expect to arrive on the string.split page. Not only that, the split example are using split as a separate keyword, when i was looking for variable.split(). There is a search field on the top, which helps to narrow down what choices are available. Veteran D programmers are probably going to laughing at me for this but one does feel a bit salty after that. I understand your pain. I work with Swift often, and sometimes it's very frustrating trying to find the right tool for the job, as I'm not thoroughly immersed in Apple's SDK on a day-to-day basis. I don't know that any programming language gets this perfect. -Steve
Re: Faster Command Line Tools in D
On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote: Some of you may remember Jon Degenhardt's talk from one of the Silicon Valley D meetups, where he described the performance improvements he saw when he rewrote some of eBay's command line tools in D. He has now put the effort into crafting a blog post on the same topic, where he takes D version of a command-line tool written in Python and incrementally improves its performance. The blog: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ There are repeated references over usage of D at Netflix for machine learning. It will be a very helpful boost if someone comes up with any reference or a post regarding how D is used at Netflix and addition of Netflix to https://dlang.org/orgs-using-d.html will be amazing. References : https://news.ycombinator.com/item?id=14064012 https://news.ycombinator.com/item?id=14413546
Re: Faster Command Line Tools in D
On Thursday, 25 May 2017 at 06:22:28 UTC, Jon Degenhardt wrote: Thanks Walter, I appreciate your comments. And correct, as multiple people noted, a speed comparison with other languages not at all a goal of the article. The real intent was to tell a story of how several of D's features play together to enable optimizations like this, without having to write low-level code or step outside the core language features and standard library. Maybe as a more casual observer the article did feel more like Python vs D. I have not yet read the ycombinator comments, just from my personal observation after reading the article. My thinking was: - Python its PyPy is surprising fast. - Surprised that D was slower in version 1. - Kind of surprised again that it took so many versions to figure out the best approach. - Also wondering why one needed std.algorithm splitter, when you expect string split to be the fasted. Even the fact that you need to import std.array to split a string simply felt strange. - So much effort for relative little gain ( after v2 splitter ). The time spend on finding a faster solution is in business sense not worth it. But not finding a faster way is simply wasting performance, just on this simple function. - Started to wonder if Python its PyPy is so optimized that without any effort, your even faster then D. What other D idiomatic functions are slow? I am not criticizing your article Jon, just mentioning how i felt when reading it yesterday. It felt like the solution was overly complex to find and required too much deep D knowledge. Going to read the ycombinator comments now. Off-topic: Yesterday i was struggling with split but for a whole different reason. Take in account that i am new at D. Needed to split a string. Simple right? Search Google for "split string dlang". Get on the https://dlang.org/phobos/std_string.html page. After seeing the splitLines and start experimenting with it. Half a hour later i realize that the wrong function was used and needed to import std.array split function. Call it a issue with the documentation or my own stupidity. But the fact that Split was only listed as a imported function, in this mass of text, totally send me on the wrong direction. As stated above, i expected split to be part of the std.string, because i am manipulating a string, not that i needed to import std.array what is the end result. I simply find the documentation confusing with the wall of text. When i search for string split, you expect to arrive on the string.split page. Not only that, the split example are using split as a separate keyword, when i was looking for variable.split(). Veteran D programmers are probably going to laughing at me for this but one does feel a bit salty after that.
Silicon Valley D Meetup - May 25, 2017 - "Trip reports: DConf 2017 and C++Now 2017"
We have guests Martin Nowak, Dentcho Bankov, and Georgi Dimitrov in person: https://www.meetup.com/D-Lang-Silicon-Valley/events/240129190/ Ali
