Why are they not using GPUs? is it use cases that don't suit GPUs or because of the limitations they are imposing on themselves to use SMIC domestic chips?
The reason is that with GPUs it is far more difficult to reach a great percentage of the maximum theoretical throughput. Most GPU programs reach only a very small fraction of what is theoretically possible, and in the best cases one may reach something like 50% to 60% of the maximum.
This CPU-based supercomputer has demonstrated reaching 80% of the theoretical maximum throughput, and this is typical for CPU-based supercomputers. It is much easier to write efficient programs for CPUs.
The new custom Chinese CPUs, which use SME, the Arm Scalable Matrix Extension, are fast enough that they have beaten all GPU-based supercomputers, so there was no need to use GPUs.
Moreover these CPUs use HBM for a very fast memory interface, so in the benchmarks that depend more on memory bandwidth they have an even greater advance over the US GPU-based supercomputers. Thus there really was no point in using GPUs.
GPUs are necessary only when your CPUs are not good enough, which was not the case here.
In the recent past, the Japanese Fugaku used the same approach, of avoiding GPUs. At that time, their custom CPUs using the Armv8-A ISA with SVE were the first which used this ISA in HPC, but now that ISA variant is obsolete in comparison with the Armv9-A ISA with SME, which is implemented in these new custom Chinese CPUs.
You can go past this only on a matmul benchmark, which is seldom useful per se.
Linpack consists mostly of matmuls, but nonetheless there are additional operations that prevent GPUs to reach the high utilization of over 80% that is normal for CPUs, so that a throughput over 50% is considered good at the scale of supercomputers.
At the scale of a supercomputer, the utilization factor is considerably less than for an individual GPU or CPU, because the big matrix is split in blocks and the matrix multiplications are computed on different boards and in different racks, then the results are assembled, so there is a communication overhead.
The former Intel Xeon Phi, with a large number of cores that were weak except for their vector execution units, resembled GPUs in failing to reach a high utilization on Linpack.
Yeah, I mean, if your workload is oddly shaped it will definitely work better on CPU than GPU. CPUs are easier to get higher utilization on but I feel like they are almost cheating, because maxing out a core is really translating your code to a machine that has weaker performance (die area, etc.) in exchange for it handling some of the complexities of your algorithm.
I’m not sure if I’m missing a joke, but that’s why we have general purpose computing on graphics processing units (GPGPU) which is why 8/10 of the top 10 machines have GPUs.
GPUs were for graphics. Now, they're mainly used for machine learning training and inference. The big tech companies are spending eye-watering amounts for GPUs - hundreds of billions of dollars a year each. That's the reason that Nvidia's market cap is at $4.66 trillion.
I led the engineering team of a large adtech company (TripleLift - order of hundreds of billions of events/day) and we evolved from self hosting Kafka, to paying a vendor (Instacluster), to migrating to RedPanda.
RedPanda was a huge win for us. Confluent never made sense to us since we were always so cost conscious but the complexity/risk of managing a critical part of our infra was always something I worried about. RedPanda was able to handle both for us - cheaper than Kafka hosting vendors with significantly better performance. We were pretty early customers but was a huge win for us.
Same, small martech company. RedPanda works and the pricing allows actually using the service, plus the “source available” isn’t that limiting if you prefer to run your own stuff. Definitely glad to be off kafka prior to this news!
Last i talked to RedPanda sales while working at a big name client they would not offer us anything below $100k per year for enterprise support etc (us running on our kubernetes). Looks like they added some "serverless" pricing thing now, but at the time Azure Eventhub (kakfa client compatible) was cheapest enterprisy option if I remember correctly.
We switched to Redpanda's BYOC product because we couldn't use Confluent Cloud (contractual reasons) and BYOC was a third the price of Confluent for Kubernetes while also being a managed service.
I've been pretty happy with RP performance/cost/functionality wise. It isn't Kafka though, it's a proprietary C++ rewrite that aims for 100% compatibility. This hasn't been an issue in the 2+ years since we migrated prod, but YMMV.
American brands like Ford typically sold models that were both designed and manufactured in Europe such as the popular Ford Escort and Ford Transit. They are completely different to what is sold in the US.
Couchbase mobile has been doing this for over a decade and early versions of membase 15 years ago were using a sqlite backend as a noSQL JSON datastore
I'm using something like this for a small personal project that's only going to have a couple of users. Basically, just an app for myself and my girlfriend for all of the various restaurants, movies, recipes, tv shows, locations, etc. that we plan to go to/do at some point in the future. It's basically just a glorified todo list that uses APIs (TheMovieDataBase, OpenStreetMap, etc.) to grab additional metadata and images to present everything nicely
I want us both to be able to make notes/add ratings to each item, so the set of tables looks like this:
- TodoItems
- Notes
- Ratings
Where every TodoItem can have multiple Ratings/Notes attached. Because each of the TodoItems is going to be of a different type with different metadata depending on the type of item (IMDB/TMDB id, image url, GPS location), and I want it to be extensible in future, its schema has ended up looking like this:
CREATE TABLE TodoItems (
id INTEGER PRIMARY KEY NOT NULL,
kind TEXT NOT NULL,
metadata BLOB NOT NULL
);
With SQLite's json manipulation functions, it's actually pretty pleasant to work with. As it grows I might end up adding some indexes, but for now the performance seems like it will be fine for this very low traffic use case. And it makes deployment and backups incredibly simple.
Postgres added native support for JSON in 2012. People have been using RDBMS to store denormalized data and even as a key-value store for way longer than that. In fact, it's very hard not to do that
