I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one compiler's behavior and performance. Curious how this same test would behave once clang ships C++26 reflection.
It should be possible to have the PPU emulation capture all of the final register state per pixel (or scanline if accuracy isn't paramount) and have the GPU render each pixel using only that state, doing the layer blending, color math, and mode 7 calculations as necessary. Based on MVG's video breaking down the draw commands performed it doesn't look like that's how Super ZSNES have implemented their PPU - it seems to render tile by tile for BGs (and OBJ?) and line by line for mode 7. That'll be a bit inaccurate but it's likely necessary to implement some of their visual enhancement tricks.
Very cool! Checking out the Van Gogh painting in the viewer I can just barely see the depth of the brush strokes. Shame you can't look 90 degrees off axis to see the protrusion effect with the bulky outer frame in the way.
Very cool idea, but unfortunately the browser doesn't allow users to select which channel of their audio interface to use as input. So unless you're plugging your guitar into input 1 this doesn't work out. I have my microphone in input 1 and my guitar in input 2.
Are we assuming that "testing" is limited to only exercising the single-threaded behavior of a function? I'm curious how others approach effective testing of multi-threaded behavior.
Sanitization of data is such a strange security practice to me. It feels like any sort of vulnerability sensitive to data sanitization just boils down to a failure to properly encode or escape data into a target language that is susceptible to injection attacks e.g. SQL, HTML, javascript. Is there a real-world scenario where data sanitization is required where proper data encoding/escaping is not the better solution?
I think cognitive load has a lot more to do with the paradigm that the code is written in than any particular type of author's contribution to the code. For instance, the object-oriented paradigm by design increases cognitive load by encouraging breaking up otherwise straightforward logic into multiple interfaces, classes, and methods.
I've built a VST3 plug-in that simulates a Mesa Boogie Mark IIC+ preamp purely from the circuit.
The approach doesn't seem popular for professional plug-ins likely because it wasn't viable for real time until modern CPU enhancements became available. Performance scales with frequency of the input which is interesting and seems to be a consequence of using an iterative solver on a system of equations and using the previous sample's state vector as a guess for the current sample.
On my MacBook M3 it requires between 50 to 70% of a single core to produce a 2x oversampled output at 48000Hz. This can be scaled back by reducing the solution tolerance bounds and get down near 25% with minimal quality loss.
The obvious solution to me is to implement streaming/buffered processing of the content while downloading it instead of downloading the entire content into memory to be processed in a single contiguous byte[].
Buffered IO would have the CPU processing acting as a natural backpressure mechanism to prevent downloading too much content and also prevent unbounded memory allocation. Each CPU worker only needs to allocate a single small buffer for what it processes and it can refill that same buffer with the next IO request. Your memory usage becomes entirely predictable and will only scale with how many concurrent threads you can actually execute at once.
Also, no matter how you artificially rate limit the virtual thread scheduling (e.g. via semaphore), if you still insist on downloading the entire content into memory before starting processing then obviously you cannot process any single piece of content larger than what can fit into available memory at any given time.
I fixed a recent Y38 bug in some classic ASP code. The bug was nothing more than a simple `Date() + 5000` computation (adding 5000 days to the current date) as a sort of expiry date applied to something; I don't recall the exact details. VB6 did not take kindly to computing any date value beyond the Y38 max and threw an error. In practice this error ended up denying service to everyone even though the Y38 max date was 14 years in the future. You never know what little bugs like that are lurking in such legacy code.
On mobile I couldn't make a mistake. Every tap was charitably interpreted as the correct action to take on that square whether it be flagging a mine or revealing empty space / numbers. I clicked every tile and never exploded a mine.