1. 13
  1.  

    1. 4

      So he did figure it out and it’s quite a weird bug — zstd’s time measurement uses some… interesting C99 and C11 functions rather than good old POSIX clock_gettime, and FreeBSD’s included zstd build uses C99 and that one reports wrong stuff (I mean there’s even a comment: “clock_t measurements can be wrong when using multi-threading”).

      1. 1

        That’s about performance running in a VM, not on actual hardware, right?

        1. 2

          But the actual numbers there aren’t the important thing; the important part is that Ubuntu and FreeBSD take the same time in Guzik’s configuration (with FreeBSD being slightly faster), but zstd on Ubuntu reports 60.1 MB/s while zstd on FreeBSD reports 3.97 MB/s. The point is that the throughput numbers from zstd, which were used in the benchmark suite, can’t be trusted.

          1. 1

            Workload and operating system performance under virtualization isn’t the native performance multiplied by a constant factor. Everything from io to scheduling will behave differently. It’s not surprising that the results are vastly different.

            1. 4

              You’re completely missing the point. The point is that those two runs take the same amount of time, but report vastly different throughputs. If they took about the same time, the throughputs should be about the same too for the same file.

      2. 6

        Please be aware, that Phoronix benchmark need to be taken with a bigger than usual grain of salt.

        1. 4

          8 years ago I tried to use the phoronix test suite in some QA environment at some cloud startup I was working at that time. It simply did not work at all. I came to the conclusion that this is one mans stuff that works for him, but nothing that can be re-used.

        2. 4

          Why do websites like this insist on making me click through seven pages when most of them are just images?

          1. 3

            More impressions = more ads

          2. 4

            These tests look interesting, but they are just a bunch of random stuff, essentially. I looked at the lame encoding benchmark, and it shows that BSD is slower. More interesting result would be to answer why it is slower.

            1. 2

              Kinda big on the tags which I usually dislike, but who leaves a change to use the DragonflyBSD tag untouched? Probably performance is just enough

              1. 2

                It’s been a long time since performance was the reason to choose a BSD.

                I haven’t been paying much attention to the BSD world for ~20yrs. What’s DragonFly all about? In many benchmarks it seemed to be closer to Linux performance than BSD performance.

                1. 2

                  DRAGONFLY is about as fast SMP as possible. And they have two cool filesystems that, once the second is matured, could end up widely ported.

                  1. 1

                    It looks like betting against Moore’s law has paid off…

                    1. 1

                      Why’s that? We’re still rapidly increasing the transistor count per area. Betting on SMT is betting on Moore’s law to keep increasing our core counts.

                  2. 2

                    Quoting Wikipedia:

                    Dillon started DragonFly in the belief that the techniques adopted for threading and symmetric multiprocessing in FreeBSD 5[4] would lead to poor performance and maintenance problems. He sought to correct these anticipated problems within the FreeBSD project.[5] Due to conflicts with other FreeBSD developers over the implementation of his ideas,[6] his ability to directly change the codebase was eventually revoked.

                    DFBSD disagreed with the others and started his own project. I haven’t used it myself but it’s on my list to try at some point due to reasons.