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

Groups > comp.lang.lisp > #61379

The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels])

Cross-posted to 3 groups.

Show all headers | View raw

Hi,

We didn't find yet a library for our Think that
would support webgpu on the ARM architecture,
so its back to the browser flag and testing there.

The node.js package comes only with:

dist
+-- d3dcompiler_47.dll
+-- darwin-universal.dawn.node
+-- linux-arm64.dawn.node
+-- linux-x64.dawn.node
+-- win32-x64.dawn.node

Its a similar situation like with SVN. In some
communities its not common to provide a ARM build.
They rather use x86 till the end of the universe.

Although we think initiatives like the x86 Ecosystem
Advisory Group could be a clever marketing trick to
hide a funeral service. Adding "luminaries" such as

Tim Sweeney and Linus Torvald to the panel, is even
more so a joke, given that intel produces mutex bottlenecks
instead of futex, where f stands for fast, in their GPU

infrastructure. So who is the teacher and who are
the students? But why even try to create a collation
against ARM, it doesn't make any sense.

Bye

Mild Shock schrieb:
> Hi,
> 
> Now I implemented some multiple producer
> and multiple consumer channel objects for
> WebGPU. The only API to integrate it user
> 
> facing into pi-WAM is this single predicate:
> 
> /**
>   * flit(C):
>   * The predicate succeeds in C with a new channel. The channel
>   * can be used from within GPU backed π-WAM logical threads.
>   */
> 
> The Mac Neo is a Budget Monster. While the
> Ryzen AI Laptop cost around 1300.- CHF.
> The Mac Neo was around 600.- CHF with all
> 
> extras. Here some performance results,
> checking out whether channel objects scale,
> when increasing their number to
> 
> communicate the same 1 millon packets:
> 
> Java performance:
> 
> AI Laptop    Single    Double
> Ryzen    705.1    337.4
> Neo    669.4    239.9
> 
> WebGPU performance:
> 
> AI Laptop    Single    Double
> Ryzen    731.8    392.9
> Neo    932.8    483.5
> 
> Cool! Java is also pretty cool, their
> semaphore library is top notch. I couldn't
> replicate the resulst with JavaScript yet,
> 
> seems their Atomics.wait() resp. Atomics.waitAsync()
> is totally broken, using futex is mutex for
> fools somehow. I also found some gremlins
> 
> attacking one of the GPUs. The Intel AI Laptop
> fails the above experiment. Maybe its a driver
> Vulkan versus OpenCL or something problem,
> 
> or the Lunar lake architecture is nonsense.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Recently there was a paper somebody mentioning
>> a flit doing a ACK or NACK, to express
>> backpressure inside a Network on a Chip.
>>
>> But what is a flit? It seems multiple
>> flits can be used to create the message
>> passing in one directiob before the
>>
>> ACK or NACK in the other direction?
>>
>> "The growing need for performance from
>> computing systems drove the industry into
>> the multi-core and many-core arena. In this
>> setup, the execution of a kernel (a program)
>> is split across multiple processors and the
>> computation happens in parallel
>>
>> Flits represent logical units of information,
>> while phits represent the physical domain,
>> that is, phits represent the number of bits
>> that can be transferred in parallel in a
>> single cycle. Consider the Cray T3D. It has
>> an interconnection network which uses
>>
>> flit level message flow control wherein each
>> flit is composed of eight 16-bit phits. That
>> means its flit size is 128bits and phit size
>> is 16bits. Also consider the IBM SP2 switch.
>> It also uses the flit level message flow
>> control, but its flit size is equal to its
>> phit size, which is set to 8 bits."
>> https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example
>>
>> Well my idea how this is realized in silicon
>> is rather foggy, I mean even the Hack project
>> from Nand 2 Tetris, does not show some gate level
>> schemes for flits and phits.
>>
>> Could be an interesting extension. But somehow
>> the image of flits and phits inspired my channel
>> objects here below. But I am afraid they are fire
>> and forget, no ACK and NACK:
>>
>> π-WAM Contest: 1 Million Packets with Prolog
>> https://medium.com/2989/ec3e91551773
>>
>> Its amazing that a max_size(1) buffer
>> can beat an unbounded buffer!
>>
>> LoL
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> How it started, NVIDIA being cool:
>>>
>>> NCCL provides routines such as all-gather,
>>> all-reduce, broadcast, reduce, reduce-scatter,
>>> and point-to-point send and receive. These
>>> routines are optimized to achieve high
>>> bandwidth and low latency over PCIe,
>>> NVIDIA NVLink™, and other high-speed
>>> interconnects within a node and over
>>> NVIDIA networking across nodes.
>>> https://developer.nvidia.com/nccl
>>>
>>> How its going, vLLM trying to be cool:
>>>
>>> [RFC]: Native Weight Syncing APIs
>>> However, there are no standardized methods for
>>> performing online weight syncing. Open source projects
>>> like SkyRL, VeRL, and TRL need to include their
>>> own implementations of the weight syncing
>>> infrastructure, leading to added complexity
>>> for developers seeking to adopt vLLM as their
>>> inference server for post-training workloads.
>>> https://github.com/vllm-project/vllm/issues/31848
>>>
>>> How much Workers are enough? I guess it depends
>>> on I/O parallelism, CPU Memory parallelism, CPU
>>> Processing parallelism, and now also
>>>
>>> GPU Memory parallelism and GPU Processing
>>> parallelism, and last but least you might have
>>> a couple DMAs sitting here and there,
>>>
>>> or even invoking a sort of RDMA. Quite amazing!
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> Well there are two viewpoint, the "client"
>>>> of the GPU, which is the CPU, and the "server"
>>>> of the GPU, which is the command processor
>>>>
>>>> queue of the GPU device. So basically as
>>>> a CPU client I can write the memory area,
>>>> that is later mapped to my GPU code storage.
>>>>
>>>> And this way have a compiler, even written
>>>> in Prolog, that compiles pi-WAM to my Hack VM,
>>>> that can then be then deployed to GPU.
>>>>
>>>> You could also try the same with a Tiny
>>>> LISP VM. And a grown up LISP to act as
>>>> the compiler. Would be a similar exercise.
>>>>
>>>> Have Fun!
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>> Hi,
>>>>>
>>>>>  > I've also added comp.theory so Mild Shock can comment.
>>>>>
>>>>>  > that has different
>>>>>  > *  sizeof ( void * ), and
>>>>>  > *  sizeof ( void (*)( void ) ),
>>>>>
>>>>> Could indicate a data RAM and code ROM model.
>>>>> Which has then the advantage of:
>>>>>
>>>>> Modern operating systems like Windows 11
>>>>> enforce strict Data Execution Prevention (DEP)
>>>>> (or NX/XD bit security features) to prevent
>>>>> malicious programs from injecting and executing
>>>>> code inside data-only memory regions.
>>>>> https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/
>>>>>
>>>>> I adopted data RAM and code ROM model for
>>>>> pi-WAM from Hack, which has the same separation:
>>>>>
>>>>> Slide 58, Hack Computer
>>>>> https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view
>>>>>
>>>>> But my motivation was not Johnny Depp prevention.
>>>>> Rather the caching of GPUs. Because WGSL
>>>>> allows storage annotations read_write and
>>>>>
>>>>> read. I use read_write for the data RAM
>>>>> of my Hack VM variant, and read for the
>>>>> code ROM of my Hack VM variant. You can
>>>>>
>>>>> see that here, its open source:
>>>>>
>>>>> @group(0) @binding(0) var<storage, read> code: array<i32>;
>>>>> @group(0) @binding(1) var<storage, read_write> state: array<i32>;
>>>>>
>>>>> 11.4 Giga Lips with a Budget Laptop
>>>>> https://github.com/Jean-Luc-Picard-2021/gigabudget
>>>>>
>>>>> Hope this Helps!
>>>>>
>>>>> Bye
>>>>>
>>>>> Johann 'Myrkraverk' Oskarsson schrieb:
>>>>>> On 03/08/2026 6:28 PM, David Brown wrote:
>>>>>>> On 03/08/2026 11:41, Richard Harnden wrote:
>>>>>>>> On 03/08/2026 09:16, David Brown wrote:
>>>>>>>
>>>>>>>>> On most targets, function pointers are the same size as void* 
>>>>>>>>> pointers. But there are exceptions, with some small 
>>>>>>>>> microcontrollers and DSPs having different kinds of pointers 
>>>>>>>>> with different sizes, depending on the memory space involved.  
>>>>>>>>> I have yet to see a situation where there was any reason for 
>>>>>>>>> storing a function address in a "void*" rather than a more 
>>>>>>>>> appropriate typedef, such as :
>>>>>>>>>
>>>>>>>>>      typedef void (*FVoid)(void);
>>>>>>>>
>>>>>>>> dlsym requires that pointer-to-function is compatible with a void*
>>>>>>>>
>>>>>>>
>>>>>>> As I say, I have yet to see a situation where using void* for 
>>>>>>> function pointers was more appropriate than using a function 
>>>>>>> pointer type.  If the OS system calls or standard OS libraries 
>>>>>>> makes it a requirement that function pointers are converted to or 
>>>>>>> from void* for some calls, then of course you need to follow 
>>>>>>> those requirements - it's the people who designed the interfaces 
>>>>>>> that made questionable design choices.
>>>>>>>
>>>>>>
>>>>>> Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
>>>>>> even though here in comp.lang.c we like to pretend it is.
>>>>>>
>>>>>> Several language environments allow function generation on the fly,
>>>>>> these functions need to be garbage collected.  Common Lisp is an
>>>>>> example, therefore comp.lang.lisp is added to this discussion.
>>>>>>
>>>>>> I've also added comp.theory so Mild Shock can comment.
>>>>>>
>>>>>> You will have to go out of your way to make a computer architecture
>>>>>> incompatible with garbage collected and heap allocated binary code,
>>>>>> something I've been told SBCL does internally [1] to create an archi-
>>>>>> tecture that has different
>>>>>>
>>>>>> *  sizeof ( void * ), and
>>>>>> *  sizeof ( void (*)( void ) ),
>>>>>>
>>>>>> and when you do that, I'll just claim you're making a /malicious
>>>>>> computer architecture/ and refuse to use it.
>>>>>>
>>>>>>
>>>>>> [1] I've not looked at the code, but told the garbage collector can
>>>>>> and will at least move the code around, if not collect it.
>>>>>
>>>>
>>>
>>
> 

Back to comp.lang.lisp | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
  Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
  Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
    But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
      GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
        What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
          Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
          The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
            The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
  Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
    Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
      Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
      Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
        Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
      Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
        Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:45 +0800
    Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 18:13 +0000
      Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:48 +0800
        Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 22:01 +0000
          Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 06:25 +0800
  A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
    The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200

csiph-web