In my opinion, conceptualizing memory consistency in terms of acquire/release is wrong and it confuses many programmers.
One problem is that 2 kinds of ordered loads and stores are not enough, 4 kinds are needed.
Some algorithms need not only load-acquire and store-release, but also a store that is guaranteed to be executed before all subsequent stores and a load that is guaranteed to be executed after all previous loads. These properties are the opposite of those provided by load-acquire and store-release. Except for x86 where any loads and stores behave like this, the other popular ISAs do not have such loads and stores, so stronger than necessary instructions must be used, i.e. load barriers and store barriers. Moreover, the instruction that is named a load barrier in the Arm ISA is not a load barrier, but a stronger barrier, but it must be used instead of a load barrier as no better alternative exists.
Besides the fact that not only load-acquire and store-release, but also other 2 ordered loads and stores are needed, a much more serious problem is that load-acquire is not the instruction that is really needed.
I have never seen any useful algorithm where load-acquire is the correct instruction to use. In all algorithms, what you want is not an instruction, but a loop that compares memory repeatedly, waiting for some condition to be fulfilled. The 4 most frequent kinds of loops that are needed are wait-for-not-equal, wait-for-equal, wait-for-even and wait-for-zero.
These loops may execute a load-acquire, but that is not the desired behavior. What you really need are 2 kinds of barriers, one inside the loop and one immediately after the loop.
The internal barrier must prevent the CPU from speculatively executing many future loop instances beyond the conditional jump that terminates the loop body, as it normally does. On x86-64, the instruction PAUSE provides such a barrier. On Aarch64, I suspect that a load-acquire instruction does inhibit this kind of speculative execution, despite the fact that this behavior is not documented. Otherwise, a CPU executing this kind of loop would waste a lot of energy and resources.
The barrier after such a loop must prevent speculative memory accesses beyond it. The semantics of load-acquire are not really needed, because all such loads are done in a loop and the memory accesses that follow the loop cannot be executed before such a load, due to the control dependency created by the conditional jump that follows the load. Nonetheless, while normal execution is impossible, the CPU can execute speculatively any loads following the loop and only this speculative execution can break the acquire semantics. Therefore what you really need is a speculation barrier after the loop, not an acquire barrier, whose behavior is provided automatically by the loop, even without any instruction with acquire semantics.
On x86-64, if a loop is terminated by an unconditional jump, it is said that such a jump blocks the speculative accesses beyond it. This is why the examples provided by Intel in its optimization manual about how to write this kind of acquire loop show loops terminated with unconditional jumps, even if this makes the loops longer, as otherwise the unconditional jump could have been eliminated by moving the conditional jump at the end of the loop. On x86-64, an alternative to unconditional jumps is the LFENCE instruction, which is a barrier for speculative memory accesses.
The so-called load-acquire instruction of Arm might also implement the textbook behavior of load-acquire, of ordering the memory accesses, despite the fact that this behavior is always superfluous, but it must also have the undocumented behavior of being a speculation barrier for memory accesses, otherwise the Arm CPUs would have been very inefficient. However, dedicated speculation barriers of the 2 kinds needed inside the loop and outside the loop would have been more efficient than a load-acquire instruction.
Technological progress is bottlenecked by the fact that there are many mathematical problems for which currently there are no known practical methods of solution.
Because even with supercomputers the equations that describe many physical systems cannot be solved, research and development is still based on a lot of empirical methods, i.e. things must be physically built and measured, because mathematical computations cannot predict their properties with sufficient accuracy.
So if some miraculous algorithms would be discovered for the approximate solution of the systems of equations that are insoluble for now, that could accelerate technological progress a lot in certain domains, especially for the discovery of new materials or chemical substances with desirable properties.
Their CPUs are faster at inference than many GPUs. These are server CPUs with 144 cores and wide memory interface.
Fujitsu has added some ISA extensions for AI inference to the standard Arm ISA, e.g. instructions for inference with FP8.
Even their previous CPU generation was for some time the champion in energy efficiency, with better performance per watt than the NVIDIA GPUs, until a newer generation of NVIDIA GPUs has leapfrogged them.
There are good chances that this new Fujitsu CPU might be again for some time the CPU with the best energy efficiency, but it remains to be seen how it compares with the recent GPUs.
For many years the Fujitsu SPARC implementations were much faster than the Sun SPARC implementations.
During the decade 1995-2005, until the 64-bit AMD Opteron servers with Linux offered an alternative that crushed any kind of SPARC CPU with Solaris by a much higher performance combined with a much lower price, the SPARC Sun or Fujitsu servers dominated the market for servers used to host the CAD/EDA design tools used in electronics engineering, for the design of integrated circuits or electronic equipment. This means that all the EDA software from vendors like Mentor, Cadence, Synopsis etc. was available only for Solaris. That kind of software could not be run on Windows, due to the 32-bit memory limit. During that time, whoever got Fujitsu servers instead of the sluggish Sun servers, was very lucky.
It was an issue of fundamentally differing directions.
In the mid-2000's, Sun decided to take SPARC towards designs with many small SMT cores. In the era of single-core processors, the UltraSPARC T1 had 8 cores x 4 threads per core. This was at the same time Intel released the Pentium 4 with hyper-threading, so it was an industry trend.
This of course works great for very specific applications, particularly considering efficiency, but is awful for others. Scientific computation was especially bad because the T1 had only one FPU for 8 cores.
Fujitsu's SPARC64 didn't go in this direction, and stayed with a conventional design (2 way SMT at most). Sun realized this and started to also sell the Fujitsu SPARC64 for customers who couldn't use the thread level parallelism, an arrangement that lasted until the end.
The idea of lots of slow cores is still a thing today: Intel's Sierra Forest Xeon is 144 E-cores.
1 FPU for 8 cores is wild, but then again they were selling webservers.
Still, iirc FPU's were silicon heavy back in those days and it'd be interesting to know how far ahead the foundries Sun and Fujitsu were, maybe it was simply a factor of being too far behind in the foundry race that left Sun with few options.
Intel's E-Cores still are functionally complete for most parts though (excl Avx512?)? Todays limits seems to be memory bandwidth and power and I guess many of the 144 core customers are in it for virtualization and servers?
My understanding is the lots of small cores are for applications where you have lots of simple, independent tasks that tend to be IO-bound: web and other front-end servers, databases, transaction processing. SMT is optimal here because you can execute other threads while waiting for IO.
I haven't been closely following it, but the Intel E-cores are definitely less wide and have less execution units. The FPU/Vector hardware is 128-bits wide instead of 256. If you ask it to do 256-bit SIMD, the front-end breaks it into 2 operations.
No it is not at all Neoverse V2, which is obsolete and has much lower performance.
It is a custom Armv9.3-A design (same ISA like the Arm C1 CPUs from the flagship smartphones of 2026), but it has double-width execution units for SVE2 (i.e. 256-bit width, vs. 128-bit for the other Arm CPUs) and it has some ISA extensions for AI/ML, e.g. instructions for inference with FP8 (BF16 is already supported by the standard Arm ISA).
Despite the fact that Armv9.3-A may include SME (scalable matrix extension, like in the Apple CPUs and in the Arm C1 CPUs), Fujitsu did not mention SME, so I assume that they did not implement it and they rely on their enhanced SVE2 (which is not surprising, while the origin of Arm SME is at Apple, the origin of Arm SVE is at Fujitsu).
They did a presentation at Hot Chips, with all these details.
The core die is made with TSMC-N2P, while the SRAM die and the peripheral die are made with TSMC-N5.
Their CPU is designed in Japan, like the AMD CPUs or the Intel CPUs are designed in USA (the latest Panther Lake Intel CPUs have returned for fabrication to USA in 2026, but they also cost double than the corresponding Arrow Lake models made at TSMC in 2025, and their GPUs are still made at TSMC).
True, but besides wars there are other dangers, e.g. USA does not declare war when they apply "sanctions" randomly, under the legal theory that they can dictate how anything that includes some piece of US origin may be used by its owner.
Since that theory began to be used, anyone outside US has become anxious to become "sovereign", i.e. to stop using anything about which a foreign state can claim to have rights.
All the component chips are made at TSMC, in various processes.
"Developed in Japan" means the same thing like "developed in USA" means for NVIDIA or AMD or Intel. You can design chips anywhere on the planet, as long as TSMC is willing to provide you the required documentation and EDA libraries (which it does only if you already are or they believe that you will be a big customer).
One problem is that 2 kinds of ordered loads and stores are not enough, 4 kinds are needed.
Some algorithms need not only load-acquire and store-release, but also a store that is guaranteed to be executed before all subsequent stores and a load that is guaranteed to be executed after all previous loads. These properties are the opposite of those provided by load-acquire and store-release. Except for x86 where any loads and stores behave like this, the other popular ISAs do not have such loads and stores, so stronger than necessary instructions must be used, i.e. load barriers and store barriers. Moreover, the instruction that is named a load barrier in the Arm ISA is not a load barrier, but a stronger barrier, but it must be used instead of a load barrier as no better alternative exists.
Besides the fact that not only load-acquire and store-release, but also other 2 ordered loads and stores are needed, a much more serious problem is that load-acquire is not the instruction that is really needed.
I have never seen any useful algorithm where load-acquire is the correct instruction to use. In all algorithms, what you want is not an instruction, but a loop that compares memory repeatedly, waiting for some condition to be fulfilled. The 4 most frequent kinds of loops that are needed are wait-for-not-equal, wait-for-equal, wait-for-even and wait-for-zero.
These loops may execute a load-acquire, but that is not the desired behavior. What you really need are 2 kinds of barriers, one inside the loop and one immediately after the loop.
The internal barrier must prevent the CPU from speculatively executing many future loop instances beyond the conditional jump that terminates the loop body, as it normally does. On x86-64, the instruction PAUSE provides such a barrier. On Aarch64, I suspect that a load-acquire instruction does inhibit this kind of speculative execution, despite the fact that this behavior is not documented. Otherwise, a CPU executing this kind of loop would waste a lot of energy and resources.
The barrier after such a loop must prevent speculative memory accesses beyond it. The semantics of load-acquire are not really needed, because all such loads are done in a loop and the memory accesses that follow the loop cannot be executed before such a load, due to the control dependency created by the conditional jump that follows the load. Nonetheless, while normal execution is impossible, the CPU can execute speculatively any loads following the loop and only this speculative execution can break the acquire semantics. Therefore what you really need is a speculation barrier after the loop, not an acquire barrier, whose behavior is provided automatically by the loop, even without any instruction with acquire semantics.
On x86-64, if a loop is terminated by an unconditional jump, it is said that such a jump blocks the speculative accesses beyond it. This is why the examples provided by Intel in its optimization manual about how to write this kind of acquire loop show loops terminated with unconditional jumps, even if this makes the loops longer, as otherwise the unconditional jump could have been eliminated by moving the conditional jump at the end of the loop. On x86-64, an alternative to unconditional jumps is the LFENCE instruction, which is a barrier for speculative memory accesses.
The so-called load-acquire instruction of Arm might also implement the textbook behavior of load-acquire, of ordering the memory accesses, despite the fact that this behavior is always superfluous, but it must also have the undocumented behavior of being a speculation barrier for memory accesses, otherwise the Arm CPUs would have been very inefficient. However, dedicated speculation barriers of the 2 kinds needed inside the loop and outside the loop would have been more efficient than a load-acquire instruction.
reply