Hacker News

https://github.com/google/highway

> constrain the length to the maximum vector size supported by the lowest platform you want to support or you lose the portability and actually end up with code that performs much worse than the scalar alternative on some platforms.

Or, put a dynamic factor into your vector size and design everything around it. Such that every platforms can plug in their own factor and _scale_ the size of vectors. This is basically what LLVM IR does for SVE and RVV: `<vscale x 4 x i32>` where vscale is the said dynamic factor. Though the exact value of vscale is only known during runtime, it doesn't matter -- we still can design compiler optimizations and lowering around it. The generated binaries can then be portable across platforms with different vscale values.

Write it once with N errors, not N*M errors :)

You probably weren't looking for a tutorial about SIMD, but just in case you were interested, Mitchell [0] did one recently that got on HN [1]

[0] Mitchell Hashimoto: "Everyone Should Know SIMD" https://mitchellh.com/writing/everyone-should-know-simd

[1] https://news.ycombinator.com/item?id=49010648

Even with languages that adopt ways to manually write SIMD, it’s mostly left to library maintainers rather than application developers.

I work for a C++ timeseries database startup that leverages SIMD about as much as we possibly can, and except for some extremely rare places we just use libraries.

With AI I'm pretty sure SIMD will be easier to integrate when necessary.

Does matlab these days do stuff like JIT operator fusing to avoid memory roundtrips and take advantage of FMAs?

Julia does that too.

It's been discussed for a long time, and the related proposals were heavily upvoted, including various older proposals.

As I understand it, part of the reason it took a while is that the core Go team was generally of the opinion that doing user-facing SIMD APIs the right way was to design a high-level, cross-platform API that would stand the test of time, and that was then punted a few times given its complexity and need to do other things.

Part of what helped the current approach take off was switching to a philosophy of designing a lower-level architecture-dependent API first (the 'simd/archsimd' package), and then later doing a higher-level portable API (the 'simd' package, which is topic of this blog post).

That two-level approach I think also gave some additional freedom for the design and implementation of the friendlier / high-level 'simd' package, including because the lower-level 'simd/archsimd' package is available for people who need or want to drop down.

It's a nice design.

> But you also went 13 years without generics

Go shipped with generics (aka bounded parametric polymorphism), but only for built-in types: slices, arrays, and maps. That, with subtyping via interfaces, handled most demand for generics. The most common pain point was custom containers.

Go was first released in November 2009. Russ Cox posted "The Generic Dilemma" [1] in December 2009. The comments show the generics debate raging from the earliest days.

As a fun side note, I forgot I posted a comment on that post pointing to Ada's generics. I was in college, and Ada was our intro language.

[1]: https://research.swtch.com/generic

> the designers didn't want that complexity inside Go.

Yes, with some nuance. Go's goal of writing server programs didn't require the type-system complexity and run-time hit of user-defined generics. [2]

> Go was intended as a language for writing server programs [...] Polymorphic programming did not seem essential [...] so was initially left out for simplicity. > > Generics are convenient but they come at a cost in complexity in the type system and run-time. It took a while to develop a design that we believe gives value proportionate to the complexity.

[2]: https://go.dev/doc/faq#beginning_generics

Out of curiosity, I collected all proposals for Go's journey to generics. https://gist.github.com/jschaf/eaa7aff1af14ea7276a18a1b7370d...

Some of the concerns around generics and why it took so long were for the users as well. One of the biggest draws to Go has always been that you get the performance of a compiled language and yet compile times are so low that it can feel like you're developing with an interpreted language. The design of generics needed to maintain the compile time advantage or else it wouldn't feel like Go any more.

That's not what "memory safe" means. "Memory safe" is a term of art meaning "not susceptible to memory corruption exploits", like stack and heap overflows, UAFs, and type confusion. Last I checked, there are essentially no non-contrived memory corruption exploits for Go programs; the best you get are people demonstrating register control on contrived programs.

The definition I'm giving is the same as the ISRG's definition at MemorySafety.org. It's the thing everybody is talking about when they talk about memory safety.

The claim being made here is "big if true", because it would imply a lot more languages than Go "aren't memory safe", despite decades without memory corruption exploits.

Yeah, we get it, you performatively hate go.

Yes, but in practice they are extremely hard to exploit. It has been discussed extensively here on HN and in other forums.

That does not make sense to me. Go is memory-safe, but it does not guarantee data-race freedom.

So whats your point here? Haskell?

Go is broadly considered to be a memory safe language.

See for example comments from tptacek like:

https://news.ycombinator.com/item?id=43335748

https://news.ycombinator.com/item?id=46028232

https://news.ycombinator.com/item?id=44672371

(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)

You can write unsafe code in Go (import unsafe), but then, you can do the same in Rust. Unsafe code is not the default, and in day to day Go i rarely see the use of the unsafe package.

No idea why you're getting downvoted for true statement. Without a ? like in C# you're always at risk of a nil pointer being dereferenced

You're right. I could have but this encourages me to seriously consider it.

Question on the multi-versioning approach: if the AST rewrite creates N specialized copies of every function that mentions the SIMD types, doesn't binary size scale with the number of SIMD-touching functions? For generic hot paths (helpers parameterized over vector widths, instantiated across many call sites) that could multiply code size noticeably. Is there dedup when two specialized copies would be identical, or has anyone measured the binary-size cost on a real codebase?

its not limited but it has overhead because of the memory model of go doesnt match the C one so there has to be some sort of rerodering being done, that's what i understood atleast, and theres also the go concurrency

Wow, that second link does exactly what I do when I'm talking to people about skittle highlighting; demonstrating a skittle highlighted snippet of prose to show how absolutely harmful it is. I only started doing that maybe three years ago, so they've got me beat by 15 years or so! Glad I'm not alone on this crusade, at least. It is genuinely my belief that skittles have cost humankind millions of manhours of productivity, at least.

I like Linus's work, but that post smells of rotting strawmen. All the examples look manipulated into throwing the opposition under the bus.

Not convinced at all by these reasons. Rob Pike has long stepped down from the Go team so it shouldn't matter? This is a website not a language change.

One wonders why you wonder.

https://en.wikipedia.org/wiki/API

> API is indeed the correct word to describe a set of functions from a library (built-in or not).

Uncorroborated by WP, note.

> If you disagree perhaps you should share your preferred term here?

Library functions.