|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2864 Location: South Pole, Antarctica
|
Posted: Sun Sep 29, 2024 8:46 pm Post subject: |
|
|
This year there will be three good news to build powerful workstations or PC for parallel simulations:
- NVIDIA RTX 5090, it is gaming GPU, it has some restrictions, but still works with CUDA too. Rumors are that it will have 32GB RAM. No NVlink on modern cards anymore but it's on 2-4x faster than previous gen GPUs PCIe 5.0. PCIe6 is already ready and PCIe7 will be perfect even without NVLink
- 128 core Intel Xeon 6980P and
- 128 and 192 core AMD "Turin" processors.
Intel's monster processor already came last week, its spec is really impressive (do not know about price tag but i am sure it will be an arm and leg. And kidney). And 500 Watt consumption.
AMD should be much cheaper. But also 500 W. Buy two (or dig out in California city dump ) and you'll get 1 kW. This is the trend.
The RTX 5090 will consume even more, 600W.
Plan to buy good 2-2.5 kW power supply working on 240W power grid, the 120V one like in our Antarctica will already not fit their power envelop |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2864 Location: South Pole, Antarctica
|
Posted: Thu Oct 03, 2024 12:22 am Post subject: |
|
|
Here is good picture which explains why this compiler must support GPUs. This diagram shows how works typical modern supercomputer, this was from the most powerful one called Frontier but in essence all is almost the same for other servers or even HPC workstations.
On their baseboards they have one or two server CPU chips connected to 8 GPUs via fast links. The CPU essentially is just the input/output controller for the GPUs. There are 10,000 such baseboards in supercomputers like Frontier and typically few or even just one in high performance workstations. Even our PC with usual graphics card basically works same way. To save on cost of fast networking inside the baseboard, on workstations often is enough to use standard PCIe bus same way like with regular graphics cards. Little more complex motherboards can use NVIDIA's NVLink which has 300MB/s speed, or a bit more modern ones have special faster switches allowing more GPUs work in parallel.
You can see why supercomputers with GPUs are faster than CPU based ones: first, each GPU is faster than CPU and second, their amount is 8x larger than the number of CPUs.
So essentially all modern supercomputers are GPU supercomputers and this will be the trend for some time due to the fact that GPUs are also specifically good for AI. The reason for that is that GPUs besides 64bit arithmetic also have 32bit, 16bit and 8bit arithmetic and hence each time you use less bits you obviously get the speed doubled and AI often needs just the 8bit one and sometimes even 4bit is enough.
With CPUs though a decade or two ago what happened was unthinkable: Intel killed native support for single precision 32bit arithmetic and started to use just the double precision 64bit one and then truncating the final result to 32bit. I used so called mixed precision before when most of operations were in 32bit and only minor amount with 64bit and even larger precisions. Decently, 64bit is easier to use, no problems with the overflows or denormal numbers. But the price for that is factor of 2 speed decline.
What is good with the new processors is that by adding more cores they become as fast as all these incarnations of previous generations of GPUs which are still hell expensive. So hopefully all of them will drop in prices. Why we will need GPU if multi-core CPUs becoming as powerful as GPUs? Because besides monopoly in GPU NVIDIA also overjumped everyone with the fast interconnect. It is easy to add 2,3,...,8...16 GPUs to the existing system and improve with that the performance accordingly while you will not find a single manufacturer which makes more than dual-CPU motherboards and you will not find how to connect even two motherboards to make a parallel system. Hence with the CPUs you are screwed if you will try to get more performance
One thing is specifically good for this compiler. With it supporting CUDA and GPUs the speed of CPU will have no difference. All will depend on GPU and not on that CPU is old, slow or does not support multuthreading. Win-win for FTN95 !
Last edited by DanRRight on Thu Oct 03, 2024 6:17 pm; edited 4 times in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Thu Oct 03, 2024 7:34 am Post subject: |
|
|
There are various ways in which we (Silverfrost) can deploy our resources:
1) Bug fixing.
2) Implementing new features in the Fortran Standards.
3) Implementing on operating systems other than Windows.
4) Making use of new technology such as parallel processors.
We depend largely on user feedback in order to prioritise these tasks.
Almost all development work is hugely expensive in time and resources.
At some point I plan to investigate the potential for further work on parallel processing.
In the mean time users should note that parallel processing is not simply a task for the compiler. The programmer must create and use parallel algorithms. Such algorithms provide for parallel action whilst selectively locking memory that is used on more than one stream.
The compiler already allows for multiple threads and selective locking and this represents one kind of parallel processing.
Another approach is available with 64 bit FTN95 and is described in the document notes_on_parallel_processing.txt that is typically located in C:\Program Files (x86)\Silverfrost\FTN95\doc.
In any case, you can assume that a parallel processing approach will require a significant investment of time and resources from the programmer. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2864 Location: South Pole, Antarctica
|
Posted: Sat Oct 05, 2024 11:10 pm Post subject: |
|
|
I think asking users of this compiler at this point to prioritize the trends of future development is like to fall into closed loop. With time the users who are left or attracted here became those who do not need parallel simulations or speed, including mostly programmers of older generation. Asking them about their priorities is like slowly going into decline and dead end.
I can not propose any magical solution where to find funds and resources for that. I'd try for example to investigate how gFortran which was like a dumb toy for kindergarten in 1990 while Salford/Silverfrost was a super-pro-ultra with even FTN77 doing multithreading became so prolific. What is their business model? Here is the list of gFortran compilers in my Linux Mint third party Software Manager
All of these are different flavors and versions of gFortrans for different processors. Than means 100s of independent people worked on them. In 30 years FTN77/FTN95 departed too far from the mainstream in parallel simulations and run speed. All other Fortran compilers support MPI, CUDA and some OpenMP. Modern, older and even already dead Fortran compilers made them a defacto standard. Besides that they all merged in many other features so that for example this popular supercomputer PIC code
https://epochpic.github.io/documentation/basic_usage/compiling.html
can be compiled and run without any changes on these compilers
COMPILER=gfortran - GNU Fortran
COMPILER=intel - Intel ifort
COMPILER=pgi - Portland group compiler
COMPILER=g95 - G95 compiler
COMPILER=ibm - IBM AIX Fortran compiler for BlueGene
COMPILER=hector - Cray compiler as used on hector and archer
and with some minor changes on additional 6. No FTN95 listed here
May be FTN95 with time will merge with all other Fortran compilers using one common new parallelization method offered by Fortran 2018 Standard, I do not know. But that may take too long time. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|