Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > sci.math > #641542

Introduction to AMBA® 4 ACE™ (2011) (Was: POINT OF VIEW OF AN ALGORITHM)

From Mild Shock <janburse@fastmail.fm>
Newsgroups sci.physics.relativity, sci.math, comp.lang.prolog
Subject Introduction to AMBA® 4 ACE™ (2011) (Was: POINT OF VIEW OF AN ALGORITHM)
Date 2025-12-01 23:37 +0100
Message-ID <10gl5b2$vu4n$1@solani.org> (permalink)
References (6 earlier) <10gkt46$vosq$1@solani.org> <10gkuno$1mfrd$1@dont-email.me> <10gl01c$vqnp$1@solani.org> <10gl238$1nj5e$1@dont-email.me> <10gl3ru$vt77$1@solani.org>

Cross-posted to 3 groups.

Show all headers | View raw


Hi,

Come on squirrel brain, that we practically have
PRAM on multi-core CPUs, is an old hat. ARM kept
up with MESI/MOESI in 2011:

https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/CacheCoherencyWhitepaper_6June2011.pdf

What are you squirrel brain, some russion developer
controlling a drone from within EMACS ? Meanwhile
ARM and Intel and Snapdragon etc.. have developed

much more marvels than only this simple PRAM.
The excitement on the side of ARM is quite big,
that they got into the boat of OpenAI:

OpenAI co-founder on new deal with AMD
https://www.youtube.com/watch?v=WuXCNpbO9hI

Bye

P.S.: Because of contention, you should of course
only use volatile variables carefully. It might
not scale well to 1000 cores.

There are also algorithms around to lift the
pressure when there is a large amount of cores.
Even Doug Lea has already put a few utilities in

java.concurrent.* for certain problems with large
number of cores, kind of easter eggs in java.concurrent.*.
But I am not sure whether Doug Lea is involved in

additions for AI accelerators. But he is in the
Program Committee of:

Parallel programming for emerging hardware, including
AI accelerators, processor-in-memory, programmable logic,
non-volatile memory technologies, and quantum computers
https://ppopp26.sigplan.org/track/PPoPP-2026-papers

It could be that the data flow compiler, things sketched
by OpenXLA already work well enough.

Mild Shock schrieb:
> Hi,
> 
> I am not saying anything. Thats the definition of PRAM.
> Whats wrong with you, are you a 5 year old moron.
> I am only citing a theoretical computer science model:
> 
> - Concurrent read concurrent write (CRCW)—multiple
> processors can read and write. A CRCW PRAM is sometimes
> called a concurrent random-access machine.
> https://en.wikipedia.org/wiki/Parallel_RAM
> 
> Technically with multi-channel memory nowadays, it
> doesn't need locks on the hardware level, only tiny
> serialization, could even happen outside of the CPU.
> 
> So if you drop some barrier requirements, you could
> really have the chaos of a PRAM, for worse or
> for better. I think you need to accept that,
> 
> even if its to big to fit in your tiny squirrel brain.
> 
> Bye
> 
> P.S.: "effectively CREW, since only one write per address at
> a time", it will just block the other cores? Short answer:
> Yes — if two cores try to write the same address, one
> 
> of them is forced to stall (block) until the other completes.
> In real hardware, the effect can mimic CRCW behavior over
> a short time window, even though it’s not truly simultaneous.
> 
> this blocking usually happens in the cache-coherence
> system, not at DRAM. Modern CPUs use MESI/MOESI. It happens
> over a small interval [t₁, t₂] dictated by cache coherence.
> 
>  From the POINT OF VIEW OF AN ALGORITHM, it’s “CRCW enough.”
> 
> 
> Bosephis Otlesnov schrieb:
>> Mild Shock wrote:
>>
>>> What are you, a 5 year old moron?
>>>
>>> There are millions of algorithm that use volatile variables. Just look
>>> at the Java code base.
>>>
>>> But I was not refering to multi-threading, I was refering to PRAM for
>>> matrix operations.
>>
>> i thought you said you wanna read and write parallel to RAM, aka PRAM, 
>> let
>> me see.. zum zum zum, yeah, you said that. Take a lock at timing
>> requirements for a read/write cycle, deadlines etc, shared memory or not,
>> fucking idiot.
>>
> 

Back to sci.math | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Pascual Sokolsky <aoa@ssppsc.pl> - 2025-12-01 19:58 +0000
  Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Mild Shock <janburse@fastmail.fm> - 2025-12-01 21:17 +0100
    Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Blending Molostvov <noo@biiooe.ru> - 2025-12-01 20:44 +0000
      Algorithm introduced in Hogwild! SGD (Niu et al., 2011) (Re: parallel random-access machine) Mild Shock <janburse@fastmail.fm> - 2025-12-01 22:06 +0100
        Linux kernel's RCU-protected hash tables (Re: Algorithm introduced in Hogwild! SGD (Niu et al., 2011)) Mild Shock <janburse@fastmail.fm> - 2025-12-01 22:26 +0100
          String interning is HashSet and not HashMap (Was: Linux kernel's RCU-protected hash tables) Mild Shock <janburse@fastmail.fm> - 2025-12-01 22:40 +0100
        Re: Algorithm introduced in Hogwild! SGD (Niu et al., 2011) (Re: parallel random-access machine) Bosephis Otlesnov <ooiv@th.ru> - 2025-12-01 21:42 +0000
          POINT OF VIEW OF AN ALGORITHM (Re: Algorithm introduced in Hogwild! SGD (Niu et al., 2011)) (Re: parallel random-access machine) Mild Shock <janburse@fastmail.fm> - 2025-12-01 23:12 +0100
            Introduction to AMBA® 4 ACE™ (2011) (Was: POINT OF VIEW OF AN ALGORITHM) Mild Shock <janburse@fastmail.fm> - 2025-12-01 23:37 +0100
              Sputnik Schock: Academia is Disposable [I. J. Good Ultraintelligence] (Was: Introduction to AMBA® 4 ACE™ (2011)) Mild Shock <janburse@fastmail.fm> - 2025-12-01 23:53 +0100
              Re: Introduction to AMBA® 4 ACE™ (2011) (Was: POINT OF VIEW OF AN ALGORITHM) Josbanne Balagula <ajbn@oll.ru> - 2025-12-01 23:06 +0000
                Re: Introduction to AMBA® 4 ACE™ (2011) (Was: POINT OF VIEW OF AN ALGORITHM) Mild Shock <janburse@fastmail.fm> - 2025-12-02 00:08 +0100

csiph-web