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

Groups > comp.lang.prolog > #15068 > unrolled thread

What is analog computing nowadays? (Re: An old Busy Beaver ASIC (Application-Specific Integrated Circuit) (Was: Could AlphaEvolve find the sixth busy beaver ?)

Back to article view | Back to comp.lang.prolog

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  What is analog computing nowadays? (Re: An old Busy Beaver ASIC (Application-Specific Integrated Circuit) (Was: Could AlphaEvolve find the sixth busy beaver ?) Mild Shock <janburse@fastmail.fm> - 2025-12-01 11:25 +0100
    Wake-up call until everybody gets ear-bleeding (Re: What is analog computing nowadays?) Mild Shock <janburse@fastmail.fm> - 2025-12-01 12:01 +0100
      BB(745) is independent of ZFC (Was: Wake-up call until everybody gets ear-bleeding) Mild Shock <janburse@fastmail.fm> - 2025-12-01 12:07 +0100
        Write ZFC formulas on a tape (of a Turing machine) (Re: BB(745) is independent of ZFC ) Mild Shock <janburse@fastmail.fm> - 2025-12-02 17:18 +0100
          Turing machines have neurons (Re: Write ZFC formulas on a tape (of a Turing machine)) Mild Shock <janburse@fastmail.fm> - 2025-12-02 17:19 +0100
            A logical calculus in nervous activity [McCulloch & Pitts 1943] (Re: Turing machines have neurons) Mild Shock <janburse@fastmail.fm> - 2025-12-02 17:20 +0100
              Busy Beaver and Theory Consistency (Was: A logical calculus in nervous activity [McCulloch & Pitts 1943]) Mild Shock <janburse@fastmail.fm> - 2025-12-02 17:39 +0100
              Busy Beaver and Theory Consistency (Was: A logical calculus in nervous activity [McCulloch & Pitts 1943]) Mild Shock <janburse@fastmail.fm> - 2025-12-02 17:43 +0100
                Re: Busy Beaver and Theory Consistency (Was: A logical calculus in nervous activity [McCulloch & Pitts 1943]) Mild Shock <janburse@fastmail.fm> - 2025-12-02 23:18 +0100
    Re: What is analog computing nowadays? (Re: An old Busy Beaver ASIC (Application-Specific Integrated Circuit) (Was: Could AlphaEvolve find the sixth busy beaver ?) Maciej Woźniak <mlwozniak@wp.pl> - 2025-12-01 12:09 +0100
      parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Mild Shock <janburse@fastmail.fm> - 2025-12-01 12:15 +0100
        Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Maciej Woźniak <mlwozniak@wp.pl> - 2025-12-01 13:23 +0100
          Nope, you can't, because of the CRCW instuction (Was: parallel random-access machine) Mild Shock <janburse@fastmail.fm> - 2025-12-01 17:12 +0100
            Algorithm introduced in Hogwild! SGD (Niu et al., 2011) (Was: Nope, you can't, because of the CRCW instuction) Mild Shock <janburse@fastmail.fm> - 2025-12-01 17:31 +0100
              PRAMs might be closer to physics: Boltzman machines, etc.. (Was: Algorithm introduced in Hogwild! SGD) Mild Shock <janburse@fastmail.fm> - 2025-12-01 18:02 +0100
            Re: Nope, you can't, because of the CRCW instuction (Was: parallel random-access machine) Maciej Woźniak <mlwozniak@wp.pl> - 2025-12-01 17:59 +0100
              PRAMs might be closer to physics: Boltzman machines, etc.. (Re: Nope, you can't, because of the CRCW instuction) Mild Shock <janburse@fastmail.fm> - 2025-12-01 18:05 +0100
              PRAMs might be closer to physics: Boltzman machines, etc.. (Re: Nope, you can't, because of the CRCW instuction) Mild Shock <janburse@fastmail.fm> - 2025-12-01 18:08 +0100
                Physics more difficult than Rasperry LED cube? (Was: PRAMs might be closer to physics: Boltzman machines, etc..) Mild Shock <janburse@fastmail.fm> - 2025-12-01 18:25 +0100
          Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?) Thomas Heger <ttt_heg@web.de> - 2025-12-03 07:17 +0100
            Re: parallel random-access machine (parallel RAM or PRAM (Was: What is  analog computing nowadays?) Python <python@cccp.invalid> - 2025-12-03 06:46 +0000
            Re: parallel random-access machine (parallel RAM or PRAM) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2025-12-03 08:02 +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
        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

Page 2 of 2 — ← Prev page 1 [2]

#15109 — Re: parallel random-access machine (parallel RAM or PRAM (Was: What is analog computing nowadays?)

Le 03/12/2025 à 07:11, Thomas Heger a écrit :
> Am Montag000001, 01.12.2025 um 13:23 schrieb Maciej Woźniak:
>> On 12/1/2025 12:15 PM, Mild Shock wrote:
>>> Hi,
>>>
>>> You wrote:
>>>
>>>  > No, they don't, they just add one (or some)
>>>  > more layer on top of it.
>>>
>>> Techically they are not von Neuman architecture.
>>> Unified Memory with Multiple Tensor Cores is
>>> not von Neuman architecture. 
>> 
>> We can use von Neumann architecture
>> to emulate other architectures, but as long as it
>> is performed by our computers it is technically
>> von Neumann's.
>> 
> Did you know, that 'von Neuman architecture' was actually invented and 
> patented by Konrad Zuse in Germany in the early 1930th?
> 
> The liberators stole it from Zuse (like zillions of other patents from 
> other German inventors).

In this specific case: this is completely WRONG.

[toc] | [prev] | [next] | [standalone]

#15110 — Re: parallel random-access machine (parallel RAM or PRAM)

Thomas Heger wrote:
> Am Montag000001, 01.12.2025 um 13:23 schrieb Maciej Woźniak:
>> On 12/1/2025 12:15 PM, Mild Shock wrote:
>>> You wrote:
>>>
>>>  > No, they don't, they just add one (or some)
>>>  > more layer on top of it.
>>>
>>> Techically they are not von Neuman architecture.
>>> Unified Memory with Multiple Tensor Cores is
>>> not von Neuman architecture. 
>>
>> We can use von Neumann architecture
>> to emulate other architectures, but as long as it
>> is performed by our computers it is technically
>> von Neumann's.
>>
> Did you know, that 'von Neuman architecture'

It really is spelled _von Neumann_, named after the Hungarian-American
polymath John von Neumann.  He was born (as Neumann János Lajos) into a
non-observant Jewish family, and raised, in Budapest, then in the Empire of
Austria-Hungary.  His family name may be of German origin.

<https://en.wikipedia.org/wiki/John_von_Neumann#Life_and_education>

> was actually invented and patented by Konrad Zuse in Germany in the early
> 1930th?

NOT true.  Von Neumann's architecture "was based on the work of J. Presper
Eckert and John Mauchly, inventors of ENIAC and its successor, EDVAC."

<https://en.wikipedia.org/wiki/John_von_Neumann#Computer_science>

ENIAC (completed in 1945) and EDVAC (completed in 1949, in operation from
1951 to 1962) were "programmable, electronic, general-purpose digital
computers".  They were NOT based on or copies of the Z series of computers
as invented and built by Konrad Zuse; the first computer of that series that
was fully digital was the Z5, ordered in 1950 and delivered in 1953:

<https://en.wikipedia.org/wiki/ENIAC>
<https://en.wikipedia.org/wiki/EDVAC>
<https://en.wikipedia.org/wiki/Z5_(computer)>

> The liberators stole it from Zuse (like zillions of other patents from 
> other German inventors).

Cite evidence.

F'up2 comp.lang.misc

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#15082 — Linux kernel's RCU-protected hash tables (Re: Algorithm introduced in Hogwild! SGD (Niu et al., 2011))

Hi,

An example of a lock free datastructure, that
even doesn't use CAS, is for example:

Read-Copy-Update (RCU) Based Hash Tables
These use only memory barriers/fences and atomic pointer writes:
- Basic approach: Readers access the table without locks,
   writers create new versions
- Memory reclamation: Uses RCU grace periods instead of CAS
- Example: Linux kernel's RCU-protected hash tables
- Operations: Only requires atomic loads/stores and memory barriers

For Prolog systems there are also various
approaches arround, if one aims at the multi-threading
model for dynamic databass or atom tables.

I think this multi-threading model should be
abadoned, in favor of things that can be speed
up by a AI accelerator. Dogelog Player has abandoned

multi-threading all together. But for example
SWI-Prolog has heavily focused on lock free
data structures already like 10 years ago,

and it seems YAP can still not keep up with
SWI-Prolog. See for example here:

Yet Another Lock-Free Atom Table Design
for Scalable Symbol Management in Prolog
https://link.springer.com/article/10.1007/s10766-024-00766-z

But in my opinion, in the light of the AI Boom,
this is all amplified nonsense.

Bye

Mild Shock schrieb:
> Hi,
> 
> 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.
> 
> See for example here:
> 
> Hogwild!: A Lock-Free Approach to
> Parallelizing Stochastic Gradient Descent
> https://arxiv.org/pdf/1106.5730
> 
> Fuck off moron.
> 
> Bye
> 
> Blending Molostvov schrieb:
>> Mild Shock wrote:
>>
>>> What are you, a 5 year old moron?
>>>
>>> Pascual Sokolsky schrieb:
>>>> Mild Shock wrote:
>>>>
>>>>> But in principle the architecture is rather:
>>>>>
>>>>> parallel random-access machine (parallel RAM or PRAM) is a
>>>>> shared-memory abstract machine.
>>>>> https://en.wikipedia.org/wiki/Parallel_RAM
>>>>>
>>>>> The above class of machines is not widely know.
>>>>> But PRAM has been also studied, already in the 80's.
>>>>
>>>> parallel read of shared memory is only allowed to cia and the chinese
>>>> governoment; must be somenthing you dont know
>>
>> from shared memory you only read and write sequential, me frendo,
>> driven by semaphores, atomic instructions and so on. You are not that
>> fucking stupid to write parallel to a cell, are you
>>
> 

[toc] | [prev] | [next] | [standalone]

#15084 — String interning is HashSet and not HashMap (Was: Linux kernel's RCU-protected hash tables)

Hi,

The Linux kernel's RCU-protected hash tables
is still not free of problems. Multiple writers
might still need extra work.

String interning with a HashSet (no values, just keys)
is actually easier to make lock-free without full
CAS because you're only concerned with existence,

not updates.

Bye

P.S.: I am not affected by this amplified nonsense.
Dogelog Player has even no atom table. And since it
is single threaded, the HashMap for predicate lookup

is totally lock free. It is single threaded and it
has cooperative multithreading. Internally it uses
async/await from JavaScript for example, which is

a cooperative multthreading approach, but from the
outside it provides tasks and sleep and stuff.
Recently demonstrated a little Strudel style music coding:

Strudel Coding in Dogelog Player
https://medium.com/2989/bbb9c78fcd67

In basically declared multi-threading dead, before
AI accelerators were there. I had more some worker
things in mind, with more thorough siloing and isolation.

But now that we have AI accelerators, the decision
to abandon multithreadinhg looks even more splendid.

Mild Shock schrieb:
> Hi,
> 
> An example of a lock free datastructure, that
> even doesn't use CAS, is for example:
> 
> Read-Copy-Update (RCU) Based Hash Tables
> These use only memory barriers/fences and atomic pointer writes:
> - Basic approach: Readers access the table without locks,
>    writers create new versions
> - Memory reclamation: Uses RCU grace periods instead of CAS
> - Example: Linux kernel's RCU-protected hash tables
> - Operations: Only requires atomic loads/stores and memory barriers
> 
> For Prolog systems there are also various
> approaches arround, if one aims at the multi-threading
> model for dynamic databass or atom tables.
> 
> I think this multi-threading model should be
> abadoned, in favor of things that can be speed
> up by a AI accelerator. Dogelog Player has abandoned
> 
> multi-threading all together. But for example
> SWI-Prolog has heavily focused on lock free
> data structures already like 10 years ago,
> 
> and it seems YAP can still not keep up with
> SWI-Prolog. See for example here:
> 
> Yet Another Lock-Free Atom Table Design
> for Scalable Symbol Management in Prolog
> https://link.springer.com/article/10.1007/s10766-024-00766-z
> 
> But in my opinion, in the light of the AI Boom,
> this is all amplified nonsense.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> 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.
>>
>> See for example here:
>>
>> Hogwild!: A Lock-Free Approach to
>> Parallelizing Stochastic Gradient Descent
>> https://arxiv.org/pdf/1106.5730
>>
>> Fuck off moron.
>>
>> Bye
>>
>> Blending Molostvov schrieb:
>>> Mild Shock wrote:
>>>
>>>> What are you, a 5 year old moron?
>>>>
>>>> Pascual Sokolsky schrieb:
>>>>> Mild Shock wrote:
>>>>>
>>>>>> But in principle the architecture is rather:
>>>>>>
>>>>>> parallel random-access machine (parallel RAM or PRAM) is a
>>>>>> shared-memory abstract machine.
>>>>>> https://en.wikipedia.org/wiki/Parallel_RAM
>>>>>>
>>>>>> The above class of machines is not widely know.
>>>>>> But PRAM has been also studied, already in the 80's.
>>>>>
>>>>> parallel read of shared memory is only allowed to cia and the chinese
>>>>> governoment; must be somenthing you dont know
>>>
>>> from shared memory you only read and write sequential, me frendo,
>>> driven by semaphores, atomic instructions and so on. You are not that
>>> fucking stupid to write parallel to a cell, are you
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#15085 — POINT OF VIEW OF AN ALGORITHM (Re: Algorithm introduced in Hogwild! SGD (Niu et al., 2011)) (Re: parallel random-access machine)

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.
> 

[toc] | [prev] | [next] | [standalone]

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

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.
>>
> 

[toc] | [prev] | [next] | [standalone]

#15087 — Sputnik Schock: Academia is Disposable [I. J. Good Ultraintelligence] (Was: Introduction to AMBA® 4 ACE™ (2011))

Hi,

Looking at how they phrase it:

"symposium focuses on improving the programming
productivity and performance engineering of all
concurrent and parallel systems—multicore, multi-
threaded, heterogeneous, clustered, and distributed
systems, grids, accelerators such as ASICs, GPUs,
FPGAs, data centers, clouds, large scale machines,
and quantum computers. PPoPP is also interested in
new and emerging parallel workloads and applications,
such as artificial intelligence and large-scale
scientific/enterprise workloads."
https://ppopp26.sigplan.org/track/PPoPP-2026-papers

It could be also that academia was overrun by the AI boom.
Is lost in the nowhere. That the techno lords have
created realities turning the academia into savages.

No wonder there is a call for automated AI researchers,
and automated AI engineers, by the AI industry itself.
And which might be the outcome of the current manhatten

project, also known as genesis mission. So that the AI
can be programmed by AI, AI which is more knowledgable
than tiny accademics. We are maybe heading towards a

first Ultraintelligence, that will then shape subsequent
Ultraintelligences. As described by I. J. Good:

"Let an ultraintelligent machine be defined as a machine
that can far surpass all the intellectual activities of
any man however clever. Since the design of machines is
one of these intellectual activities, an ultraintelligent
machine could design even better machines; there would
then unquestionably be an 'intelligence explosion,' and
the intelligence of man would be left far behind...
Thus the first ultraintelligent machine is the last
invention that man need ever make, provided that the
machine is docile enough to tell us how to keep it under
control. It is curious that this point is made so
seldom outside of science fiction. It is sometimes
worthwhile to take science fiction seriously."
https://exhibits.stanford.edu/feigenbaum/catalog/gz727rg3869

Bye

Mild Shock schrieb:
> 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.
>>>
>>
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.prolog

csiph-web