I'm afraid I still don't understand. One factor is having fewer features and not looking for obsolete files, that I can understand. I guess the other thing is using better rules to figure out when a file truly need to be rebuilt?
To be honest, it's not clear to me why other systems are not faster. Ninja is relatively straightforward but also not too clever.
Now that I think about it, I did write more about some of the performance stuff we did here: https://aosabook.org/en/posa/ninja.html Looking back over that, I guess we did do some lower-level optimization work. I think a lot of it was just coming at it from a performance mindset.
I might be missing your sarcasm, but this is a common approach for large scale builds. Virtual filesystems are used to provide a pre-computed tree hash as a xattr. In a more typical case, you can read the git tree hash.
Not sure it was meant as sarcasm really. I just think so many build (and other) problems could have been avoided it a file hash was available on every file by default.
In the current POSIX paradigm yes, it would be expensive. But if the hash was defined as the hash of fixed blocks, it wouldn't be expensive. The raciness depends, a lot, on the semantics we would define. (In the context of a build system, it's no different than that the file could get a new mtime after we read the mtime.)
I had a similar experience implementing simd instructions in my emulator, where I needed to break apart a 64-bit value into four eight-bit values, do an operation on each value, then pack it back together. My first implementation did it with all the bit shifts you’d expect, but my second one used two helpers to unpack into an array, map on the array to a second array, and pack the array again. The optimized output was basically the same.
I don't know the technical details, but the kernel docs say "It exists because implementation in user-space, using existing tools, cannot match Windows performance while offering accurate semantics."
https://docs.kernel.org/userspace-api/ntsync.html
If you're interested in technical notes on how the WoW64 thing works, I dug into Wine and implemented a similar thing in my (far inferior) emulator and wrote about it here, including some links to some Wine resources: https://neugierig.org/software/blog/2023/08/x86-x64-aarch64....
Hey thanks! I don't mean to hijack this great wine news with my own project, but since you asked, the top of the post has links to more. I will fix the link.
By the way, I did a deeper dive on the problem of serializing objects across the Rust/JS boundary, noticed the approach used by serde wasn’t great for performance, and explored improving it here: https://neugierig.org/software/blog/2024/04/rust-wasm-to-js....
The Tl;Dr here is that the cost to them of operating the free tier is lower than what they estimate their Customer Acquisition Cost would be without a free tier, so the free tier generates better leads/conversions to their paid products at a lower cost than traditional sales and marketing.
As long as these economics continue to hold they'd be stupid to discontinue the free tier.
But it isn't 'economics' as there is no actual data or science here, just a wild guess about what customer acquisition might currently cost. All it takes to rug pull is some exec speculating that 'the economics' have changed.
Acquisition cost can definitely be calculated. I'm pretty sure they know how many customers do convert into paying users from their free tier and how much does it cost to get them through other channels
Say 5% of the free tier users converts to a paying customer within 5 years. And user growth is constant. Then over time, you will get a much larger free tier user base, compared to your paying customers (in absolute numbers).
At some point, it must become tempting to charge all free tier users a little bit to continue, because the group got so big, so there is a lot that can be earned there.
And they have become quite infamous for having aggressive sales tactics for anyone going over their internal metrics for the free tier (still under the public metrics for free).
Also the fact it means companies can run a demo themselves without having to contact sales, after they see it works on their system they pay to add all the users they will need.
Products that have no free tier where everything is behind a scheduled sales demo present a huge barrier to entry.
All it takes is for the decision-maker who gets the credit for cutting costs by removing the free tier to be a different person from the one who gets the blame for higher customer acquisition costs. Not saying it'll happen, just that it being a bad move isn't a guarantee.
Most of my known userbase hangs out in the decomp.me Discord server. Each project also tends to have its own dedicated Discord server.
The Windows decompilation community is far more fragmented than the console one, as it hasn't coalesced around a common set of tools like splat or decomp-toolkit.
Exact same for me! Just ten minutes ago my son opened his Xmas present, his first box of TubeLox. My expectations and hopes are high but he is currently distracted by the flashier presents.
He'll probably find it himself, but if he doesn't, just build something cool in front of him. He may not have unlocked all the possibilities in his brain yet.
reply