Although this project is undoubtedly very cool, and maybe simplifies build processes by having a single binary, is there any other reason to use it? How does it compare in terms of performance, static linkability, standards conformance, etc. with musl and glibc? I’m curious because I’m picking a libc at the moment for my project.
Looking at thin matrix SVD, it appears much faster than everyone else. I’m curious what it’s doing differently at a high level and if there’s any tradeoff in accuracy. I also wonder how it compares to MKL, which is typically the winner in all these benchmarks on Intel.
Why can’t hash based partitioning systems just store the full hash with the key for fast rehashing if the number of buckets needs to change, or else recompute the hash?
Since a lot of people are discussing Apple’s plans to replace C/C++ in performance critical areas, I’m curious to discuss it. How do they plan to make Swift actually match those languages in speed? Last I checked, classes, along with fundamental struct types like Array and String, use atomic reference counting. Do they plan to ban all those types in these systems? Are there any highly performance sensitive and C/C++ Apple systems (not just libraries) that have been rewritten in Swift without a drop in speed? The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.
Why has it taken so much longer for CPython to get a JIT than, say, PyPy? I would imagine the latter has far less engineering effort and funding put into it.
I don't know much about CentOS, but I've seen a lot of anger about the end of CentOS Linux, regardless of CentOS stream, Rocky, etc. . Can someone explain the history of this, why CentOS is going away, why it's being replaced with these new alternatives, and why many seem quite mad about it? Just curious to understand the state of it.
The real slowdown of Objective-C method calls is at startup where the caches haven't been filled. Pure Objective-C apps typically spend 5-15% of startup time on objc_msgSend
Why would they use SipHash at all? That’s a significantly slower hash algo than, say, wyhash, and any additional DOS protection SipHash might have (assuming it does) seems irrelevant for this use case
I’ve been bitten enough by Objective-C++ compiler bugs (Apple’s attempt at mixing Objective-C and C++), as well as bugs in Apple’s code in the Swift ecosystem, not to trust the stability here for at least several years. I also don’t see how this is much better than just creating a C or ObjC wrapper around a C++ library, rather than needing to keep C++‘s complicated language features, and Swift’s interop with it, in my head as I use the library. Were there people clamoring for this? I can’t really see the point.
Typically, the difference between equivalent JSON and Protobuf payloads that have been gzipped is quite small. It can even be that the gzipped Protobuf payload is larger than gzipped JSON one. Granted, there's less data to decompress out of it, which may mean a faster decompression stage, but I'm not sure that's a bottleneck in the first place.
So, do they not compress requests between microservices? Otherwise, how did they see such a reduction?
Dynamic programming problems are banned at a number of companies, and with good reason. Candidates ability to do well on them is largely a function of how much they’ve practiced those problems. I’ve never needed to do dynamic programming with caching of recursive overlapping sub problems ever, and only learned it recently during interview practice.