SeasonalEnnui

If you buy the UK 1.8-metre Power Adapter Extension Cable, this has a metal ground pin that grounds through the metal clip on the power brick. I switched all my MacBook & iPad chargers to this, no more earth leakage sensation from metal casing.

I tried it out, fetching i8 arrays from a localhost server, sending to webgpu and rendering the waveform. Wow, faster than I expected, 2 billion points/sec.

I had a look, that certainly looks like part of the solution, now I need to get that array buffer from my backend into the browser runtime transferable object.

Yeah I agree, I'd like to get an idea of the order-of-magnitude of difference between the two approaches by trying it out but realistically I don't think there's an easy way to get a i16 raw array into the browser runtime with minimal overhead (WebRTC maybe?)

What's the best way to get all those points from a backend into the frontend webgpu compute shader?

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.

I've done both, I prefer embedded web views:

- 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.

It's a huge leap forwards from those days.

- 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.

Yes! I’m glad to see this pointed out - when working on UIs, I regularly move them between 3 monitors with varying resolution & DPI. 4k @ 200%, 2K at 125%, and 2K at 100%. This reveals not only design issues but application stack issues with DPI support.

The thing I enjoy most about 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.

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.

Yes, totally agree. The 2nd thing I found it great for was to explain errors, it either finds the exact solution, or sparked a thought that lead to the answer.

Good blog post, I recognise much of that.

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.

Mode Control Panel? I'm not sure about "eating" the world but certainly used worldwide by aircraft.

Anecdotally I've noticed a lot of acronyms from science/technology being reused in the context of LLMs, what a curious phenomenon.

I really like this. Did you investigate the options regarding CO2 sensors? I'm interested to know if you compared SCD30 to SCD41? The dual-channel design of SCD30 is supposed to offer lower drift and longer stability compared to the SCD41 (which claims to need taking outside once a week). That's the deal on paper, I'm wondering if you got any real data on this.

This SDK update moving the RP2040 baseline to 200MHz is very welcome for the projects where you can't have an egregious overclock over manufacturer approved spec.

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.