rsaxvc

I meant memcpy()-like

If I'm reading your comment and the blog post correctly, the compiler would need a memory like access on every multibyte pointer argument where the compiler cannot otherwise prove alignment. Is that correct?

As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...

About four years after he reviewed a series of changes me and two coworkers put together to rework this handling.

Humans are incompatible with nearly every gas at 13000feet/400 atm and beyond. Nobody has done it.

Cabin pressurization might get you to ~50atm, but that's around the extreme limit, so regardless of cabin pressurization the hull has to handle most of it.

Here's hoping it has and they can be found quickly.

This is the multi-threaded compiler: https://github.com/rsaxvc/tcc-swarm

With the multi-threaded tcc above it scales about as well as multiprocess. With mainline it doesn't scale well at all.

So far I haven't gotten around to reusing anything across libtcc handles/instances, but would eventually like to share mmap()'d headers across instances, as well as cache include paths, and take invocation arguments through stdin one compilation unit per line.

Edit: By small pixels I mean a low pixel aspect ratio(area of lit pixel vs total area per pixel). If you consider this as a DSP problem(instead of a time series problem, a brightness value over distance or angle), there's effectively no reconstruction low pass filter. You can think of small lit pixel area with larger distance between like zero padding. This can make some things appear sharper, but by doing so it'll appear less like the image source wants it to.

Mainline has a lock so that all backends can use global variables, but only one instance can do codegen at a time.

It was a giant refactoring Especially fun was when multiple compilation units used the same static variable name, but it all worked in the end.

From: https://www.forbes.com/sites/katherinehamilton/2023/06/19/he...

"Pogue also shows the vessel uses construction pipes as ballast."

I'm having trouble finding the interview video, but dropping ballast involves the crew and passengers rocking the vessel to drop the pipes off the side.

Started with a pair of loops for each image, foreach col, foreach row.

Problem: C++ 2d arrays are row-col not col-row.

Halfway through multi-threaded performance was much worse than single threaded.

Eventually we switched to row-col processing, single-threaded was fast enough, back to two loops per image.

The Chinese one is effectively a warped coordinate system, see GCJ02: https://en.m.wikipedia.org/wiki/Restrictions_on_geographic_d...

Dunno about power consumption.

When I switched to an ISP with local peering, ping times between my home and my server downtown dropped to a few milliseconds. It's like being on my LAN.

If this is still an issue for AT&T, traceroute+reverse DNS of each router may indicate it.

This poor peering isn't directly a throughput problem, but really increases the chance of being routed through a congested link, which you could sometimes guestimate from ping times and peeringdb.

This may have some amount of survivorship bias in that remediated interference won't count toward those failures.