The Register Home Page

* Posts by borje

3 publicly visible posts • joined 2 May 2013

HPC won't be an x86 monoculture forever – and it's starting to show

borje

I remember the time when different CPU and systems architecture were good for different applications and type of workloads.

If you wanted good performance on the SGI NUMA machine, just use have of the CPU's and make sure you ran one process on each 2-CPU part. If you wanted it to perform really bad, then make sure you ran more processes than you had CPUs, and after a while all processes where running against remote (slow) memory. On a Sun Starfire (E10000) you had a very small slowdown when overloading the system.

Different CPU architectures where good for different applications and of course correct use was critical. I remember one HPC app that ran almost 2x faster on SPARC by changing from standard 8k pages to 4M large pages. And to get to the point, I do think that the default page size is a bigger problem than there being some old instructions laying around unused in the silicon. My first PC had 384kB of RAM, and then a 4kB page size was quite reasonable. But using that same 4kB page size when you have TB of memory - that is a lot of overhead as TLB entries need to repeatedly be loaded from memory. I also have the feeling that many applications are no longer well optimized.

I do hope that we in the future will see more different CPU architectures in HPC. Someone claimed that RISC-V has a lot of MIPS heritage and that might not be that bad - at least that heritage is less of a burden than what X86 has.

Arista monster switches fluff up cloud with 1 million virty machines

borje

Impressive

Andy is in my opinion one of the best, if not the very best, HW engineers on the planet.

AMD reveals potent parallel processing breakthrough

borje

Re: What was UMA architecture then?

To work well and with good performance, the correct page size as well as TLB structure is vital.

X86 systems today, work mostly with 4kB pages (there might be a handful of TLB-entries that can be used for huge (2MB) pages). Dividing a main memory of multiple, maybe +100 GB of memory into 4kB will be a huge overhead. It will be even worse with a combination of CPU's and GPUs.

4kB page size and 1024 TLB entries mean that you can only access 4MB of virtual memory before you need to start replacing TLB entries (reading the translation between virtual to physical memory from memory, before you can access the memory - ie you double the number of memory transactions).

SPARC and POWER today support much larger page sizes (+1GB) and this is something that needs to be done in X86 too.