ashvardanian

It’s a very interesting benchmark (https://github.com/lemire/TestingMLP) — probably worth adding to the Phoronix or some wider suite.

Every couple of years I refresh my own parallel reduction benchmarks (https://github.com/ashvardanian/ParallelReductionsBenchmark), which are also memory-bound. Mine mostly focus on the boring simple throughput-maximizing cases on CPUs and GPUs.

Lately, as GPUs are pulled into more general data-processing tasks, I keep running into non-coalesced, pointer-chasing patterns — but I still don’t have a good mental model for estimating the cost of different access strategies. A crossover between these two topics — running MLP-style loads on GPUs — might be exactly the benchmark missing, in case someone is looking for a good weekend project!

Curious if anyone’s using the 8–16 socket IBM E1080 systems for large-scale data processing outside of SAP HANA. POWER10 offers ~400 GB/s memory bandwidth per CPU, so a full system pushes ~6 TB/s. Feels like HANA doesn’t really scale that far — what does?

2012 Retina model had all the relevant ports, a great keyboard & screen, an Intel CPU and Nvidia GPU - the go-to choices for professional software development to date, making it much easier to design locally & deploy remotely.

Build quality was also stunning. It’s still good, but the gap between brands is shrinking.

Arguably the worst part about modern MacBooks is software. I don’t know anyone who finds it more stable/convenient to use or pleasant to develop for :(

Maybe even better examples would be <https://github.com/intel/hyperscan>, <https://github.com/simdutf/simdutf>, and my own <https://github.com/ashvardanian/StringZilla> :)

Yes, macOS/iOS aesthetics reached their peak around 2013-14. Hardware-wise, the story is similar; the 2012 MacBook Pro was the most marvelous piece of hardware I've ever bought.

I miss that feeling. No part of me would agree that Apple is a more impressive company today than it was 13 years ago, despite its market cap.

You can go quite far with such libraries if you only perform data-parallel numerics on the CPU. However, if you work on complex algorithms or exotic data structures, there's almost always more upside in avoiding them and writing specialized code for each platform of interest.

Here's an explanation from one of my repos: <https://github.com/ashvardanian/simsimd?tab=readme-ov-file#d...>

Text processing. Loading/branching/storing content 1 byte at a time is the CPUs worst nightmare, but most text processing is quite tricky in SIMD.

Hi Austin! Was just checking your blog and the vowels detection post (< https://austinhenley.com/blog/vowels.html>).

What exactly do you mean by “use SIMD directly without calling out to another language”?

In some way Assembly will probably anyways be another language… but that’s a technicality.

I guess the spectrum of SIMD-related work in relation to Python is quite broad. There are projects like PeachPy, to help one write x86 Asm in Python, new Python’esque languages like Mojo, or SIMD libraries with thin CPython bindings. Do you mean one of those?

PS: I’m in the last camp. And in case you are focused on ASCII, for vowel search, have you tried StringZilla’s `find_first_of` (< https://github.com/ashvardanian/StringZilla/blob/960967d78c7...>)? I think it should perform well ;)

> Swift is the only language that scales from embedded devices and kernels to apps and cloud infrastructure.

Most people would disagree with this line…

Rule of thumb: Medium = primers, Substack & corp blogs = mid-depth, hand-curated personal blogs = deep dives.

Would love to see more Jepsen-grade explorations (<https://jepsen.io/consistency/models>) that include code snippets and highlight both implementation details and real-world usage caveats for different consistency models.

Absolutely agree! On the bright side, widespread adoption of Python-like general-purpose languages gives me hope, that similar options will multiply in the DBMS space.

From a modern startup’s POV - fast pivots, fast feedback - it’s fair to say HTAP is “dead.” The market is sticky and slow-moving. But I’d argue that’s precisely why it’s still interesting: fewer teams can survive the long game, but the payoff can be disproportionate.

> Per an analysis by TD Cowen cited by Bloomberg, hiked prices for server racks, cooling systems, chips, and other components could contribute to overall build cost rises of 5-15% on average.

I can agree that infrastructure generally has much lower margins than software businesses, but I don't know of any mega-projects that wouldn't turn out costlier during construction, and 15% is hardly something that stopped them.

The article mostly focuses on the 2008-2014 era.

It might be clearer to link the original blog post (https://cognition.ai/blog/kevin-32b) rather than the Hugging Face model card.

The charts and formulas are attractive, but the CUDA snippet feels quite elementary.

If I recall correctly from the recent YC interview, the Windsurf founder noted their team leans more toward GTM than engineering. That makes this less likely to be a classic acquihire (as with Rockset) and more plausibly a data play rather than a product integration.

My current read is that this is a frontier lab acquiring large-scale training data—cheaply—from a community of “vibe coders”, instead of paying professional annotators. In that light, it feels more like a “you are the product” scenario, which likely won’t sit well with Windsurf’s paying customers.

Interesting times.

Thanks, appreciate the gesture :)

Traditional SWAR on GPUs is a fascinating topic. I've begun assembling a set of synthetic benchmarks to compare DP4A vs. DPX (<https://github.com/ashvardanian/less_slow.cpp/pull/35>), but it feels incomplete without SWAR. My working hypothesis is that 64-bit SWAR on properly aligned data could be very useful in GPGPU, though FMA/MIN/MAX operations in that PR might not be the clearest showcase of its strengths. Do you have a better example or use case in mind?

Of all the billion-scale investment and acquisition news of the last 24 hours this is the only one that makes sense. Especially after the record-breaking $15B round, that Databricks closed last year.

The article covers extremely important CUDA warp-level synchronization/exchange primitives, but it's not what is generally called SIMD in the CUDA land .

Most "CUDA SIMD" intrinsics are designed to process a 32-bit data pack containing 2x 16-bit or 4x 8-bit values (<https://docs.nvidia.com/cuda/cuda-math-api/cuda_math_api/gro...>). That significantly shrinks their applicability in most domains outside of video and string processing. I've had pretty high hopes for DPX on Hopper (<https://developer.nvidia.com/blog/boosting-dynamic-programmi...>) instructions and started integrating them in StringZilla last year, but the gains aren't huge.

At this point, it doesn’t provide much novel functionality, but it should be faster than the standard libraries of most (or maybe all) programming languages.

https://github.com/ashvardanian/StringZilla

Has anyone done/shared a recent benchmark comparing JNI call latency across Java runtimes? I’m exploring the idea of bringing my strings library to the JVM ecosystem, but in the past, JNI overhead has made this impractical.

I can't speak for the whole industry, but we used it in older UForm <https://github.com/unum-cloud/uform> and saw good adoption, especially among those deploying on the Edge, where every little trick counts. It's hard to pin down exact numbers since most deployments didn't go through Hugging Face, but at the time, these models were likely among the more widely deployed by device count.

There is a "hush-hush open secret" between minutes 31 and 33 of the video :)

`#embed`, finally! Fixing UB in range-based `for` loops is also a good one!

Amazing! Would love to try them! If possible, would also ask for a table translating between CubeCL and CUDA terminology. It seems like CUDA Warps are called Planes in CubeCL, and it’s probably not the only difference.

Agreed! I was looking through the summation example < https://github.com/tracel-ai/cubecl/blob/main/examples/sum_t...> and it seems like the primary focus is on the more traditional pre-2018 GPU programming without explicit warp-level operations, asynchrony, atomics, barriers, or countless tensor-core operations.

The project feels very nice and it would be great to have more notes in the README on the excluded functionality to better scope its applicability in more advanced GPGPU scenarios.

Previous submission: https://news.ycombinator.com/item?id=43738703

Great article — and several other high-quality deep dives linked at the end! Here's another one on the H100 that I found particularly useful: <https://cudaforfun.substack.com/p/outperforming-cublas-on-h1...>

I agree with the author that programming GEMM on newer GPUs is a very different experience, though I'm wondering if "newer GPUs are [actually strictly] better"? It seems like there should still be some highly cost-effective use cases for T4 GPUs — aren't there?

Great article! I'm not very familiar with Zig, but this post definitely sparked my interest. While browsing the site, I also came across a collection of "favorite links" — definitely worth checking out: https://matklad.github.io/links.html