Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
57 ms
·
841.
▲
by
dzaima
4y ago
Doesn't work if you don't have read access past (or before) the segment you want. And, as GP says, asan won't like reading/writing out-of-bounds (even if temporarily) either. Probably very unlikely to happen, but that&#x
842.
▲
by
dzaima
4y ago
Doesn't seem to be for SSE & AVX at least (only 32-bit and 64-bit groups in AVX, and nothing for SSE). AVX-512 has _mm512_maskz_loadu_epi8, but not much has AVX-512. It's a shame that there aren't guarantees on being able
843.
▲
by
dzaima
4y ago
An out-of-order CPU will interleave things for you. Any modern CPU should have no issues running many iterations of the loop in parallel, as nothing should depend on the previous iteration. But, given that the task at hand usually deals wit
844.
▲
by
dzaima
4y ago
Here's a sorting algorithm with a similar idea of assuming a random input and applying an idea from hashing (but instead of buckets, it's robin-hood hashing): https://github.com/mlochbaum/rhsort Unlike this p
845.
▲
by
dzaima
4y ago
Windows/WSL shouldn't change anything, gcc will have the same set of optimizations everywhere. There's just no inlining of the functions going on. There may be differences in the dispatching between different compilers &
846.
▲
by
dzaima
4y ago
My guess (as someone who hasn't used D) is that it looks/feels too much like C for people who want a better Java/C#/etc, and too much like Java for people looking for a better C, resting in the middle, not really being a
847.
▲
by
dzaima
4y ago
Not for jumps - modern CPUs still (usually) have limit of one taken branch per cycle, or 1 to 2 untaken branches. And usually branch prediction will be the limiting factor anyway, for which a single branch is gonna be faster than many.
848.
▲
by
dzaima
4y ago
And, some actual timings (code: https://godbolt.org/z/qnWEqs446 ): $ clang -DLEN=1024 -DITERATIONS=100000 -O3 switch.c && ./a.out predictable: call_table: 173.1ms switch_cases: 59.6m
849.
▲
by
dzaima
4y ago
I can't reproduce neither clang nor gcc with -O3 inlining functions in a call table: https://godbolt.org/z/E7Tj31vox Nor do I see any of that kind of behavior in your linked assembly - call_table clearly contains
850.
▲
by
dzaima
4y ago
The spec contains "The behavior upon decoding a reserved instruction is unspecified." which to me sounds like that the CPU can do whatever it wants.
851.
▲
by
dzaima
4y ago
Right; making abstractions in C when you really know you should can be messy, but still possible (not with the same syntax, but I personally like the fact that a[b] is 100% guaranteed to be, at most, a single load; similarly for all operati
852.
▲
by
dzaima
4y ago
I'd say the case of C strings is more a case of a bad abstraction C has (at least historically), rather than lack of one. But the things that expect them are just the standard library (which doesn't have many useful general-purp
853.
▲
by
dzaima
4y ago
It's not even just memory access patterns. It's any and all abstractions - C doesn't provide any, so you write things manually, and thus won't do things that are not required for your use-case (whether it be separated lo
854.
▲
by
dzaima
4y ago
In AVX-512, there's an instruction vpcompressd, which literally does the equivalent of 16 iterations of that loop (the "store a subset of items to memory contiguously" part at least). The compiler would have to figure out how
855.
▲
by
dzaima
4y ago
good point on ICC! I've compared against it a couple times before, but never got any satisfying results so forgot about it.
856.
▲
by
dzaima
4y ago
Seems that[0] clang doesn't succeed at vectorizing that, instead just doing a bunch of boring regular unrolling. I'd assume it wouldn't be too hard for clang to be able to understand that pattern, just noone has bothered to
857.
▲
by
dzaima
4y ago
You can't really have bytecode instructions for the vector API functions because they're generic. They're instead methods, which the JIT compiler can handle specially if it so chooses to. Effectively, for pure computational o
858.
▲
by
dzaima
4y ago
__builtin_expect_with_probability knows nothing about booleans or branches. It assigns a probability for the first and second argument being equal, but 2!=1 while 2 is truthy.
859.
▲
by
dzaima
4y ago
CRC32X works on 8 bytes at a time and has a throughput of one invocation per cycle, whereas the SIMD operates on blocks in parallel (the chromium code does 64 bytes an iteration, with a lot of instruction-level parallelism too). Theoretical
860.
▲
by
dzaima
4y ago
Note that it might be worth trying the latest clang version first. The latest proper version is 14.0.0 from Mar 25, which is only a month old compared to the 7 months of 13.0.0, but if it's something that's condensable to a single
861.
▲
by
dzaima
4y ago
If (and this is very much an "if") it really is the case that just an offer can be a binding contact, what happens if you make an offer to two parties in parallel, and both accept? Does the one who accepted later just not get the
862.
▲
by
dzaima
5y ago
the memcopies will of course be compiled to unaligned loads & stores. Clang even seems to simplify the multiplications based on the size of the current portion of the argument, so I don't see much that could be improved. Maybe you
863.
▲
by
dzaima
5y ago
compress has less throughput, and probably a decent bit more latency. It would save offsetting the result pointer by the leading zero count, but I don't think that'd be enough to compensate for the slower compress. I don't kn
864.
▲
by
dzaima
5y ago
The AVX-512 constants aren't embedded in the instructions, but the address to load being static means the CPU can start to cache them when the decoder gets to them, possibly even before it knows that the input to the function is. In co
865.
▲
by
dzaima
5y ago
The list of arguments to _mm512_setr_epi64 are just reciprocals of powers of 10, multiplied by 2^52. The scalar code uses division by powers of 10, which'd compile down to similar multiplication constants; you just don't see them
866.
▲
by
dzaima
5y ago
Ah. The article, as I see it, is primarily about AVX-512 vs scalar code, not the 15 digits though. The fixed-length restriction is purely to simplify the challenge. To remove leading zeroes, you'd need to use one of bsf/lzcnt/
867.
▲
by
dzaima
5y ago
The article compares padded length 15 output for both cases; removing leading zeroes would have cost for both AVX-512 and regular code.
868.
▲
by
dzaima
5y ago
I imagine something like that might be viable in the to-be-designed RISC-V J extension, as safety checks (mostly in JITs) would be close to the only thing benefiting from this. Though, maybe instead of a conditional call, a conditional sign
869.
▲
by
dzaima
5y ago
such VMs would be near the only thing to benefit from them, and, still, only in code size (which wouldn't be in cache anyway) and codegen speed, i.e. not anything related to actual runtime speed. You can't use them for actually co
870.
▲
by
dzaima
5y ago
In most cases, I'd think those small teams support like a max of 5 ABIs, out of the 176. Of course it's "possible". Of course, complaining about it won't get it done. But I can easily envision an alternate universe
More ›