Intel Still Has The Upperhand On BSD Support - Core i9 10980XE Benchmarks With DragonFlyBSD + FreeBSD

[jaypatelani]

aht0 you can use PkgSrc also which works across many platforms . Even NASA uses it with Linux

https://www.nas.nasa.gov/hecc/support/kb/using-software-packages-in-pkgsrc_493.html

[aht0]

Yeah, matter of preference. Since synth exists on DragonFly as well, I've become more used to using it.

[kylew77]

Unfortunately I am not aware of many BSD users being Phoronix Premium members, so testing is just as it comes about / time allows. FreeBSD and DragonFlyBSD are the BSDs I am most interested in so that is what they are tested with my limited time, but if premium members request NetBSD/OpenBSD, will work on adding them to the queue as it allows.

How hard is it to do testing with the Phoronix test suite and do you still accept guest articles like you used to? I have some spare time this Christmas season and could benchmark the latest NetBSD and OpenBSD releases for you.

[Michael]

How hard is it to do testing with the Phoronix test suite and do you still accept guest articles like you used to? I have some spare time this Christmas season and could benchmark the latest NetBSD and OpenBSD releases for you.

It's mostly:

<Install git and PHP CLI packages (not a web suite or the like) >
git clone https://github.com/phoronix-test-sui...nix-test-suite
cd phoronix-test-suite/
./phoronix-test-suite benchmark <whatever tests or results>
[Mostly sit back and watch]

On the likes of OpenBSD and NetBSD there may be not quite as much automation just when it comes to installing any test build dependencies, there is coverage of dependency installation using pkgsrc / pkg / ports / etc but most of my BSD testing is done on DragonFly/FreeBSD so any other caveats may lead to needing to manually install whatever build dependencies.

Yes, I always accept guest articles, thanks.

[torsionbar28]

If it wasn't for Ryzen they would still sell i5 with 4 cores and i7 with 4 cores + Hyperthreading.

Also all the BS about the "ultrabook" CPUs called i7 and i5 that are in fact mobile i3s with slightly better clock speed.

Not to mention that while AMD invented x86-64 and released Athlon64 and Opteron, Intel's answer to 64 bit computing was the Itanium.

[aht0]

Not to mention that while AMD invented x86-64 and released Athlon64 and Opteron, Intel's answer to 64 bit computing was the Itanium.

It wasn't so much "Intel's answer" as Intel's first attempt at 64bit. And as with "first attempts" it often happens, result wasn't all it could have been.
AMD64 came after Itanium and was technically more solid, in terms of performance and compatibility. Itanium was utter crap when it came to emulating 32-bit x86 and even 64-bit performance wasn't much (about one half of P4 on equal clocks).

AMD64 allowed smooth transition to 64-bit over following decades, Itanium did not. Intel understood early-on that AMD64 is technically better and implemented/licensed it in it's own x86 processors as well. Due enterprise contracts it also kept producing Itaniums on the side tho.

So by now, technically inferior solution (Itanium) has almost died out (last remaining extended Windows server support left for Itanium (Win2008 R2 server lineup) will end on Jan 14 2020 and Itanium 9700-series was the last planned production series - from Jan15 2020 onwards Itanium shall be nothing but another footnote in computer history).

[starshipeleven]

Not to mention that while AMD invented x86-64 and released Athlon64 and Opteron, Intel's answer to 64 bit computing was the Itanium.

That was technically better, but was not retrocompatible.

I wouldn't say this is a evil choice from Intel.

[aht0]

That was technically better, but was not retrocompatible.

I wouldn't say this is a evil choice from Intel.

Itanium could actually run x86 code, performance sucked bad tho.. it had like 1/10th of PIII IPC if I recall it right

Itanium and P4 were just dead ends for Intel. It had to build new uarch based on older Mobile PIII to get out of said holes.

[starshipeleven]

Itanium could actually run x86 code, performance sucked bad tho

ARM can also run x86 code with shit performance (with QEMU), does that mean anything about its value as an architecture? No it does not.

Intel weren't complete morons that couldn't figure out how to hack the x86 to go 64bit like AMD did.
They just didn't want to be stuck with a mediocre arch forever and saw the 64bit jump as a good point to let x86 die and try something better.

[k1e0x]

aht0

Wow, Synth looks pretty cool, I'd never head of it before. Thanks I'll check it out.

Those are some eye opening results, no mistake. Used to be FreeBSD was very hit or miss on performance. It's become far more consistent over the past year since the release of v R12.x

Now if only they had consistently easy to use packaging like Linux distros. Yes I know that's flame bait, but I really don't like ports as the whole concept is inconvenient for those that just want a working system, and their binary packages tend to not have features that I want or need in base packages and mixing the two can cause "issues".

And frankly the repackaged FreeBSD "distros" pretty much suck IMO.

I agree, former TrueOS kind of missed the mark but GhostBSD is meh, ok. It has some things I like but I find it a little unstable. I do like it, but I use vanilla.

I actually really like FreeBSD's pkg and ports.. tho they have issues. pkg isn't totally smart.. but it has pretty good features, a good syntax and it's not horribly slow like apt and portage. For ports.. it takes a while to get use to it.. and frontends exist but the main feature here is flexibility and control. FreeBSD also has a LOT of ports/packages.. I'm often surprised by a lot of major Linux distros how often they send you off to random unknown repo's for common stuff.

If I had to pick 3 good ones on Linux I would probably chose, Portage, Zypper and Apt.. they all suck but the rest suck harder.

What package managers do you like, or how would you like to see pkg improved?