290 karma · joined February 5, 2020
There doesn't seem to be a communication mechanism that has minimal memcopy or no serialization/deserialization, the security boundary makes this difficult.
I have a backend array of 10M i16 points, I want to get this into the frontend (with scale & offset data provided via side channel to the compute shader).
As it stands, I currently process on the backend and send the frontend a bitmap or simplified SVG. I'm curious to know about the opposite approach.
- All the work is done in my high performance backend, where I joyfully optimise my hot loops to the assembly level. The web view is a thin layer on top.
- HTML and CSS is a joy to work with in comparison to many UI toolkits. LLMs are better at supporting a web stack.
- The UI zooms/scales, and is accessible with screen readers (looking at you, imgui).
- Cross platform with low effort.
IMO you have to be extremely careful not to pull in a whole frontend stack. Stay as vanilla as possible, maybe alpine.js or tailwind, and I've got hot reload set up so the developer productivity loop is tight when editing the view.
- Works on linux/macos, x86/ARM64.
- The mature frameworks (e.g. ASP.NET with razor pages) are great. Microsoft still have the same issue of pushing new and different ways of doing web things, but you do see a lot of that on the web platform in general.
- CLI workflow for compilation/build/deployment is now there and works smoothly. VS Code extensions for a bit of intellisense without requiring a full IDE (if that's the way you work).
The thing I enjoy most about modern C# is the depth/levels of progressive enhancement you can do. Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List<T>, foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions.
Depending on your requirements you can then progressively enhance the memory churn, or the processing speed:
for(;;), async, LINQ, T[], ArrayPool<T>, Span<T>, NativeMemory.Alloc, Parallel.For, Vector<T>, Vector256<T>, System.Runtime.Intrinsics.
Eventually getting to a point where it's nearly the same as the best C code you could write, with no memory churn (or stop-the-world GC), and SIMD over all CPU cores for blisteringly fast performance, whilst keeping the all/most of the safety.
Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List<T>, foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions.
Depending on your requirements you can then progressively enhance the memory churn, or the processing speed:
for(;;), async, LINQ, T[], ArrayPool<T>, Span<T>, NativeMemory.Alloc, Parallel.For, Vector<T>, Vector256<T>, System.Runtime.Intrinsics.
Eventually getting to a point where it's nearly the same as the best C code you could write, with no memory churn (or stop-the-world GC), and SIMD over all CPU cores for blisteringly fast performance, whilst keeping the all/most of the safety.
I think these new language features have the same virtue - I can opt into them later, and intellisense/analysers will optionally make me aware that they exist.
The positions of both evangelists and luddites seems mad to me, there's too much emotion involved in those positions for what amounts to another tool in the toolbox that should only be used in appropriate situations.
Anecdotally I've noticed a lot of acronyms from science/technology being reused in the context of LLMs, what a curious phenomenon.
For hobby projects, I've achieved significant overclocks on both RP2040 and RP2350. I suspect this is mostly due to the use of TSMC's 40NM 40LP process which is a smaller process node than most microcontrollers use.
That's largely my concern with Dear ImGui et al. It's okay to have it as a debug environment in a game, it's not okay to have it as an application. The lead developer agrees: "I do know that Dear ImGui unfortunately does not align with requirements of accessible software. It was designed as a technical/debug tooling software to be used as an overlay over 3d/graphics applications which themselves tends to have little to no accessibility features. It's not really my fault that people have started using it for desktop-ey applications." (GH issue 7892)
In other words: 1. The RP1 (implemented on TSMC 40LP) contains all the power hungry/high bandwidth IO that is difficult to do on smaller process nodes. This allows the main processor to be moved to smaller nodes or even a different vendor/architecture in future boards. Easier to target better power efficiency in the future. 2. Going forwards, the IO feature set will now be consistent and reliable, by reusing RP1. It is no longer a requirement to try to get these peripherals on the main processor.
To any KiCad dev reading this - thank you.
Install .NET 8, and create a new C# Console application. From .NET 6 onwards, it uses the new “top level statements” style which is effectively like the blank slate of a script file. The barrier to entry has never been lower. (https://learn.microsoft.com/en-us/dotnet/core/tutorials/top-...)
This lets you take advantage of a really healthy toolchain/package manager ecosystem.
You can take this a step further by using VS Code with the Polyglot Notebooks extension to get a Jupyter-style experience with C# code. (https://marketplace.visualstudio.com/items?itemName=ms-dotne...)