Hacker Newsnew | past | comments | ask | show | jobs | submit | physicsguy's commentslogin

People were definitely asking for it.

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.


Layered API design is a great way to resolve ergonomics/performance tradeoffs.

Oh this is great, it was one of my biggest bugbears about Go since you almost always have to link C/C++ code to get the appropriate performance.

The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.


FWIW, there is some pretty substantial autovectorization work that is already in-flight for the Go compiler.

There's a CL stack here:

https://go.dev/cl/791740

It's hard to make predictions with an open source project, but my personal guess is some flavor of it will land (including it is already demonstrating good results without an enormous level of code complexity in the compiler and without overly slowing down compile speeds), but I guess we'll see.

It's being driven by an external contributor who has landed some good changes in the past to the Go compiler. (I think the autovectorization work might be part of their PhD or other academic research, but not sure.)


As a first step, it might be possible to write a linter rule that rewrites suitable numeric loops to SIMD. There are already rules to rewrite several loop types, so that should be doable.

The poor Assembler and the unsafe package forgotten in the corner.

While reaching out to CGO is the easier way, it doesn't mean it is the only tool available in Go.


> I live in a European country, where the phone company hasn't bothered to come remove the old unused copper phone lines in the last 5 years. Thousands of dollars worth of cables running past my house alone, and no one has bothered to go strip it in the night and sell it

Isn't that because they're still flat out on rolling fibre out? There's not that many telecoms engineers and if they spend tons of time removing the old, that slows down the new.


> Isn't that because they're still flat out on rolling fibre out?

Spain's rollout is up in the last few percentage points (>95%) of fibre coverage, in this particular region we reached saturation of the entire rural area 5 years ago.

Plenty of time for those disconnected copper cables to go walkabout if anyone were so inclined. Realistically, in a region where the population skews older and most everyone owns property, it's probably not worth the risk to fence it


We're still quite some way off that in the UK. Copper lines still working though due to shut down by next year I think. Lots of older people with no internet left in the lurch with phone lines with that of course.

I ran into the exact same wall when doing some SIMD + OpenMP optimisations.

Me: "Parallelise this loop without changing the results."

AI: "I can't do that, because of floating point accumulation."

Me: "So spin out a temporary fixed-length array, accumulate into that thread-locally, and then do an ordered summation of that at the end."

AI: "Oh, you're right!"

It's a fantastic tool for automating the implementation grind, but you still have to hand-feed it the strategy. I guess it will get there at some point.


That is true if you're using them as chatbots but for something behind a product it's largely OK as long as it meets the requirements.

I haven’t used open weight models yet, but this would match my intuition given I haven’t experienced a noticeable increase in code quality this calendar year. If open weight models are already on par with January frontier models that’s already enough for me to automate most of the manual parts of my work (I.e. not “architecting”).

And once frontier models can architect (turn business requirements into engineered systems) then I guess no one needs a job because that’s the digital singularity.


I'm finding that executives at work are generating AI slop and sending it at each other and teams that are then meant to digest it, without any critical thought. Often these are sloppy and contain broad mistakes that aren't relevant to our company's setup.

Only about 15 years later than it should have been introduced

Hi, Fabricio from AWS here. I hear you and it's something we've heard for years and am glad is finally being rolled out. If you have more thoughts on the new experience, feel free to share :D

I wouldn’t personally refer anyone I’ve not worked with. What’s the point? Someone being smart isn’t enough, they have to be actually sane and normal to work with. You can be friends with people you wouldn’t want to work with. Someone I’ve not met would be a totally unknown quantity.

I would refer someone I'm friends with if I know them well, understand what they would be like to work with, and understand the job/company well enough.

After all, I've lived with some people that I never worked with. Surely I know them well enough to recommend them for jobs, even though I have not ever worked alongside them.


I wouldn't trust a referral from someone I don't work with either. Your reputation is on the line, if you don't have one to lose why should anyone care.

In the UK I had a panel interview with 4 people, in person. But for international students who often brought their own funding sponsored by their government that didn’t happen.

That's an interesting wrinkle. If anything, externally funded international students seem like exactly the case where you'd still want the interview, since the funding answers "who pays for this?" but not "does this person have the background and understanding to do the work?"

I recently tried to get Claude to use Codegraph in a repo rather than using grep/find all the time but I found it didn't follow instructions a lot of the time. I tried putting in a pre-tool call hook and explciitly blocking find/grep, and instead rather than using Codegraph like it was told, it started using Python to find/search instead.


I have a hard time to divert “rm” to “trash” too


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: