Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
menaerus
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
51 ms
·
901.
▲
by
menaerus
2y ago
Weighing 800kg (!). Like, what the heck.
902.
▲
by
menaerus
2y ago
Spelling out the code in editor is not really the bottleneck.
903.
▲
by
menaerus
2y ago
You're absolutely right, not sure why I dumbed down my example to a single instruction. Correct way to estimate this number is to feed and keep the whole pipeline busy. This is actually a bit crazy when you stop and think about it. Now
904.
▲
by
menaerus
2y ago
Lately there's been a shitload of sponsored $$$ and anti-MySQL articles so it's kinda entertaining that their authors are being slapped in their face by Uber, completely unintended.
905.
▲
by
menaerus
2y ago
A cluster of 10 machines with 40 vCPUs in total would equate to 4 vCPUs per machine. I am not familiar with Spark internals but in the realm of distributed databases such a setup would generally make no sense at all (to me). So I think you&
906.
▲
by
menaerus
2y ago
Right, I found this interesting as a thought exercise and took it from another angle. Since it takes 4 cycles to execute FMA on double-precision 64-bit floats (VFMADD132PD) this translates to 1.25G ops/s (GFLOPS/s) per each core@5
907.
▲
by
menaerus
2y ago
Not sure if this comment was about to come out as snarky but the parent rightfully pointed out the not so obvious design of EPYC CPUs. CCD is a NUMA in disguise.
908.
▲
by
menaerus
2y ago
> Linear scan is very fast, but it's not competing against a worse scan it's competing against not scanning which is what the hash table is going to do. Not sure I agree since "not scanning" would imply that we have a
909.
▲
by
menaerus
2y ago
Learn to read with understanding and learn to have some respect as well. Never have I said that it cannot make a difference but that it's not universal and that it depends on the workload.
910.
▲
by
menaerus
2y ago
No, that's rubbish that became a meme. There is no universally the best design of a hash-map. Each design always comes with its own trade-offs and so is the case with open-addressing vs separate chaining in conflict resolution. Iterato
911.
▲
by
menaerus
2y ago
Actually read performance is one of the main challenges in LSM based storages.
912.
▲
by
menaerus
2y ago
If it doesn't fit into the L3 cache then what the benchmark is measuring is not the CPU efficiency of your SIMD approach but also inherently includes different (and complex) effects of L1+L2+L3 cache hierarchy, memory prefetchers and m
913.
▲
by
menaerus
2y ago
Such vendor would have a hard time finding a business model since plenty of chat-services are already existing on the market and all of them have access to the data of their users in one way or another. Thus I don't know what other typ
914.
▲
by
menaerus
2y ago
How about per-node memory pressure, did it change in favor of Scylla? I ask because I would legitimately expect that GC-based system would have a larger pressure on the memory subsystem.
915.
▲
by
menaerus
2y ago
Sure, the advantages of async communication are obvious but the crucial difference is that in that case vendor has to store your data somewhere in the data center. Reusing that data for unsolicited purposes is what many people will have a c
916.
▲
by
menaerus
2y ago
In the age we are living this starts to sound more like a feature to me.
917.
▲
by
menaerus
2y ago
If true this would be between ok-ish and decent result but since you didn't say anything about the experiment or how you ran it or anything about the HW it's hard to say more. I assume you didn't use https://github
918.
▲
by
menaerus
2y ago
LSM trees? ScyllaDB is LSM-based storage engine. RocksDB as well.
919.
▲
by
menaerus
2y ago
I can write SIMD code that's 2x the speed of the non-vectorized code but I can also rewrite that same SIMD code so that 2x becomes 6x. Point being, not only that you can get 2x on top of initial 2x SIMD implementation but usually much
920.
▲
by
menaerus
2y ago
If you're ready to settle on much lower IPC then yes.
921.
▲
by
menaerus
2y ago
Definitely. And I also found the title quite misleading. It's the auto-vectorization that this presentation is trying to cover. Compile-time SIMD OTOH would mean something totally different, e.g. computation during the compile-time usi
922.
▲
by
menaerus
2y ago
Red main branch is not what I am talking about at all. I am referring to the code being developed in a feature/bug-fix branch that is yet to be merged with main branch. OP believes that even in the development branch you should not fix
923.
▲
by
menaerus
2y ago
merge-commits or patch-series are already making it vastly more difficult for git-bisect than linear history with single self-contained commits. I used both and git-bisect on merge-commits is a nightmare.
924.
▲
by
menaerus
2y ago
We are talking about the commit, or series of commits thereof, during the development of code in feature/bug-fix branch and not about the commit that you push as a post-fix because one of your previous commits broke something. That was
925.
▲
by
menaerus
2y ago
What is wrong with simply pushing a "Fix linting issues" in a new commit? It's self-contained and very well describes the (single) purpose of the commit. I share the sentiment about the "logical small commits", and
926.
▲
by
menaerus
2y ago
In practice this doesn't result with a special-kinded instruction to hint the CPU branch-predictor but only affects the compiler to generate a codegen that is optimized for better CPU instruction-cache utilization. E.g. it will try to
927.
▲
by
menaerus
2y ago
> They serve to show why random OSS projects are indistinguishable from corruption. > In other words how do I choose which projects to support? How do I detect when said support is above board or when there are other factors? Same arg
928.
▲
by
menaerus
2y ago
> That comes out to an estimate of ~30k machines with ~2M total cores and this reverse proxy being responsible for ~20% of CPU time on average for every single machine (40k CPU cores from the article divided by 2M total cores across the
929.
▲
by
menaerus
2y ago
> but at scale Do you perhaps know what the actual scale is? Is it a 100 proxies around the world or is 1k, 10k, 100k ...? I imagine that number is not very high since the blog post says that pingora-origin can serve 35M+ requests per se
930.
▲
by
menaerus
2y ago
They only measure the CPU utilization of clear_internal_headers and they don't show what was the impact of the change to the overall runtime performance. The latter is what I was referring to.
More ›