Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Command Line Tools in D

dlang.org

Post reply on HN
Print view View original

41–50 of 100 posts

Re: Faster Command Line Tools in D

#41

Post by dom0 »

qznc wrote: post #27
ramses0 wrote: post #8

This 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.

In general, Python is slow (compared to C or whatever) because of excessive memory allocation and overuse of hash maps. PyPy probably manages to optimize the hash map/method call lookups for these small programs, which explains the speedups. Removing memory allocations is still hard. The D language provides finer mechanisms to control memory and data structures. This makes the language larger, but enables you to opti…

> In general, Python is slow (compared to C or whatever) because of excessive memory allocation and overuse of hash maps.

Python is a highly dynamic language with an API (towards both Python and C) that is very invasive. These two things, taken together, make optimizing the interpreter extremely difficult, because practically all of it can be modified or introspected. CPython being implemented largely as a hashtable-interpreter is only one facet to its performance.

Perhaps a talk recommendation: https://www.youtube.com/watch?v=qCGofLIzX6g&list=PLRdS-n5seL...

Re: Faster Command Line Tools in D

#42

Post by AceJohnny2 »

agumonkey wrote: post #20
KirinDave wrote: post #4

> (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.

You've just defined Test-Driven-Development.

Re: Faster Command Line Tools in D

#43

Post by milcron »

maxxxxx wrote: post #38
maxpert wrote: post #30

Makes me wonder, how many people actually use D-lang in production. Specifically with HTTP stack what kind of numbers/performance benchmarks we are looking at? Other than toy projects is there a company out there running D on massive scale (millions per day)?

D would make a good case study to look at why some technologies find widespread use whereas others don't. I don't understand why it never took over from C++.

D's standard library uses garbage collection.

Re: Faster Command Line Tools in D

#44

Post by cwyers »

maxxxxx wrote: post #38
maxpert wrote: post #30

Makes me wonder, how many people actually use D-lang in production. Specifically with HTTP stack what kind of numbers/performance benchmarks we are looking at? Other than toy projects is there a company out there running D on massive scale (millions per day)?

D would make a good case study to look at why some technologies find widespread use whereas others don't. I don't understand why it never took over from C++.

C++ was deliberately backwards compatible with C. D was not backwards compatible with C or C++.

Re: Faster Command Line Tools in D

#45

Post by throwaway7645 »

ramses0 wrote: post #8

This 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 was excited with D's performance before I realized it is barely faster than PyPy. Almost not much of a point unless it saves in other ways like concurrency and parallelism?

Re: Faster Command Line Tools in D

#46

Post by yumaikas »

penpapersw wrote: post #12
mhh__ wrote: post #5

Earlier 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.

The other strength that Go has over D is that Go, being used by Googlers, is much more likely to have better networking support. Two examples come to mind: HTTP2 support (Go was used for either the first or second implementation of that and has standard library support), and TLS cryptography, where Go has it's own suite written by experts, where a good portion of the non Microsoft ecosystem relies on OpenSSL. For web/app servers, CLI tools, and networking stuff, I think Go has a strong set of options. Go also has a nice cross platform story for that subset of programs (networking and CLI tools).

That set of good internet sensibilities is what attracted me to Go in the first place, and why I still like working in it in my spare time. If D has a similarly strong story in that area, I'd love to know about it.

Re: Faster Command Line Tools in D

#47

Post by Cyph0n »

yumaikas wrote: post #46
penpapersw wrote: post #12

Earlier quoted context omitted.

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.

The other strength that Go has over D is that Go, being used by Googlers, is much more likely to have better networking support. Two examples come to mind: HTTP2 support (Go was used for either the first or second implementation of that and has standard library support), and TLS cryptography, where Go has it's own suite written by experts, where a good portion of the non Microsoft ecosystem relies on OpenSSL. For web…

In other words, it's because Go has the backing of a huge software company, while D doesn't.

Re: Faster Command Line Tools in D

#48

Post by btbytes »

Mister_Snuggles wrote: post #22
penpapersw wrote: post #12

Earlier quoted context omitted.

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.

I haven't actually used Go, but one of its big strengths seems to be that you get a binary with no dependencies (beyond libc I believe) at the end of it. You can just deploy it through a file copy and have it just work.

So can you with D.

With D, in addition, you can link against C shared libraries (dynamic linking) AND you can write standalone libraries in D that even C can link against (see Mir/betterC).

AFAIK, you can do neither of these in Go.

Re: Faster Command Line Tools in D

#49

Post by aisofteng »

mhh__ wrote: post #21
penpapersw wrote: post #12

Earlier quoted context omitted.

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.

I can only give my own biased opinion: Go's only advantage is it's commercial adoption e.g. builtin in support in AppEngine and co. I am not referring to it's ecosystem: While gofix and friends are very good, D has similar tools available + the usual bells and whistles for IDEs. By chance, I found (while looking for a rob pike quote) this article critiquing Go's design: It uses D to demonstrate it's arguments. http:/…

The first code comparison in that article compares Go error handling with doing a `catch Exception` in D. I don't find that a fair comparison; `catch Exception` for a block of code that can fail in different ways at different points is a bad practice.

Re: Faster Command Line Tools in D

#50

Post by throwaway7645 »

gshulegaard wrote: post #17
faragon wrote: post #15

TL;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.

No, it isn't debatable which is generally faster (D), but I was impressed that you could just prototype in Python (probably significantly faster than D) and run it through PyPy when you're done and get 90% of the performance of D. Of course Python has the bloat of the interpreter and Jitter, while D is just a binary. Point is I was expecting more speed from D. I'm curious if this is just luck or the two would be neck and neck on a range of tests?
Post reply on HN