Pascal on Aros 64 bit.

[trekiej]

If I use Pascal on Aros 64, do I have access to large sums of memory?
If I have motherboard with 32 Gigs of RAM, how well does Aros 64 deal with it?

[mschulz]

If I use Pascal on Aros 64, do I have access to large sums of memory?

If our pascal version supports it, then yes. AROS itself does.

If I have motherboard with 32 Gigs of RAM, how well does Aros 64 deal with it?

The RAM will be splitted a little somewhere close to the 4GB boundary (MMIO for PCI and PCI memory on e.g. graphics card), so you will have about 28GB of MEMF_FAST in one chunk above 4GB and few memory regions below 4GB (MEMF_CHIP and MEMF_FAST).

If you had more than 128GB of memory it would be spitted into 128GB chunks.

[trekiej]

Thanks, I guess Aros Smp has exact same capabilities.
Outside of 3D Rendering, I am not for sure what uses large Data Sets.
edit:
I could google a list I bet.

[trekiej]

I think about games like Grand Theft Auto V and how much area the gamer has to roam around in the game.

[magorium]

If I use Pascal on Aros 64, do I have access to large sums of memory?

Depends on what you call "large sums" 

The maximal amount of memory that can be allocated would be more than on a 8-bit computer and less than on a 128-bit computer. Provided that you have configured those systems with the maximal amount of memory that can be slotted into them.

Or to put it in other words: "yes".

Alll limitation(s) as provided by the OS (if there are any) when it concerns memory allocation still counts.

[magorium]

I think about games like Grand Theft Auto V and how much area the gamer has to roam around in the game.

Somehow that statement reminded me of the first demo i saw on the c-64 that was able to show an actual demo on the screen (including music and sprites) and was able to load data from disk in the background... that data to be used to further continue the demo. This technique should be around here for 35-40 years now or so... perhaps even older.

Mildly stating there that programmers these days tend to be lazy and just fill up every darn bit they are able to find (including disk-space). Not that they have any clue what to do with a single bit though 

It is a wrong view of things anyways. These days data is stored into the buffers/memory of your graphics card. Funny thing that the cycle of using custom chips keeps repeating itself.

[trekiej]

I see the Amiga in today's computers.

[trekiej]

Linus Tech Tips had a mother board that had 4 Opterons on it. Each had 16 cores. The total memory for that board was 1 Gig of RAM. It ran games really bad. I was wondering if ccNuma or Numa was in need of an update or tweak.
How would Aros fair on this, if possible?

[magorium]

Linus Tech Tips had a mother board that had 4 Opterons on it. Each had 16 cores. The total memory for that board was 1 Gig of RAM. It ran games really bad. I was wondering if ccNuma or Numa was in need of an update or tweak.

Can be.

Keep in mind though that threads are not (i repeat not) a holy grail. After a certain amount of threads you are hitting the limits of a couple of things such as for example overhead of stack (each thread has it's own stack) and locking of data on which a thread operates (only one thread can access the same data at the same time).

Even if you design your application properly (for threading) it can happen that things don't scale very well. Sometime that require a redesign that scales better or requires to take a complete other approach to the problem at hand.

Maybe you don't understand all terminology but take a look here at a normal day practise and the approach taken to find a proper solution to their specific problem. https://www.druva.com/blog/multi-threading-hits-scalability-dead-end/

As stated there and as is a normal approach: a (web)server that uses blocking sockets and threading to handle requests. And in practise that scaled terribly and the blogger writes about hitting those limits and what they did and take another route to solve the problem. He names it micro-threads (greenlet) and which Pascal kind of refers to as worker threads.

It is the same for every application out there that uses threading. Game or not. At a certain point you hit the limits of your design and hardware being used.

I'm sure there are far better (academic) explanations out there that discusses things (theoretical) into detail but i thnk it is better suited to explain things using every day situations.

Speaking of Linus... that is why all the benchmarks he does mean shite.... unless your are in the business of running benchmarks for the life-duration of the hardware. Great if you are using blender all day long but otherwise can kill your pleasure considerably. Benchmarks such as he uses are just a mere indication of the capabilties of the hardware being benched. And usually under perfect conditions as those benchmarks works best for themselves that way. If that eventually works for you or not is complete other story 

How would Aros fair on this, if possible?

I have absolutely no idea... buy one and test it ? 

But to give you a more serious answer, i do not know because i have no idea how the thread model is going to be implemented in the end. So far i've only seen other cpu cores/threads being used as a worker thread. Which is all nice but doesn't provide us any information on how threads could be automatically scheduled on different cores. Perhaps it proves to be unrealistic at all in the end. Besides that it really is not my area of expertise and i have no idea how much progress was made for AROS. So be warned and eat buckets of salt 

[trekiej]

Oops, I mean a Terabyte of R.A.M.