Odd that c# has a better stable SIMD story than Rust! It has both generic vector types across a range of sizes and a good set of intrinsics across most of the common instruction sets
Why would that be odd? C# is an older and mature language backed by a corporation, while Rust is younger and has been run by a small group of volunteers for years now.
> hile Rust is younger and has been run by a small group of volunteers for years now
I thought Rust was getting financial support from Google, Microsoft and Mozilla? Or was the Rust Foundation just a convenient way for Mozilla to fire a large amount of developers and we are actually rapidly approaching the OpenSSL Heartbleed state. Where everyone is happily building on a secure foundation that is maintained by a half dead intern when he isn't busy begging for scraps on the street?
Mozilla hasn’t supported development on the Rust project for about 5 years now, since laying off all the developers working on it in August 2020.
Since then several Rust project developers did find full time jobs in companies like Amazon, Meta etc. But corporate interest ebbs and flows. For example Huawei employed a couple of engineers to improve the compiler for several years but they lost interest a couple of months ago.
The Rust Foundation is powered by donations, but a lot of its expenses went on funding infrastructure, security, legal expenses. But this problem of funding the maintainers of the project is on their radar. Yesterday they started an initiative to fund raise for the Maintainers Fund, with the money going straight to maintainers who aren’t being paid by their employer to do it full time. (https://rustfoundation.org/media/announcing-the-rust-foundat...)
It is atypical for otherwise mainly high-level languages to have this. Moreover, C# and F# get this through completely independent work runtime libraries and RyuJIT, not by being lazy and having LLVM do everything which is also why Go and Java are so so far behind in this area.
C# portable SIMD is very nice indeed, but it's also not usable without unsafety. On the other hand, Rust compiler (LLVM) has a fairly competent autovectorizer, so you may be able to simply write loops the right way instead of the fancy API.
Unsafety means different things. In C#, SIMD is possible via `ref`s, which maintains GC safety (no GC holes), but removes bounds safety (array length check). The API is called appropriately Vector.LoadUnsafe
Having worked in HPC a fair bit I'm not a fan of autovectorization. I prefer the compiled code's performance to be "unsuprising" based on the source and to use vectors etc where I know it's needed. I think in general it's better to have linting that points out performance issues (e.g. lift this outside the loop) rather than have compilers do it automatically and make things less predictable
You can write good autovectorized code in Rust today, but only for integers. Since Rust lacks --ffast-math, the results on most fp code are disappointing.
You are not "forced" into unsafe APIs with Vector<T>/Vector128/256/512<T>. While it is a nice improvement and helps with achieving completely optimal compiler output, you can use it without unsafe. For example, ZLinq even offers .AsVectorizable LINQ-style API, where you pass lambdas which handle vectors and scalars separately. It the user code cannot go out of bounds and the resulting logic even goes through (inlined later by JIT) delegates, yet still offers a massive speed-up (https://github.com/Cysharp/ZLinq?tab=readme-ov-file#vectoriz...).
Yeah, golang is a particular nightmare for SIMD. You have to write plan 9 assembly, look up what they renamed every instruction to, and then sometimes find that the compiler doesn't actually support that instruction, even though it's part of an ISA they broadly support. Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. So without compiler support I don't believe there's any way to do something like intrinsics even. Fortunately compiler support for intrinsics seems to be on its way! https://github.com/golang/go/issues/73787
> Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it.
Even if you had access to the register convention (which you kind of do), would it be of any benefit? The registers in question are general-purpose registers, not vector registers.
You're both stating things that are a bit beside the point.
Pure Go code uses registers to pass function arguments whenever possible. Large structs and/or numerous arguments can still spill onto the stack, though.
FFI (cgo) uses whatever the platform's calling convention requires. These conventions also usually favor registers.
Go has its own assembly language, which is neither of those two things. Go assembly technically supports two ABIs, one called "ABI0" and the other called "ABIInternal" [1]. The former passes all arguments on the stack and is stable while the latter passes some arguments through registers but is unstable and subject to change. Accordingly, people writing Go code outside of the Go toolchain almost always use ABI0, so that the code keeps working even when new versions of Go are released.
To be fair, Java's lack of support seems to have more to do with them needing to fix the whole primitive vs object mess rather than a lack of effort. It sounds like the Vector API will be stabilized shortly after they figure that out, but who knows how long it will take.
If anything, the Mono runtime is what prevents heavier (ab)use of SIMD types in the standard library, or at least it causes additional required effort to make it not regress in performance since it's nowhere near as capable as CoreCLR.
As C# SIMD had a such a long head start in Mono (your linked MS blog post has their timeling starting only in 2014) it should probably get a bit more credit.
It was after all enabling games to use SIMD with C# (with MonoGame and Unity), even if their interface wasn't the winning one in the end.
Kafka is great tech, never sure why people have an issue with it. Would I use it all the time? No, but where it's useful, it's really useful, and opens up whole patterns that are hard to implement other ways
Managed hosting is expensive to operate and self-managing kafka is a job in of itself. At my last employer they were spending six figures to run three low volume clusters before I did some work to get them off some enterprise features, which halved the cost, but it was still at least 5x the cost of running a mainstream queue. Don't use kafka if you just need queuing.
Cheapest MSK cluster is $100 a month and can easily run a dev/uat cluster with thousands of messages a second. They go up from there but we've made a lot of use of these and they are pretty useful
I've basically never had a problem with MSK brokers. The issue has usually been "why are we rebalancing?" and "why aren't we consuming?", i.e. client problems.
It's not the dev box with zero integrations/storage that's expensive. AWS was quoting us similar numbers for MSK. Part of the issue is that modern kafka has become synonymous with Confluent, and once you buy into those features, it is very difficult to go back. If you're already on AWS and just need queuing, start with SQS.
Kafka also provides early architectural scaffolding for multiple teams to build in parallel with predictable outcomes (in addition to the categorical answers to hard/error-prone patterns). It’s been adopted in principle by the services on, and is offered turn-key by, all the major cloud providers.
Personally I’d expect some kind of internal interface to abstract away and develop reusable components for such an external dependency, which readily enables having relational data stores mirroring the brokers functionality. Handy for testing and some specific local scenarios, and those database backed stores can easily pull from the main cluster(s) later to mirror data as needed.
JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection
To re-optimize compiled code blocks isn't without effort. Google has publicly spoken about AutoFDO and Propeller [0], after Meta had open sourced BOLT [1] in 2021.
AutoFDO has since been ported to Android and adopted by Yandex [3].
Hard disagree. Many newer game system emulators (32-bit and up) rely on JIT or "dynarecs" to get playable speeds, and they pretty much all use high performance compiled languages already. They often double the performance over their interpreter or more.
Sure, but the relevant comparison isn't between languages: it's between a state-of-the-art JIT implementation of one language and a likewise-state-of-the-art AOT implementation of the same language. Unfortunately there aren't many examples of this; most languages have a preferred implementation strategy that receives much more effort than the other one.
I almost did a PhD with David but ended up working at Transversal instead, which was a company he co-founded to do some interesting work in the search engine space! It's what got me into software development as a career so I'm always grateful to him
The Fens in East Anglia in the UK has a lot of interesting pumping tech. The latest can do 100m3/s (https://www.edie.net/st-germans-pumping-station-keeps-fens-f...). If all the pumps failed there would be hundreds of km2 underwater within days or weeks
I think it's more that western cultural cliches become invisible to western audiences rather than moving on. E.g. the "superhero" is definitely a western cliche. "A lone operative defies the rules to do the right thing because might is right if you're right. Individual exceptionalism triumphing etc". Somewhat shallowly examined in some films but still turns up all over the place.
We have https://www.myenergi.com/ for our car charger and it seems to be able to integrate batteries, charging and panels like you suggest, only you have to go all in. We have parts of it and are tempted to use more, but the lock-in angle is a bit off-putting
Yeah I have a Zappi, but as you know its got no local API, and it doesn't like getting warm. However it _cant_ control my battery directly, because its made by tesla. (I mean thats also my fault....)
I have also heard that if you go all in it works much better. It does have the nice feature of diverting to other devices instead of the grid, and giving priority to certain devices.
reply