OpenBSD on Zenbleed • Hacker News Board

Re: OpenBSD on Zenbleed

#61

Post by hulitu » Tue, Jul 25, 2023, 4:05 PM UTC

ksec wrote: post #51

pdw wrote: post #3

Earlier quoted context omitted.

OpenBSD is not a fast system.

It used to be very slow ( or for some people fast enough ). But I wonder if that is still the case in 2023. This reminded me nagging phoronix to do another BSD reviews.

Depends on the architecture. On Sparcstation 20 circa 2000 OpenBSD was way faster than linux.

Re: OpenBSD on Zenbleed

#62

Post by matrix12 » Tue, Jul 25, 2023, 4:17 PM UTC

stevefan1999 wrote: post #18

matrix12 wrote: post #10

Earlier quoted context omitted.

Rust would love a talk with you...

I am a Rust guy, sorry.

Then you know Performance and Safety are not mutually exclusive.

Re: OpenBSD on Zenbleed

#63

Post by mrweasel » Tue, Jul 25, 2023, 7:10 PM UTC

tiffanyh wrote: post #57

mrweasel wrote: post #54

Earlier quoted context omitted.

> That OpenBSD just never got around to implementing AVX more thoroughly? Realistically that probably the right answer, they didn't have the developers nor did they priorities going in and just retro-actively fitting AVX in everywhere where it could potentially help with speed. The "smart choice" deliberately or not, is to not just jump onto everything new but adopt new features at a slower pace. My reaction was towa…

FWIW, my original post was mainly fueled by the fact that AVX was announced in 2008 and in both Intel & AMD chips by 2011. So it’s not like AVX is a “new” development. It’s 12-years old. (Not directing these comments at you. Just trying to expanded upon what drove my original post) https://en.m.wikipedia.org/wiki/Advanced_Vector_Extensions

That's honestly also a little older than I expected. It is a little weird I'll admit. It would be interesting to know if the slow adoption in OpenBSD is deliberate or done on purpose.

Re: OpenBSD on Zenbleed

#64

Post by stevefan1999 » Sat, Jul 29, 2023, 5:31 PM UTC

matrix12 wrote: post #62

stevefan1999 wrote: post #18

Earlier quoted context omitted.

I am a Rust guy, sorry.

Then you know Performance and Safety are not mutually exclusive.

They still are mutually exclusive. For example, you don't have built-in bitfields in Rust. You have fat objects that requires heap memory to work properly. Still, there are many kinds of metrics for performance. While the execution performance of Rust is fantastic that it reaches the figures on the ballpark with C and C++, and sometimes even better due to fundamental stuff like borrow rules and strong alias rules and immutability propagation, the developmental performance of Rust is abysmal at best :[ Bunch of concepts to understand, generic and trait bounds, async and Poll, crate orphan rules, ownership and lifetime and although my prior C++17 knowledge did help, but consider in the picture for a complete newbie, they are no easy feat to challenge.

The compilation performance of Rust is also unsatisfying too with right even though it got the package manager right. I remember sitting 15 minutes to build my first ESP32 RISC-V firmware in Rust and still have to wait 2 to 3 minutes for consecutive debug builds. All of that on a Ryzen 3700X, maybe machine issue idk.