Performances of FreeBSD versus Raspbian on Raspberry PI3b ?

Hello,

I have two RPI3B+ with same SD card, both are installed and ready.
There is not much differences considering performances between FreeBSD versus Raspbian based on usage of shell (without looking for scientific, elaborated method of perfs comparison).

The console usage (pkg, mutt, mc, ... ) is readily as fast on both machines. No differences.

However, for X11, I have impression that things are a bit different.

If you have more impressions about the topic raspbian vs freebsd perfs., please leave a short note/post.

You are welcome.
 
I tried it a long time ago but I noticed FreeBSD to be quite a bit slower.

I tried to install xorg via pkg add but it took so long I powered off half way through.

I don't know if disk access was the bottleneck or if SMP was lacking etc. but its good to hear that things might have gotten a bit better though :)
 
I haven't tested FreeBSD on RPI boards, but have tested it on a BBB a few years ago.
Back then I used ubench or unixbench, compiled the same sources with the same compiler on both systems (gcc x.y.z) with the same compiler flags.
What I found was that it was quite a lot slower than a Debian image. Also, the board ran a lot hotter and consumed more power.

I suggest doing the same, testing out with a benchmark program to see where the difference lies. Of course, if it's GUI related it might be a GPU driver issue, so you'll have to run a graphical benchmark as well.
 
powerd(8) is your friend in this case.
I thought that too, but it didn't work out that way. Can't say what the issue was though, I never investigated. Not saying it's still the case either (but I haven't tested recently).
If I find the time I'm going to see if the same issue still persists.
What could be the possible reason?Software for hardware / Kernel of FreeBSD?
Everything from this line on is speculation of reasons that could explain this, so don't take it as fact.
It might be that:
  • Clang's ARM support isn't as good as GCC's (for kernel and userland compilation)
  • The benchmark program is written with linux-isms (unlikely for ubench though)
  • CPU support isn't as complete as it is on Linux. e.g. Linux's AM3358 (the processor on the BBB) support is written by TI itself.
  • ARM Kernel code is better/more performant on Linux than it is on FreeBSD. I wouldn't be surprised if that were the case since the kernel is probably heavily optimized by Android people.
  • and much more that I didn't think of :)
 
I thought that too, but it didn't work out that way. Can't say what the issue was though, I never investigated. Not saying it's still the case either (but I haven't tested recently).
If I find the time I'm going to see if the same issue still persists.

Everything from this line on is speculation of reasons that could explain this, so don't take it as fact.
It might be that:
  • Clang's ARM support isn't as good as GCC's (for kernel and userland compilation)
  • The benchmark program is written with linux-isms (unlikely for ubench though)
  • CPU support isn't as complete as it is on Linux. e.g. Linux's AM3358 (the processor on the BBB) support is written by TI itself.
  • ARM Kernel code is better/more performant on Linux than it is on FreeBSD. I wouldn't be surprised if that were the case since the kernel is probably heavily optimized by Android people.
  • and much more that I didn't think of :)

In all cases, by definition, clang and gcc are less ideal ;)

So actually kernel of FreeBSD would be issue.

Actually, I am not so sure that kernel for x86 is that good either.

I see however good perfs on Apple(s) and PS4 ;)


CPU support is actually a drawback there, surely.
 
Back
Top