While randomly browsing around the web, I came across the description of the "Exec SG" project on LinkedIn. Which ended in a rather unexpected bit:
Quote:

Current development includes multi-core support (NUMA aware).

NUMA? Which stands for Non-Uniform Memory Access, i.e. a computer architecture where main memory is split into several segments, and the latency and bandwidth to each segment is non-uniform across the processors in the system.

In other words, NUMA means that some memory is "closer" to one processor, and other memory is "closer" to another processor, and while each processor can access all memory, for performance reasons, it is desirable to access "close" memory as much as possible.

Obviously, being NUMA aware is highly recommended while running on a NUMA machine (although how such awareness might manifest is very much a matter of approach --- there is no easy, compromise-free way of maximising performance on such a machine).

However --- all current and known-about future AmigaOS hardware is single-CPU, even if some of the CPUs are multi-core. And both the PA6T as well as the P5020 have crossbars between the CPU cores and the memory controllers, meaning that single-CPU machines with those machines are definitely not NUMA.


So --- anyone want to speculate why the Friedens are making ExecSG NUMA-aware? Unknown AmigaOS hardware[1]? ExecSG being used apart from AmigaOS?


[1]: Alas, the Apple Quad G5 is not a NUMA machine, either :(

Last edited by umisef on 13-Sep-2015 at 02:22 PM.

@umisef

Maybe they mean cache hierarchy in e6500 based SoC(s) from Freescale: eg. T4240 has three clusters (4 e6500 cores share same L2 on one cluster).

@umisef

Quote:

umisef wrote: While randomly browsing around the web, I came across the description of the "Exec SG" project on LinkedIn. Which ended in a rather unexpected bit: Quote: Current development includes multi-core support (NUMA aware). So --- anyone want to speculate why the Friedens are making ExecSG NUMA-aware?

Source(?): https://www.linkedin.com/pub/thomas-frieden/36/709/314

If you really ask me what I'm thinking about this sentence, my answer might disappoint you.

Non of the hardware announced by AEon is a NUMA hardware, so when they build their OS 'NUMA-aware' it might be an excuse for not having real SMP.

Last edited by OneTimer1 on 13-Sep-2015 at 02:33 PM.

@umisef
Maybe their idea of SMP is running 2 instances of AmigaOS in 2 seperate addressspaces which then can only access the other cores RAM after that core has been stopped and all caches flushed ?

Might even work (to some extent).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@umisef


freescale calls NUMA "CoreNet" on the P5020

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@umisef

possibly just a gimmick, but remember that amiga os 1.2-3.9 support it. 32 bit first, then zorro, chip last.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

68k Amigas only had 1CPU/core, NUMA doesn't really apply.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Sounds like most of it fits:
Quote:

Non-Uniform Memory Access, i.e. a computer architecture where main memory is split into several segments, and the latency and bandwidth to each segment is non-uniform

Then this part doesn't fit so well:
Quote:

across the processors in the system.

So while technically AmigaOS 1.3 (etc) didn't support AMP, SMP and NUMA, it has a software solution for an identical problem, namely non-uniform memory segments.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

If we leave the definition that wide open, every system that maps a GFX card to memory would also be NUMA.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

NUMA and SMP definitions cannot be changed as someone wishes...

@cdimauro

Since you don't have a law-degree your not even allowed to enter that discussion

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @olegil 68k Amigas only had 1CPU/core, NUMA doesn't really apply.

But it does sound suspiciously like what some of our users have been discussing, Kronos.

@Kronos

Quote:

Since you don't have a law-degree your not even allowed to enter that discussion

ROFL... Can I use that in my sig?

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@Kronos

Quote:

Maybe their idea of SMP is running 2 instances of AmigaOS in 2 seperate addressspaces which then can only access the other cores RAM

My line of thinking is similar.
Not two (2) instances of the OS though. They did indicate that they would be running two (2) instances of Exec, and the two Execs would play nicely with each other by keeping to their memory address space.

Making the new OS NUMA-aware is pretty much a must, even if the current hardware has only a single CPU socket, with a single channel for memory access.

_________________
All the way, with 68k

@cdimauro

Quote:

NUMA and SMP definitions cannot be changed as someone wishes

We're not changing the definition of NUMA. We are speculating or making educated guesses as to how a NUMA-aware kernel would benefit AmigaOS 4.x running on a single socket multi-core CPU with interleaved/non-interleaved RAM.

_________________
All the way, with 68k

@olegil

Quote:

So while technically AmigaOS 1.3 (etc) didn't support AMP, SMP and NUMA, it has a software solution for an identical problem, namely non-uniform memory segments.

The "across the processors in the system" part is rather important, however. It means that NUMA-awareness is a rather different problem.

In a classic-Amiga-style Chip-vs-Zorro-vs-Fast scenario, there is no challenge to picking memory --- simply pick the fastest memory that's (a) available and (b) fulfils the requirements. Voila, fastest possible execution, regardless what the scheduler does. Trivial optimal algorithm.

In a NUMA system, which memory is fastest depends on which processor code is running on. So the memory allocator and the scheduler interact. If the scheduler moves a process from one processor to another (as can happen easily in SMP), the performance of the process may change, because its distance from its data has changed. It may be beneficial to migrate the physical storage for the process's data into RAM that's closer to the new processor (using virtual memory, the OS can do this in a manner transparent to the process). But that costs CPU cycles and memory bandwidth, so the OS has to decide whether it's worth it --- will the process stick on that processor for a while? Is the process's performance actually memory bandwidth/latency limited?

What of memory shared between processes? Say, a FIFO that sits between two decoding stages of a video player? Obviously, the scheduler will want to move those stages to separate processors, so they can run in parallel. At the same time, the memory manager will want to keep them close together, so that memory accesses don't have to go through painfully many hops to reach the RAM chips[1][2].

Given that OS4 still has a single, globally accessible address space, and memory ownership by processes is still a foreign concept --- I would be most curious to see how one would even begin to make ExecSG deal with NUMA. And I would expect any such attempt to need extensive testing --- which would naturally require actually running on a NUMA platform. What platform would that be?


[1]: In a previous job where we were building extreme-throughput network filters, I once went to great lengths to not only pin every performance-critical process to a particular core, but also to ensure that shared libraries and executables were duplicated on each NUMA node, reducing the "sharing" aspect but increasing performance. Linux made that (relatively) easy by using copy-on-write sharing.
[2]: This also interacts in fun ways with memory-deduplication... Should memory be de-duplicated across NUMA nodes? Will the performance gain from having additional memory available compensate for the performance loss from having to access more distant memory?

@agami

Quote:

Making the new OS NUMA-aware is pretty much a must

Why? NUMA-awareness is merely a performance optimisation, which should be completely transparent to anything but the kernel. It has no logical effects (i.e. programs that behave correctly with kernel NUMA awareness will behave correctly without it, and vice versa).

And I have a hard time seeing why any OS4 developer would spend time now adding functionality, or even thinking about functionality, which might, one day, on some future hardware using some future NUMA-capable PPC, save 10% of performance --- while video still gets decoded by the CPU, 3D support is still at a 1990's level, there is no GpGPU support, and printing is still a thorny issue.

Quote:

We are speculating or making educated guesses as to how a NUMA-aware kernel would benefit AmigaOS 4.x running on a single socket multi-core CPU with interleaved/non-interleaved RAM.

The answer is "not at all".

@umisef

Quote:

And I have a hard time seeing why any OS4 developer would spend time now adding functionality, or even thinking about functionality, which might, one day, on some future hardware using some future NUMA-capable PPC, save 10% of performance --- while video still gets decoded by the CPU, 3D support is still at a 1990's level, there is no GpGPU support, and printing is still a thorny issue.

Spot on. BUT, one guy working on the kernel might get a kick out of putting in new functionality THERE instead of starting on a whole different project which is graphics oriented. I'm still hopeful that OS4 is not a one-man-show (actually, maybe I should start hoping it would be a one man show. I guess we don't have any full time developers, right?)

So while you're absolutely right about the technical side, your original question included the word "why" which to me makes it more of a psychological than technical question.

So I have a speculative answer to your question:
For the kicks.

Last edited by olegil on 14-Sep-2015 at 07:31 AM.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Quote:

I guess we don't have any full time developers, right?)

All I know is that when certain claims were being made about the Friedens not working on AmigaOS4, Ben responded that they worked about one day per week.
Although that information can be considered fairly recent, the usual caveat applies:all information is only relevant (if accurate in the 1st place), in the time it is offered.
Although others work their tails off in all of their spare time, I don't believe any of them work what you would term "full time".

Slight correction to be clear: The reference was to work on AmigaOS4, because Hyperion is not confined to AmigaOS4 for what it does.

#6

Last edited by number6 on 14-Sep-2015 at 01:31 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@umisef

I really haven't a clue about this but would to dual CPU A1XE modules that the Friedens had at one point (maybe still do?) count as NUMA?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad