Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sestep
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
91.
▲
by
sestep
1y ago
Great post, thanks for the link! I think you and I were just focusing on different things. You gave a broader discussion of the topic from a few different angles, with more specific basic numbers about CPUs as well as more realistic benchma
92.
▲
by
sestep
1y ago
Fair, it probably would have been useful for me to include a link to a page discussing those ideas. Since those theoretical/qualitative ideas are already covered in plenty of places online, I didn't bother to talk about them here
93.
▲
by
sestep
1y ago
Unclear if that'd be "better" but definitely something to compare against! Here's a related post by someone else that measures more of what you're talking about: https://lemire.me/blog/2018/
94.
▲
by
sestep
1y ago
The shuffle was only unacceptably slow for data too big to fit in memory. For data that fits in memory, Fisher-Yates is totally fine; this is why it's fine for the two-pass shuffle to use buckets that fit in RAM but not in cache.
95.
▲
by
sestep
1y ago
To be clear, the overhead on the left part is only due to file access for the last two graphs (the "direct" summation ones with just one blue line). For all the charts with both blue and yellow lines, there is no file access happe
96.
▲
by
sestep
1y ago
Great point thanks, and I agree! I thought about also including another experiment for this "linked list"-style access pattern to see what the difference in performance is, but didn't get around to it. Maybe I'll write a
97.
▲
by
sestep
1y ago
Yes, sorry for not being more explicit! It's 3x8GiB. Originally 4x, but one of my RAM sticks broke and I never bothered to replace it.
98.
▲
How much slower is random access, really?
(samestep.com)
114 points
by
sestep
1y ago
|
70 comments
99.
▲
by
sestep
1y ago
Automattic*
100.
▲
by
sestep
1y ago
All great points. In case it's relevant, I will also note that the rust-analyzer parser is considerably closer to DoD than the rustc parser is: https://github.com/rust-lang/rust-analyzer/tree/a642aa8023be
101.
▲
by
sestep
1y ago
Naive question: is accelerating at 1G continuously within the range of what we consider possible?
102.
▲
by
sestep
1y ago
I'm not an expert in this space, but is this meaningful? I'd assume that it's more common to fuse together transposition with an operation that precedes or follows it (e.g. matmul), which should be far more efficient than mat
103.
▲
by
sestep
1y ago
Is this the same thing as Red Knot?
104.
▲
by
sestep
1y ago
Somewhat related, from March: https://news.ycombinator.com/item?id=43297574
105.
▲
by
sestep
2y ago
I'm probably just missing something obvious, but in this scenario with really long names, doesn't that just mean all code will be extremely verbose? Or are you saying there'd be some way to have shorter bindings to those long
106.
▲
by
sestep
2y ago
Yeah but no GitHub Action is going to do this because updating tags is the de facto mechanism for releasing patches for those repositories.
107.
▲
by
sestep
2y ago
The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3
108.
▲
by
sestep
2y ago
If you're using VS Code then you can add `"rust-analyzer.check.command": "clippy"` to your `settings.json`. I assume there's a similar setting for rust-analyzer in other editors.
109.
▲
by
sestep
2y ago
The way to do this while avoiding race conditions seems to be `Arc::into_inner` or `Arc::get_mut`; for instance, the docs for `Arc::try_unwrap` mention a possible race condition, and recommend using `Arc::into_inner` to avoid it: https:&#x
110.
▲
by
sestep
2y ago
For "How Fast is This?" it links to a benchmarks page, which only shows that it's faster than Haskell. It would be more informative to instead compare against a language that is more popular and/or more performant than H
111.
▲
by
sestep
2y ago
For context, this is adapted from the book Dune , after which the OCaml build tool was named. https://www.goodreads.com/quotes/2-i-must-not-fear-fear-is-t...
112.
▲
by
sestep
2y ago
I was excited to read this post because I haven't yet tried WasmGC for anything beyond tiny toy examples, but was disappointed to find no actual numbers for performance. I don't know the author well enough to be able to assess the
113.
▲
by
sestep
2y ago
Really? I thought that no practical linear algebra library used the Strassen algorithm. Can you provide a source?
114.
▲
by
sestep
2y ago
This is true but misleading: analogously, typechecking depends on parsing, but IDEs typically make a best effort to typecheck syntactically ill-formed programs.
115.
▲
by
sestep
2y ago
It is interesting that the borrow checker doesn't run until after typechecking succeeds. As far as I'm aware, rust-analyzer has its own builtin logic for doing typechecking, but it delegates to rustc for borrow checking. I wonder
116.
▲
How can computers roll dice?
(samestep.com)
2 points
by
sestep
2y ago
|
0 comments
117.
▲
by
sestep
2y ago
I had no idea this existed, thanks so much for the link! Reading their paper right now, and I'd love to see your explainer once you make it :) My website is linked from my profile, send me a link on social media if you ever get around
118.
▲
by
sestep
2y ago
Not sure if this is exactly the same scope as what you're asking about, but here's an ESSE '21 paper titled "The Impact of Undefined Behavior on Compiler Optimization": https://doi.org/10.1145/3
119.
▲
by
sestep
2y ago
It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; that's why it's still on version 1.x. Granted, sometimes there is a compiler bug that causes some old code not to compile with n
120.
▲
by
sestep
2y ago
TIL 3d.xkcd.com exists.
More ›