6 ms·

I had to smile, as this thread is a microcosm of programming language stereotypes: with the python programmers tweaking code to get that extra 10% (nobody menti

I had to smile, as this thread is a microcosm of programming language stereotypes: with the python programmers tweaking code to get that extra 10% (nobody mentioned pypy..), someone trying to get javascript to work in a long running program, of course a rust implementation that isn't working well just yet (but we're all rooting for it.. set that compiler flag and rerun).. One comment about perl (turns into a one liner..). Nobody bothering to redo the Lua, Ruby and PHP. And for fun somebody throws down some fortran. what is going on with the m4 code?

jrimbault 9y ago
One night for fun, I wrote a fizzbuzz (without actual printing) in almost all of the languages mentionned here (except fortran), and benchmarked it with 10000 executions each.
- sevensor 9y ago
  And? Don't leave us hanging! Who wins at FizzBuzz? Also, surely 10k is just getting started?
  - jrimbault 9y ago
    10k was just sufficient to get actual differences. Of course I went crazy and did something like 10M, but waiting 10 minutes to get the same relative differences didn't bring anything. Remember this is without any printing: C is fast, if I remember correctly it was something like 0.015 or 0.03s while at the other end of the spectrum I had to wait 0.1s for JavaScript. C results varied from simple to double because of the OS I guess because it was so quick. It isn't a really significant benchmark though, for any language. It was one of those nights. Ah, and I remember a large difference between go run and go install.
    - sevensor 9y ago
      > It isn't a really significant benchmark though, for any language Sure, but it's reassuring to know that the universe is still sane, C is still faster than Javascript. Thanks for expanding on your comment!
      - jrimbault 9y ago
        Found the old sources, reran the benchmark for 100 times each. c 0.062s f90 0.080s go 0.108s awk 0.116s lua 0.117s rs 0.140s sh 0.434s php 0.886s scm 1.323s py 2.965s rb 3.738s js 5.411s My memory was bad, I also added fortran for the occasion.
        sevensor 9y ago
        Thanks for digging those up!
- simon83 9y ago
  Pretty sure none of your implementations will beat the FizzBuzzEnterpriseEdition [1]. [1]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - jrimbault 9y ago
    That link is always marked as already visited and yet I always forget it exists.
  - midwestcode 9y ago
    this is hilarious on so many levels...
