Live data from Hacker News

Wc in D: 712 Characters Without a Single Branch

dlang.org

41–50 of 89 posts

Re: Wc in D: 712 Characters Without a Single Branch

#41
post #14

Perhaps I'm just being pedantic or maybe I am misunderstanding. The author claims to be IO bound toward the end. But they are comparing to two versions that are faster. It is my understanding that IO-bound means that the IO subsystem is the thing which limits run time of the program. But the author clearly demonstrates that the IO subsystem of their machine is capable of supporting faster wc binaries. So what am I mi…

People incorrectly use the term “IO bound” or “bottlenecked by IO” without thinking about it all the time.

Like they will talk about how their web app is IO bound because the DB query takes 1 second while their slow ruby code only takes 300ms after it gets the result from the DB back.

Well guess what, making the web app twice as fast still cuts 150ms off the response time, and it still means you can do twice as many requests on the same server.

In order to be able to say that something is “bound” by something else, you have to have some kind of concurrency going on. One task has to be doing all it’s work in the time that it’s waiting for more work to arrive from another.

Re: Wc in D: 712 Characters Without a Single Branch

#42

Earlier quoted context omitted.

slightly related, does embedding arithmetic in mov instructions go faster than explicit ALU operations ?

Depending on the arithmetic, it seems that yes it can! I've noticed gcc using LEA instructions for arithmetic of the form (x * a + b), where 'a' and 'b' fit with the instruction.

Using LEA (load effective address) for calculation seems to be pretty common in most programs for both gcc and llvm. You basically get smaller code, and it used to schedule them better across more execution ports. Not sure if the CPU can fuse the ADD+MUL now.

Re: Wc in D: 712 Characters Without a Single Branch

#43

I'm wavering between D and Rust for which one could be used as a better alternative to C++. (Though I don't see C++ getting replaced anytime soon.) Even if Rust is getting most of the attention, D also seems to be a strong candidate.

Rust is definitely more difficult but it has it benefits, I guess? For me as a Python guy D was just easier both concept wise and syntax wise. I could write a relatively complex algorithm after 2 weeks of reading a D programming book with just standard ops. And it was definitely faster. Maybe not as fast as C but I felt efficient. Personally, I liked that D does pray FP like Scala while also being a multiparadigm lan…

*does not pray FP

Re: Wc in D: 712 Characters Without a Single Branch

#44

Earlier quoted context omitted.

D is an amazing language. But what eventually put me off is the lack of documentation for installing and linking libraries in the compilers.

This is a bit perplexing. Libraries don't need to be installed, you simply put them in a directory, add a path to it in the command to the compiler, and list the library on the command to the compiler. Just as you would for C and C++. Other languages may need libraries to be installed, but not D.

Just like in Java

Re: Wc in D: 712 Characters Without a Single Branch

#45
post #6

I find D easier to grok coming from a Java/Python background.

My only issue is that it's far more complicated than Java and for a language that fills that same niche it's hard for me to justify putting my resources into learning it even though I do like a lot of the features.

D is designed to be able to do 100% of everything C++ can do. "Alias this" is intended to replace C++'s implicit conversion through multiple inheritance pattern and its "function that returns a value with implicit conversion" pattern. "Mixin templates" are a way to do CRTP.

Re: Wc in D: 712 Characters Without a Single Branch

#46
post #14

Perhaps I'm just being pedantic or maybe I am misunderstanding. The author claims to be IO bound toward the end. But they are comparing to two versions that are faster. It is my understanding that IO-bound means that the IO subsystem is the thing which limits run time of the program. But the author clearly demonstrates that the IO subsystem of their machine is capable of supporting faster wc binaries. So what am I mi…

> So what am I missing here?

The Haskell program is multi-threaded (I don't know about wc's official implementation, but I assume it is as well), while the D program is single-threaded.

Re: Wc in D: 712 Characters Without a Single Branch

#47
I believe I'm missing something here or my day was too long, but in Clojure this can be squeezed in 13 lines and 435 characters keeping things fairly readable (for Clojure & Lisp developers ;)).

    (defn wc [^String file]
      (with-open [rdr (clojure.java.io/reader file)]
        (apply (partial printf "%d %d %d\n")
               (reduce
                (fn [[nl nw nb] ^String ln]
                  (let [words (count (.split ln "[ ]+"))
                        bytes (alength (.getBytes ln "UTF-8"))]
                    [(inc nl) (+ nw words) (+ nb bytes)]))
                [0 0 0]
                (line-seq rdr)))))
    
    (defn -main [& args]
      (wc (first args)))

I haven't tested how fast it is, but startup time can be optimized by compiling it with GraalVM.

Re: Wc in D: 712 Characters Without a Single Branch

#48

Earlier quoted context omitted.

In what way is more complicated than Java?

well, java isn't really complicated. it's just verbose. but my understanding is that d has many of the features of c and modern cpp. that alone makes it more complicated than java...

You can also write verbose code in D. The language doesn't prohibit it.

Re: Wc in D: 712 Characters Without a Single Branch

#50
post #14

Perhaps I'm just being pedantic or maybe I am misunderstanding. The author claims to be IO bound toward the end. But they are comparing to two versions that are faster. It is my understanding that IO-bound means that the IO subsystem is the thing which limits run time of the program. But the author clearly demonstrates that the IO subsystem of their machine is capable of supporting faster wc binaries. So what am I mi…

> So what am I missing here? The Haskell program is multi-threaded (I don't know about wc's official implementation, but I assume it is as well), while the D program is single-threaded.

So, that sounds like it's CPU bound then...
Post reply on HN