Is it worth pointing out that the compiler flags for the D program didn't use ldc's full optimisation settings?
Namely, link time optimisation (But not sure if that would have helped here or not), cross module inlining (Possibly the same as before, but I know that this inlines parts of the runtime (AA implementation) and -O3 (As opposed to -O).
Faster Command Line Tools in D
11–20 of 100 posts
Re: Faster Command Line Tools in D
#12I'd be interested in the perspective of someone who has used both GO and Dlang for command line tools. Go is my current tool for this, but D seems like a much nicer, less dogmatic language.
The answer is fairly obvious: dlang is a nicer language, by design. Go isn't meant to be particularly impressive on the language design/innovation front.
Honest question: what strengths does Go have over D? I became very proficient at Go several years ago, and was reading about D for hours and hours last night, and it looks like D is overall a much better language.
Re: Faster Command Line Tools in D
#13This article is trash. They start with "obvious" python at 12s, run it with pypy instead for 3s, and then rewrite and optimize a D version from 3s to 1s w/o attempting any further optimization of the python version(!?!). In my opinion omit all of the discussion on python and just talk about "how to optimize a D program" b/c that's what this article is.
I think this repository gives more context as to why they might of showed some Python code:
https://github.com/eBay/tsv-utils-dlang
They basically explored new languages to rewrite some perl script in and liked D enough to shift over. They have other tooling in other languages, my guess is they'll unify a good amount of it in D. Disclaimer: this is based on my own assumption that they like D so much they want to just use it all over. It wouldn't surprise me to see this confirmed by an eBay employee. Although seeing as he wrote TSV Utilities, it really wouldn't surprise me if he wants to rewrite all in-house tooling he uses in D as the repository states.
Re: Faster Command Line Tools in D
#14well, i dont think that there were much doubt that d was faster than python i am thought impressed with how fast pypy did
I wonder how fast you can make the Python version. For example by not producing intermediate lists with .split(delim). This produced a significant speedup in the D version, it should do the same in the Python version.
collections.Counter in Python 2.7 was not speedy at the time of this Stack Overflow question:
https://stackoverflow.com/questions/27801945/surprising-resu...
Another likely optimization would be to use the csv module (which would parse the rows in C).
Re: Faster Command Line Tools in D
#15TL;DR: D is faster than Python.
Re: Faster Command Line Tools in D
#16Earlier quoted context omitted.
The answer is fairly obvious: dlang is a nicer language, by design. Go isn't meant to be particularly impressive on the language design/innovation front.
Honest question: what strengths does Go have over D? I became very proficient at Go several years ago, and was reading about D for hours and hours last night, and it looks like D is overall a much better language.
This is sort of what I'm wondering. Are the compile times as good as Go? Is the GC as good as Go, or do you end up having to do manual management to get similar performance to Go? What is the build tool ecosystem like (I found Go's to be the one part of Go that was not easy to pick up quickly)?
Re: Faster Command Line Tools in D
#17TL;DR: D is faster than Python.
Is it though? Un-optimized Python vs. a D script iterated on 5 times?
Certainly eye-catching but I wouldn't call it conclusive.
Re: Faster Command Line Tools in D
#18Re: Faster Command Line Tools in D
#19This article is trash. They start with "obvious" python at 12s, run it with pypy instead for 3s, and then rewrite and optimize a D version from 3s to 1s w/o attempting any further optimization of the python version(!?!). In my opinion omit all of the discussion on python and just talk about "how to optimize a D program" b/c that's what this article is.
You're right... naive PyPy and D are in the same ballpark. Then they only optimized the D version.
Re: Faster Command Line Tools in D
#20> (Note: For brevity, error handling is largely omitted from programs shown.) I found this article interesting but to be honest I hate it when people do this. Usually it is the real-world considerations and error handling that cause the code to cease being an elegant demo and look more like the same stuff everyone else writes.
Yeah code only dealing with elegant cases is elegant. News at 20.
Sometimes I wonder if software should error first, then when you bounded the failure space, you iterate on the success space as you see fit.