I've always wanted it to work this way. However it'd only work if you had a case with the magnetic cover to turn on the device. Otherwise someone would pick up their un-cased kindle with the page lock screen, start reading, and then get confused when they tried to turn the page and nothing happened — the device would still be off!

Good suggestion. Updated.

Good job. This caught my eye. I don't think the visual even needs much of an explanation, I can see what it's doing.

Thanks CyberDildoNics!

I'm interested to try, but don't get what that early access signup is about. Where is the email address going to show up? Can I use a temp mail?

I used the term "early access" when I should've used "private beta". The sign up is just for me to have an email addresses to send the private beta when the next update goes out, and I'll follow up for feedback. Nothing sinister is happening.

> to send the private beta when the next update goes out

Meaning I only can try the software after sign up, or did I miss the obvious repo link?

What language is this project written in, what build system does it use itself?

I just don't feel comfortable pasting my email address into a Google site. I can use a temp mail, but I will loose access to it in a few minutes/hours, so I don't know if that would annoy you.

What kind of times do you expect in the form, serial or parallel build time? What kind of file do you want to be modified. When I modify main.c, basically nothing gets rebuild, when I modify the central header file, it will be like a total rebuild. Can you clarify that in the form?

You can make an email you don't care about with protonmail, I recommend them cause they don't require you to enter an existing email address or a phone number when signing up.

I use whatever the equivalent is on that OS.

I'll be sending out the a macOS version to another wave of beta users after I fix an outstanding issue, if you sign up (at bottom of article) and mention this comment I can make sure you're in that wave.

Thanks. Signed up

Thank you! Yeah it can be used for any type of program, but I haven't been able to think of anything besides compilation that creates enough processes to be interesting. I'm open to ideas!

Video encoding and 3-D rendering are a couple that come to mind; I'd think they'd launch quite a few.

This looks like a really cool tool!

Just as a random example in the area, I had a project where I transformed every frame in a video, using a custom binary, before encoding them back to the video.

Hundreds of thousands of processes were normal.

OP Here. Thats an interesting idea. What The Fork knows all the commands run, and every path they read/write, so I should be able to make it estimate build time just by looking at what files were touched.

(OP here) Thanks!

My call with the Mozilla engineer was cut short, so we didn't have time to go into detail about what he found, I want to look into it myself.

Hello, I am the engineer in question. I am not actually super familiar with the details of the build system, but from when I saw, the main issues were:

- Lots of constant-time slowness at the beginning and end of the build

- Dubious parallelism, especially with unified builds

- Cargo being Cargo

Overall it mostly looks like a soup of `make` calls with no particular rhyme or reason. It's a far cry from the ninja example the OP showed in his post.

What `cargo being cargo` problems are you having?

1. The image at the top of the article makes it clear the segments aren't contiguous

2. iterating a 4 billion item segmented array would have 26 cache misses. Not a big deal.

I think the parent poster meant that a compiler might have a hard time understanding when sa_get(..., i) and sa_get(..., i+1) actually access contiguous memory locations, and will thus stop applying nice optimizations. Conversely, accessing a[i] for all 4 billion items of a regular array will be optimized to specialized instructions, not excluding SIMD or SWAR.

If I understand the article right, if this is an issue I think you can get around it by redesigning your approach to first retrieve the segment and segment length directly and then access the data within the segment like a traditional array, instead of going through your accessor functions every time. Should help with the problem a bit.

feel free to call it a "levelwise-allocated pile"