idsout 9y ago
Within this thread someone pointed out https://github.com/cgati/yes/blob/master/src/main.rs https://github.com/cgati/yes/blob/master/src/main.rs. This rust version gives me 7.81GiB/s versus GNU's 7.54GiB/s.
- acomjean 9y ago
  Yeah. Rust came through (woot!), though thats some verbose low level code fu with cows? (use std::borrow::Cow;) ?! (I don't know rust, its on my list.. Especially with cow borrowing! They clearly are my people). I noticed they added a comparison of Rust to gnu yes on the thread. They only got: 2.17GiB/s but on a slower machine.. (2.04 for the GNU)
  - eridius 9y ago
    Cow means "clone on write". It's a generic wrapper for types that have both a borrowed version and an owned version. For example, `Cow<'a, str>` can hold either an `&'a str` (a borrowed string) or a `String` (an owned string), and a `Cow<'a, [u8]>` can hold a `&'a [u8]` (a slice of bytes) or a `Vec<u8>` (an owned vector of bytes). In that Rust program, Cow is being used here so if the user provides an argument it ends up with an owned vector that contains that argument plus a newline, otherwise it ends up with a borrowed byte slice that contains "y\n". That said, there's not really a whole lot of point to using Cow here since allocation is a one-time cost and nobody cares if yes starts up a few microseconds slower, but the usage of Cow is limited to just a couple of lines so it's not really complicating anything (the actual write() call just ends up taking a &[u8] byte slice, so the usage of Cow is strictly limited to main()).
    - steveklabnik 9y ago
      tine, tiny note: it means Clone on write, not Copy, and it's String not Str.
      - eridius 9y ago
        Oops, typo. I've updated my comment accordingly, thanks. Also, I didn't realize it was Clone-on-write. Interesting, and the documentation does confirm this. I say "interesting" because the actual operation involved is `to_owned()`, not `clone()`, seeing as how `clone()` on a `&str` just gives you the same `&str` back.

jrimbault 9y ago

One night for fun, I wrote a fizzbuzz (without actual printing) in almost all of the languages mentionned here (except fortran), and benchmarked it with 10000 executions each.

sevensor 9y ago
And? Don't leave us hanging! Who wins at FizzBuzz? Also, surely 10k is just getting started?
- jrimbault 9y ago
  10k was just sufficient to get actual differences. Of course I went crazy and did something like 10M, but waiting 10 minutes to get the same relative differences didn't bring anything. Remember this is without any printing: C is fast, if I remember correctly it was something like 0.015 or 0.03s while at the other end of the spectrum I had to wait 0.1s for JavaScript. C results varied from simple to double because of the OS I guess because it was so quick. It isn't a really significant benchmark though, for any language. It was one of those nights. Ah, and I remember a large difference between go run and go install.
  - sevensor 9y ago
    > It isn't a really significant benchmark though, for any language Sure, but it's reassuring to know that the universe is still sane, C is still faster than Javascript. Thanks for expanding on your comment!
    - jrimbault 9y ago
      Found the old sources, reran the benchmark for 100 times each. c 0.062s f90 0.080s go 0.108s awk 0.116s lua 0.117s rs 0.140s sh 0.434s php 0.886s scm 1.323s py 2.965s rb 3.738s js 5.411s My memory was bad, I also added fortran for the occasion.
      - sevensor 9y ago
        Thanks for digging those up!
simon83 9y ago
Pretty sure none of your implementations will beat the FizzBuzzEnterpriseEdition [1]. [1]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- jrimbault 9y ago
  That link is always marked as already visited and yet I always forget it exists.
- midwestcode 9y ago
  this is hilarious on so many levels...

idsout 9y ago

Within this thread someone pointed out https://github.com/cgati/yes/blob/master/src/main.rs https://github.com/cgati/yes/blob/master/src/main.rs. This rust version gives me 7.81GiB/s versus GNU's 7.54GiB/s.

acomjean 9y ago
Yeah. Rust came through (woot!), though thats some verbose low level code fu with cows? (use std::borrow::Cow;) ?! (I don't know rust, its on my list.. Especially with cow borrowing! They clearly are my people). I noticed they added a comparison of Rust to gnu yes on the thread. They only got: 2.17GiB/s but on a slower machine.. (2.04 for the GNU)
- eridius 9y ago
  Cow means "clone on write". It's a generic wrapper for types that have both a borrowed version and an owned version. For example, `Cow<'a, str>` can hold either an `&'a str` (a borrowed string) or a `String` (an owned string), and a `Cow<'a, [u8]>` can hold a `&'a [u8]` (a slice of bytes) or a `Vec<u8>` (an owned vector of bytes). In that Rust program, Cow is being used here so if the user provides an argument it ends up with an owned vector that contains that argument plus a newline, otherwise it ends up with a borrowed byte slice that contains "y\n". That said, there's not really a whole lot of point to using Cow here since allocation is a one-time cost and nobody cares if yes starts up a few microseconds slower, but the usage of Cow is limited to just a couple of lines so it's not really complicating anything (the actual write() call just ends up taking a &[u8] byte slice, so the usage of Cow is strictly limited to main()).
  - steveklabnik 9y ago
    tine, tiny note: it means Clone on write, not Copy, and it's String not Str.
    - eridius 9y ago
      Oops, typo. I've updated my comment accordingly, thanks. Also, I didn't realize it was Clone-on-write. Interesting, and the documentation does confirm this. I say "interesting" because the actual operation involved is `to_owned()`, not `clone()`, seeing as how `clone()` on a `&str` just gives you the same `&str` back.