Tim Bray’s response to the suggestion of analysis for the Wide Finder Results is “Are you kidding me!?!? Getouttahere. Maybe someday.”
I’m only barely braver.
People hours are more expensive than computer hours. Tim includes the lines of code metric, and the average elapsed wall-clock for each implementation. Let’s use division!
| Name | Language | Elapsed | LoC | LoC per Elapsed | Model |
|---|---|---|---|---|---|
| clv5 | Gawk | 46.73 | 24 | 0.51 | Serial |
| wf_p | Ruby | 50.16 | 39 | 0.78 | Map-Reduce |
| wf-2 | Python | 41.04 | 38 | 0.93 | Map-Reduce |
| wf-Heikkinen | OCaml | 49.69 | 110 | 2.21 | Serial |
| wf-Fernandez | OCaml | 39.17 | 124 | 3.17 | Serial |
| tbray5 | Erlang | 20.74 | 76 | 3.66 | Message Passing |
| tbray9(128) | Erlang | 21.58 | 119 | 5.51 | Message Passing |
| wf-block | OCaml | 18.99 | 144 | 7.58 | Serial |
| wf-6(2) | Python | 16.91 | 137 | 8.1 | Scatter-Gather |
Let’s assume less lines of code = easier to understand. Let’s also assume that parallel processing concepts are hard to learn.
Then it seems Map-Reduce models are maturing well. Thank Google for popularizing that.
Odd, though. Erlang’s model of message passing is older. But, I hear there are weaknesses in its standard library?
Leave a Reply