The primes one is my least favourite one indeed, I left it in just because I happened to include it in the very first version and I am thinking it just counts for 5% in the end...
The regex ones are "micro" yet quite important, dkbench it's a Perl (and C)-based benchmark (reflects our main code), and the regex engine is the most highly optimized part of the language so regex speed is a good representation of text processing speed in Perl.
As I said, the overall score correlates well to SPEC/Geekbench so as a suite it works well.
For compiler comparisons I usually compile a language like python or perl as a test, but I did not want to add something like that, to keep it fast with many smaller benchmarks.
It came up recently in a post I did about how bad Geekbench 6 multi-core is, and some are saying they still use it for single-thread as it correlates well with SPEC. I thought I'd mention the one I built and use, which also correlates well with SPEC (and Geekbench 5+) but is open source and scales well up to hundreds of cores.
It came up recently in a post I did about how bad Geekbench 6 multi-core is, and some are saying they still use it for single-thread as it correlates well with SPEC. I thought I'd mention the one I built and use, which also correlates well with SPEC but is open source and does not have scaling issues.
They warn they will reclaim. I had two accounts, one processing data for a free weather service I volunteer for, so it's not idle and has had no issues for a couple of years now. The other for personal projects, so at times it stays idle for a while and I would get these email warnings which made me switched it to paid. I have not paid a cent, again for a couple of years now.
I had a bit of a hard time when I first signed up. It turns out the problem was I had included "oracle" in my email (I give a different email on my domain to every provider), so some part of the system considered it an internal email and others part did not, so I had a weird account that could not do anything. Took them a month of two to figure out what was wrong...
The testing was from mid-September to mid-January, Turin was released on Azure end of January. They simply did not make the cut, unfortunately I could not wait forever for them, they always seem to lag behind at least half a year :(
Huh, I have not been able to provision any newer CPUs after dozens of tests, certainly not Emerald Rapids. And that blog post is weird, their charts don't even have a key shown, it's like they bought a few CPUs and threw that quickly together to get people's hopes up. A real shame, I am still running DO droplets, but they are behind the times...
May I suggest the one I use (I wrote it), which also correlates well with SPEC & Geekbench 5, but also runs the benchmarks on all cores if you want to so you get both max single-thread and max multi-thread: https://github.com/dkechag/dkbench-docker . You basically run 'docker run -it --rm dkechag/dkbench'.
Yeah, that's the main reason. Not sure why the ban, medium etc are much worse...
The second reason is I've never had a slashdot submission accepted and I saw that after posting this the page suggested I share it to increase chances of the editors picking it up, but I don't really use social media so I though hey why not HN.
A 16-core 4565p is of course faster in max single thread speed than a 96-core that GCP is running at an economically optimal base clock.
A year ago I gave a talk about optimizing Cloud cost efficiency and I did a comparison of colocation vs cloud over time. You might find it interesting here, linking to the relative part: https://youtu.be/UEjMr5aUbbM?si=4QFSXKTBFJa2WrRm&t=1236
TLDR, colocation broke even in 6 to 18 months for on-demand and 3y reserve cloud respectively. But spot instances can actually be quite cheaper than colocation.
You generally don't go to the cloud for the price (except if we are talking hetzner etc).
Going to the cloud can't possibly be as cheap as owning your own hardware for obvious reasons - they have to make money somehow. Well, unless you use spot instances, which uses spare nodes.
In any case, you move to the cloud despite the cost if you need the multi-region redundancy, the management/features etc. More commonly it's because the higher ups heard everybody's doing it, but oh well :D
I wrote the article. I would NEVER tell anyone to use Oracle, as the vendor lock in and strong-arming and pricing is ridiculous. That said, I am hosting small projects on Oracle Cloud, due to the super low cost. I can just move them whenever they decide to be naughty, I am not using an oracle DB or anything proprietary, just linux VMs with my own mysql setup.
From your post I can tell you did not read the "year-old blog post". It starts with the scaling, but goes further and explains a lot. I am a software engineer specializing in algorithms and optimization, Amdahl's law is part of the usual training I give our junior developers. It has nothing to do with Geekbench 6 being a surprisingly bad benchmark, especially for big CPUs.
Not sure you opened the blog post. The scaling is atrocious, even for tasks that should be extremely parallelizable. The Geekbench "Text Processing" benchmark supposedly processes 190 markdown files, and yet it tops at just 1.34x the single-thread performance when you have 4 cores, and it drops with more cores! I admit my expertise is algorithms & optimization so I may get more easily incensed by inept developers, but this is crazy... It is not realistic in any way, unless we assume the "real world" is just js beginners scribbling code for a website...
Yeah, I also get confused with references. I was annoyed from the start, when "Mojo" was announced as a Python family language. Mojolicious uses the "Mojo" namespace and is referred to as that quite often. I know Perl is not as popular as it used to be, but Mojolicious is probably the most popular framework of a language that is roughly in the same "space" as Python, so that naming choice was very ignorant IMHO.