Conversation

Notices

1. Embed this notice
   Kornel (kornel@mastodon.social)'s status on Thursday, 17-Apr-2025 10:21:22 JST Kornel

   What if C isn't portable, only non-C-compatible architectures went extinct?

   I'm half joking, but:

   VLIW/EPIC architectures are dead, despite CPUs desperately needing instruction-level parallelism.
   Instead of SIMT we have hyperthreading at home, and bug-prone threads with context switching in software.
   Instead of hierarchical memory, we waste 8 bytes on all pointers & emulate thread-local memory in software. Larabee was DOA & SIMD barely exists. MOS6502-style stack+registers are only on GPUs.

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Thursday, 17-Apr-2025 14:17:30 JST Alfred M. Szmidt

     in reply to

     • Artemis

     @kornel >When LISP and LISP machines were hot, RAM access took exactly 1 CPU cycle.

     No it did not.

     @artemissian

   • Embed this notice
     Artemis (artemissian@mastodon.social)'s status on Thursday, 17-Apr-2025 14:17:31 JST Artemis

     in reply to

     @kornel "A processor designed purely for speed, not for a compromise between speed and C support, would likely support large numbers of threads, have wide vector units, and have a much simpler memory model. Running C code on such a system would be problematic, so, given the large amount of legacy C code in the world, it would not likely be a commercial success."
     — https://cacm.acm.org/practice/c-is-not-a-low-level-language/

     I wonder what a Lisp machine using current technology would be like? Designed from the ground up for Lisp

   • Embed this notice
     Kornel (kornel@mastodon.social)'s status on Thursday, 17-Apr-2025 14:17:31 JST Kornel

     in reply to

     • Artemis

     @artemissian LISP is pointer-heavy. When LISP and LISP machines were hot, RAM access took exactly 1 CPU cycle. Now it takes ~300 cycles. Maybe some purely-functional flavor could be made to work, but that's beyond my imagination.

     The current state favors data-centric embarrassingly parallel programs with minimal pointer indirections.

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Thursday, 17-Apr-2025 14:21:28 JST Alfred M. Szmidt

     in reply to

     • Artemis

     @artemissian >I wonder what a Lisp machine using current technology would be like? Designed from the ground up for Lisp

     You'd need to define "Lisp Machine" in more detail, are we talking about the stack macrocode machine (which is just a virtual machine); or are we talking about the underlying microcode processor which is just a RISC like machine?

     @kornel

   • Embed this notice
     Kornel (kornel@mastodon.social)'s status on Thursday, 17-Apr-2025 20:48:18 JST Kornel

     in reply to

     • Alfred M. Szmidt

     @amszmidt Really? I did not expect them to do worse than C64.

     Anyway, my point was that CPU clock speeds used to be close to DRAM speeds. Until mid 80s CPUs didn't even need to have caches.

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Thursday, 17-Apr-2025 22:39:35 JST Alfred M. Szmidt

     in reply to

     @kornel Not sure how doing memory access in more than a cycle is "worse than C64". The CADR did not use DRAM, it was all SRAM (with a typical access time of 50ns); the cycle was around 200ns -- variable at that. But there are other memories, and there is propagation time, and need to settle things between data paths.

     Plus, we are talking about a machine that was made in the mid-70s, with high resolution monitors, an actual programming language for doing useful stuff, etc...