That you need a whole lot of “ordinary” compute to benefit from the scaling properties of agents is the reason Nvidia is making this chip in the first place.
I also don't buy that it's a particularly representative set of tasks you might do with agents. Also included in the SPEC benchmarks are multimedia codecs, lossless data compression codecs, sqlite (i.e., database), all of which are going to be things you should easily throw into the sets of tasks an agentic workload might do. Cherry-picking just the compiler benchmarks instead of all of SPECint... again, it just raises a couple of eyebrows.
[1] To be honest, I'm kinda surprised that both gcc and llvm are in SPEC cpu2026.
Where compiler code is going to get really unusual, I suspect, is that compilers tend to be a little mono-focused on relatively few data structures. I know I was able to get measurable (single-digit percent!) performance differences in LLVM making very small tweaks to layout in llvm::Value. By contrast, when I was working on Thunderbird, the only similarly small change I could think to make that kind of difference would be to "oops, all string functions are now a cross-DLL call" (and even then, only because string handling is so dominant in that kind of application). Another kind of difference is that the compiler-based benchmarks are going to be quite light in virtual or indirect function calls (there's more of an emphasis on switch-based dispatching than vtable-based dispatching in most compiler implementations), which is going to make it a poorer proxy for some kinds of applications.
That is, nowhere.
Also you are wrong and anyone sizing up an arch to put their loads onto must first try that load on it and not rely on "bah, compilers compile on it".
Remember, the very first Windows XP 64 bit release was on Itanium.
[1] https://archive.org/details/NT351PMZPPC
[2] https://www.techmonitor.ai/technology/undercurrent_bubbling_...
[3] Legend has it that the SPARC port existed, done by Intergraph, but for Reasons was never a product.
I'm not completely convinced of this.
If you ignore VLIW, you just have a very unexciting RISC ISA, but because of the VLIW, you get extra scheduling info that most RISC designs don't provide which might be advantageous. The real question is actually about the code density of 41-bit instructions and if it can be offset by the 128-bit package (and perhaps something like allowing new 24-bit compressed instructions).
Poulson already somewhat proved part of this as it added back a traditional frontend and even added some OoO capabilities and 4-way SMT. It wasn't earth-shattering, but it wasn't absolute garbage either.
The Itanium ISA actually had a few nice features, but it also had other bad features that outweighed the good features. Besides the static instruction scheduling in bundles, there was also the handicap of using SPARC style register windows, which slowed-down context switches.
The second version of HP PA-RISC, which was too quickly replaced by Itanium, would have had good chances of providing superior performance in comparison with Itanium, had it not been abandoned without a fight.
If you're solely interested in single-core performance, then I would agree that they are a good stress test, but I think for a processor that is being sold on it's parallelism, they are not a great benchmark.
The reason is that for the other benchmarks the CPU vendors have always succeeded sooner or later, to tweak their compilers and compiling options, or even the hardware of the CPUs, in order to get improved benchmark results that nonetheless are not indicative of the improvements in other applications.
On the other hand, the compiling benchmarks, like with gcc, and now also with clang, are too diverse in CPU resource usage and no special feature of the CPU has a significantly greater weight than others, so special tricks to enhance the benchmark results have never been found.
When looking at the past SPECint results, the values of the gcc benchmark remain the most reliable relative performance estimator.
I doubt that this will change in the near future.
Moreover, the multi-threaded compiling benchmark is also very useful, because it matches exactly a real-world workload that is extremely frequently encountered. Due to the great clock frequency difference between running a benchmark on a single thread and running it on all available threads, the single-threaded results have a very poor correlation with the multi-threaded results.
The former implies per core memory bandwidth is probably not great, meaning SQLite wont perform as well, the latter meaning FP workloads are better done on the GPU, so video encoding wont be a high point. The idea is to run branchy integer workloads that fit into RAM imo, which is what these benchmarks measure.
Benchmarking is tricky. The only one that counts is your software running the way you run it. I often run a profiler while running unit/integration tests, but I know the results will not replicate actual use - it's just a proxy, because I don't want to profile everything in production unless the profiler has almost zero cost.