vlovich123

10 ms·

61.
by vlovich123 1mo ago
Probably with an annotation around a NanBoxable(f64) type that tells it to do that. That being said, the optimization is complex that may be insufficient: > For my boxing scheme, I picked a bias value such that the lowest two bits end up
62.
by vlovich123 1mo ago
At what levels? There’s no guarantee that the default compression level is comparable. You have to normalize by time spent compressing.
63.
by vlovich123 1mo ago
Some people would like to keep running a system that’s connected to the internet that’s still receiving security updates. Running an outdated host isn’t the best idea.
64.
by vlovich123 1mo ago
Apple discontinues support for this HW, not Apple discontinues support for running Linux in a hypervisor.
65.
by vlovich123 1mo ago
CVEs are handed out like candy for non issues, the severity rating system isn’t a serious evaluation of the actual severity (eg a vulnerable function may not even be compiled in), the scoring is inconsistent and subjective and frequently in
66.
by vlovich123 1mo ago
CVE severity is a terrible way to do this. If you follow the cybersecurity space you should know why.
67.
by vlovich123 1mo ago
Given the likely length of the shortest possible proof, I feel like Fermat is 100% vindicated - the proof won’t fit in the margin. My strong hunch is that it was a joke - he knew how difficult the problem was and claiming he had a solution
68.
by vlovich123 2mo ago
That’s not what caching is for. Caching lets you resume with a pre computed KV cache saving you from having to ingest everything in the chat history as input on every single round trip. You still need caching regardless of SRAM or not as it
69.
by vlovich123 2mo ago
That’s not going to work for read ahead unless you’re really only requesting 1 page at a time which is terrible for performance across the board. That syscall will return EAGAIN if any data is missing to satisfy the read. Meaning if you i
70.
by vlovich123 2mo ago
Data is generally read more often than written and data is read in locally spatial way. That’s why having elements laid out next to one another is often more important than the algorithmic complexity of occasionally doing an O(n) or O(n log
71.
by vlovich123 2mo ago
That’s fair. I’m not saying x86 is a pig for interrupt latency. But M still isn’t a fair comparison. X86 runs general purpose OSes which like to do things like load balance interrupts (not that I’m convinced this is actually a good design)
72.
by vlovich123 2mo ago
But you’re also comparing dozens of cycles at 10mhz to 100ks at 5ghz. That’s probably comparable in terms of wall clock, no?
73.
by vlovich123 2mo ago
You're basically advocating for unscrambling the omelet to be easier. Should be obvious why it's harder to unmix than it is to mix.
74.
by vlovich123 2mo ago
Of course it is and there is. Generally DBMSs are not handling 1 request at a time. Indeed such a DBMS wouldn’t be taken seriously. All of them support running run multiple requests concurrently. This is where io_uring is really important b
75.
by vlovich123 2mo ago
You’ve misunderstood what they’re saying. Not that the benchmark is invalid, but that it’s an incomplete picture if your use case is a mixed set of applications where DB performance is not the only important thing. Hence the comment about m
76.
by vlovich123 2mo ago
That’s not the only case. A read call makes your thread unable to do anything for the duration of the read. Io_uring lets that same thread continue to handle other requests which themselves might generate more I/O that gets amortized.
77.
by vlovich123 2mo ago
> In part, this is because Fable 5.1 can now be used to discover software vulnerabilities—though not to develop exploits for them Generally once an exploit chain is described, developing the exploit is trivial. If you're so inclined
78.
by vlovich123 2mo ago
Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests because the I/O queue isn’t infinite. So both the Linux kernel and t
79.
by vlovich123 2mo ago
Doesn’t the Linux kernel automatically merge requests for contiguous regions into a single request? I’m not sure 16 read I/Os submitted to io_uring for a contiguous 64kib region will behave differently at the disk level than a single 6
80.
by vlovich123 2mo ago
Do this with io_uring with the preadv syscall. It’ll be the same or faster (faster only if you can do something else while waiting for I/O or you can submit multiple requests simultaneously - a single io_uring will be basically identic
81.
by vlovich123 2mo ago
Not sure what you mean. Nothing about preadv lets you indicate you only want to read what's already in the page cache. And io_uring and preadv aren't orthogonal - you can give io_uring a preadv op to do the scattered read instead
82.
by vlovich123 2mo ago
The other problem is that even if there were 200k such employees, there wouldn’t be enough power to go around to contain it and also their skill isn’t necessarily anything to do with IC talent.
83.
by vlovich123 2mo ago
You’re thinking of this as a primary driving vehicle. I’m thinking of it purely as a secondary commuter vehicle / renting when you need to do a longer trip. And you’ve wildly intentionally inflated your estimates precisely to make it s
84.
by vlovich123 2mo ago
This should be made structurally impossible through type safety rather relying on code review.
85.
by vlovich123 2mo ago
I’d be worried about the safety of driving a bike in wet weather. You’d have to make sure the brakes and tires are really rated for that kind of weather or you’re going to be in for a bad time.
86.
by vlovich123 2mo ago
From some parts of SF to SJ is about 42 miles. Thats a very long distance that you’re likely to get completely on solar. For that long of a commute you probably need a bigger battery but you could easily have most of your costs met for free
87.
by vlovich123 2mo ago
It’s fine to have multiple runtimes. There’s probably some additional performance overhead at the API boundary because you have to transfer the work to run on the other runtime but I haven’t benchmarked what that looks like. It’s probably o
88.
by vlovich123 2mo ago
And has performance I believe worse than rocksdb
89.
by vlovich123 2mo ago
It’s usually very difficult in a KV db to have an efficient operation that returns the item deleted. You’d need a transaction API to do it reliably. The challenge is concurrent writes are impossible to serialize against without transactions
90.
by vlovich123 2mo ago
Because Tokio, while great for lots of things (ie default decent performance with ease of use), is a performance bottleneck if you want extremely high performance. For example, the best this DB can do is ~3.7Mkeys/s for non durable wri

More ›