Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400344 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2026-07-22 01:38 +0200 |
| Last post | 2026-07-23 11:18 +0200 |
| Articles | 20 on this page of 205 — 24 participants |
Back to article view | Back to comp.lang.c
Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 01:38 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 17:26 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 01:50 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 20:25 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 17:37 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-22 13:26 -0700
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 07:33 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-22 10:41 +0200
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-22 18:08 -0500
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-23 10:31 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:31 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:48 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 15:11 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 09:23 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 03:14 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-24 14:56 +0000
Re: Prioritize Performance over Correctness antispam@fricas.org (Waldek Hebisch) - 2026-07-25 16:30 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 09:33 -0400
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 00:22 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 12:58 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:37 -0500
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 17:13 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 15:17 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 01:18 +0000
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:40 +0800
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:18 +0000
Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 22:48 +0800
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 15:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 23:30 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 19:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:08 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:15 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:26 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 06:41 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:23 +0000
Picture of Organicks' book Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:01 +0800
Re: Picture of Organicks' book cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-29 13:46 +0000
Re: Picture of Organicks' book R Kym Horsell <kymhorsell@gmail.com> - 2026-07-29 16:54 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-29 23:22 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 15:55 -0700
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 18:58 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:10 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:20 +0000
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-29 14:44 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-30 02:08 +0000
Re: Prioritize Performance over Correctness dave_thompson_2@comcast.net - 2026-09-15 21:16 -0400
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-15 22:05 -0400
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 14:37 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:14 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 05:45 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:59 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 17:59 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:42 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 03:22 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 19:21 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 13:02 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 20:18 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 14:17 +0100
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-28 16:02 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:45 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 12:03 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 19:32 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 13:42 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 20:49 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 16:01 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 12:53 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-31 14:21 -0400
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-31 20:07 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-31 13:00 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 02:34 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 16:08 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:28 +0000
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:22 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:51 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:32 -0400
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:20 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:54 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:00 +0800
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:25 -0400
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:55 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:31 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 21:26 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:57 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 15:33 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 16:22 -0700
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-07-30 07:40 +0100
Re: Prioritize Correctness over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 06:48 +0000
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:50 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:54 -0700
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 08:24 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:40 -0700
Re: Prioritize Correctness over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:39 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:44 -0400
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:00 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:38 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:53 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 15:10 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:40 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-31 02:43 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:44 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:58 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 01:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-02 23:14 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-02 14:37 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-02 22:51 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 16:43 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 12:03 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-03 23:49 +0000
Re: Prioritize Correctness Over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:35 -0700
MS-DOS memory models (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 08:08 +0800
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 10:16 +0200
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-03 10:41 +0100
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 12:28 +0200
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 David Brown <david.brown@hesbynett.no> - 2026-08-03 14:01 +0200
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 22:52 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 19:41 +0200
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:13 -0700
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:10 -0700
Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Re: Malicious Computer Architecture Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:26 -0300
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
Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:32 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Anthk GM <anthk@disroot.org> - 2026-09-15 17:10 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 18:08 +0000
You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-09-15 20:21 +0200
Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 20:05 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 02:08 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 15:25 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 16:28 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-08-23 01:48 +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 Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:21 +0800
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
GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:37 -0300
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
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:34 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:04 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-04 00:52 +0000
Re: Prioritize Correctness Over Performance scott@slp53.sl.home (Scott Lurndal) - 2026-08-04 14:22 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 15:10 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:16 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-03 20:29 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 17:55 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-04 09:12 +0200
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-21 05:49 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-21 10:38 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 18:25 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-24 10:15 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 19:01 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-03 19:59 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:50 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 15:09 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 08:14 +0800
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:54 +0800
Re: Prioritize Performance over Correctness steveo@panix.com (Steven M. O'Neill) - 2026-07-31 20:34 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 19:40 -0400
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:36 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:56 +0800
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-24 14:47 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 16:27 +0200
Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 00:52 +0800
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-24 23:08 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-24 18:50 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 01:54 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:20 +0800
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 07:24 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:30 +0800
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:37 +0200
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:35 +0800
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 12:39 -0500
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-26 22:27 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 18:02 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 22:32 +0000
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:58 -0700
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:23 +0200
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:29 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:25 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:33 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:38 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-26 17:06 -0700
Re: Resources for Amateur Compiler Writers Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-26 17:03 +0000
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-24 16:50 -0500
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:13 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-26 15:26 -0500
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-23 11:18 +0200
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-09-03 14:26 -0300 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <87zexyz1o0.fsf@debian> |
| In reply to | #400744 |
scott@slp53.sl.home (Scott Lurndal) writes: > Hey dipshit, you're responding to a post in comp.lang.c and > cross-posting your reply to other unrelated groups. Please don't > do that. My, my.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-03 18:10 +0200 |
| Subject | Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) |
| Message-ID | <114qei6$t1uc$1@solani.org> |
| In reply to | #400738 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-03 18:15 +0200 |
| Subject | But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) |
| Message-ID | <114qerq$t244$1@solani.org> |
| In reply to | #400751 |
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. >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-07 14:37 +0200 |
| Subject | GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) |
| Message-ID | <1154jip$296j$3@solani.org> |
| In reply to | #400752 |
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. >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-07 18:07 +0200 |
| Subject | What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) |
| Message-ID | <1154vsi$2mto$3@solani.org> |
| In reply to | #400915 |
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. >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-09 21:22 +0200 |
| Subject | Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) |
| Message-ID | <115ak0p$6g3f$3@solani.org> |
| In reply to | #400917 |
Hi, How it started: Filming a vitamin B12 photoreceptor in action https://www.psi.ch/de/news/science-features/filming-a-vitamin-b12-photoreceptor-in-action How its going: Elon Musk's potential FEL route could challenge EUV lithography https://www.kucoin.com/news/flash/elon-musk-s-potential-fel-route-could-challenge-euv-lithography Who will win the Nano Atom mover race, will the USA OutChip its competitor China and its supplier Asia in the next years? 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. >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-18 16:26 +0200 |
| Subject | Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <1161q20$mbl1$3@solani.org> |
| In reply to | #400936 |
Hi, Sometimes I think the Loderunner Enemy AI was way ahead of its time: Lode Runner - Broderbund - 1983 - Apple II https://www.youtube.com/watch?v=pJZJepU8law Meanwhile SWI-Prolog Prologers even don't know whether a Prolog text is CNF or DNF: Sets of rules as conjunctions and/or disjunctions https://swi-prolog.discourse.group/t/sets-of-rules-as-conjunctions-and-or-disjunctions/9779 No Wonder that the EyeProlog "why" feature produces nonsense. Even a Flea circus is less crazy. Bye P.S.: If only there would exist something like universities where one can take a basic course in FOL, and then a world wide web, where one can lookup clark equational theory, clark completion, curry howard correspondence, etc.. etc.. Mild Shock schrieb: > Hi, > > Obviously to generate AI Surprises, > you have to stand on the shoulder of > giants. Otherwise you will not discover > > surprises, right? Only mediocre deja vues. > For this purpose, and maybe otherwise > related, in a discussion concerning the future > > of the library, Marvin Minsky and Edward A. > Feigenbaum endorsed the idea for books > to ‘talk to each other’: > > LET DOCUMENTS TALK TO EACH OTHER > Z. CHEN - 1993 > doi.org/10.1108/eb026910 > > Now we have: > > THE MACHINES ARE STUDYING > THE HUMANS ARE SCROLLING > https://9gag.com/gag/a9yQ16o > > Bye > > P.S.: But who was Marvin Minsky, and would it > be important to use symbolic AI? > > The Perceptron Controversy > Yuxi Liu - 2024 > https://yuxi.ml/essays/perceptron-controversy > > Mild Shock schrieb: >> Hi, >> >> How it started: >> >> Filming a vitamin B12 photoreceptor in action >> https://www.psi.ch/de/news/science-features/filming-a-vitamin-b12-photoreceptor-in-action >> >> >> How its going: >> >> Elon Musk's potential FEL route could challenge EUV lithography >> https://www.kucoin.com/news/flash/elon-musk-s-potential-fel-route-could-challenge-euv-lithography >> >> >> Who will win the Nano Atom mover race, >> >> will the USA OutChip its competitor China >> and its supplier Asia in the next years? >> >> 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. >>>>>> >>>>> >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-18 16:50 +0200 |
| Subject | How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <1161reu$mcl7$2@solani.org> |
| In reply to | #401296 |
Hi, The biggest joke, is to have logic somewhere in procedure and somewhere in declarative, and try to see different takes on logic. They really don't know what this mantra means: Algorithm = Logic + Control And cannot relate it to the ideas of declarative reading and procedural reading. The problem is a too lax introduction of this notions, prematurely before the notion "logic" is even understood. But nobody understands the meaning of the term "logic", i.e. a set of supposedly tautological sentences, as under- stood by mathematical logic. There is a subtle error again to conflate it with a "calculus", so this website has a very misleanding title, although they try hard to not commit the fallacy, and have subtitles "Proof System" and "Logic Level": Welcome to LogicProof https://6ximik9.github.io/naturalDeduction/ Then there is this moron: There is only one “minimal logic”. The term denotes Johansson’s Minimalkalkül [1937] — intuitionistic logic without ex falso quodlibet — and nothing else. No rival system competes for the name. https://vidal-rosset.net/rule-correspondence-F.html Of course there are rival "Proof Systems" aka calculi, even when the "Logic Level" is minimal logic. It is as if Joseph Vidal-Rosset doesn't understand basic German. You have to look behind "Minimalkalkül" to find "Minimallogic". Right? To identify calculus with logic, is maybe a 1930's fallacy, but then we had model theory besides proof theory, and people should be more educated now. Model theory can be also expanded to non-classical logics and even minimal logic, to give a purely semantic reading. Ok some modern morons think they need to invoke the word "algebraic". Bye Mild Shock schrieb: > Hi, > > Sometimes I think the Loderunner Enemy AI > was way ahead of its time: > > Lode Runner - Broderbund - 1983 - Apple II > https://www.youtube.com/watch?v=pJZJepU8law > > Meanwhile SWI-Prolog Prologers even don't know > whether a Prolog text is CNF or DNF: > > Sets of rules as conjunctions and/or disjunctions > https://swi-prolog.discourse.group/t/sets-of-rules-as-conjunctions-and-or-disjunctions/9779 > > > No Wonder that the EyeProlog "why" feature produces > nonsense. Even a Flea circus is less crazy. > > Bye > > P.S.: If only there would exist something like > universities where one can take a basic course in > FOL, and then a world wide web, where one can > > lookup clark equational theory, clark completion, > curry howard correspondence, etc.. etc.. > > Mild Shock schrieb: >> Hi, >> >> Obviously to generate AI Surprises, >> you have to stand on the shoulder of >> giants. Otherwise you will not discover >> >> surprises, right? Only mediocre deja vues. >> For this purpose, and maybe otherwise >> related, in a discussion concerning the future >> >> of the library, Marvin Minsky and Edward A. >> Feigenbaum endorsed the idea for books >> to ‘talk to each other’: >> >> LET DOCUMENTS TALK TO EACH OTHER >> Z. CHEN - 1993 >> doi.org/10.1108/eb026910 >> >> Now we have: >> >> THE MACHINES ARE STUDYING >> THE HUMANS ARE SCROLLING >> https://9gag.com/gag/a9yQ16o >> >> Bye >> >> P.S.: But who was Marvin Minsky, and would it >> be important to use symbolic AI? >> >> The Perceptron Controversy >> Yuxi Liu - 2024 >> https://yuxi.ml/essays/perceptron-controversy >> >> Mild Shock schrieb: >>> Hi, >>> >>> How it started: >>> >>> Filming a vitamin B12 photoreceptor in action >>> https://www.psi.ch/de/news/science-features/filming-a-vitamin-b12-photoreceptor-in-action >>> >>> >>> How its going: >>> >>> Elon Musk's potential FEL route could challenge EUV lithography >>> https://www.kucoin.com/news/flash/elon-musk-s-potential-fel-route-could-challenge-euv-lithography >>> >>> >>> Who will win the Nano Atom mover race, >>> >>> will the USA OutChip its competitor China >>> and its supplier Asia in the next years? >>> >>> 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. >>>>>>> >>>>>> >>>>> >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-19 03:24 +0800 |
| Subject | Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <0k2hS.765207$jNNe.305662@fx15.ams4> |
| In reply to | #401297 |
On 18/08/2026 10:50 PM, Mild Shock wrote: > Hi, > > The biggest joke, is to have logic somewhere > in procedure and somewhere in declarative, and > try to see different takes on logic. > > They really don't know what this mantra means: > > Algorithm = Logic + Control > > And cannot relate it to the ideas of declarative > reading and procedural reading. The problem is > a too lax introduction of this notions, > > prematurely before the notion "logic" is > even understood. But nobody understands the > meaning of the term "logic", i.e. a set of > > supposedly tautological sentences, as under- > stood by mathematical logic. There is a subtle > error again to conflate it with a "calculus", > > so this website has a very misleanding title, > although they try hard to not commit the fallacy, > and have subtitles "Proof System" and "Logic Level": > > Welcome to LogicProof > https://6ximik9.github.io/naturalDeduction/ > > Then there is this moron: > > There is only one “minimal logic”. The term denotes Johansson’s > Minimalkalkül [1937] — intuitionistic logic without ex falso quodlibet — > and nothing else. No rival system competes for the name. > https://vidal-rosset.net/rule-correspondence-F.html > > Of course there are rival "Proof Systems" aka > calculi, even when the "Logic Level" is minimal > logic. It is as if Joseph Vidal-Rosset doesn't > > understand basic German. You have to look behind > "Minimalkalkül" to find "Minimallogic". Right? > To identify calculus with logic, is maybe a 1930's > > fallacy, but then we had model theory besides > proof theory, and people should be more educated > now. Model theory can be also expanded to > > non-classical logics and even minimal logic, to > give a purely semantic reading. Ok some modern > morons think they need to invoke the word "algebraic". > All my graphic art in CorelDRAW! is done with algebraic curves. I found the regular Bezier curves simply boring, and /upgraded/ my curvatures to /algebraic/. Do you also draw with algebraic curves in your vector drawing utility of choice? Is it Xfig? -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-19 03:21 +0800 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <Ug2hS.182070$nUE4.143102@fx07.ams4> |
| In reply to | #401296 |
On 18/08/2026 10:26 PM, Mild Shock wrote: > Hi, > > Sometimes I think the Loderunner Enemy AI > was way ahead of its time: > > Lode Runner - Broderbund - 1983 - Apple II > https://www.youtube.com/watch?v=pJZJepU8law > > Meanwhile SWI-Prolog Prologers even don't know > whether a Prolog text is CNF or DNF: Are you coding the SWI interfaces in RISC OS in Prolog? Isn't it much more fruitful to code it in the /Acorn RISC Machine/ assembly? > > Sets of rules as conjunctions and/or disjunctions > https://swi-prolog.discourse.group/t/sets-of-rules-as-conjunctions-and- > or-disjunctions/9779 So, is this set of conjunctions and disjunctions about how to create set intersections and unions of windows on RISC OS? Why is that important? > > No Wonder that the EyeProlog "why" feature produces > nonsense. Even a Flea circus is less crazy. Does wearing an eye patch help when writing Prolog? I ask because I have never coded any Prolog before. Corollary, since an eye patch would hide my central heterochromia, would that not hinder my ability to reason? > > Bye > > P.S.: If only there would exist something like > universities where one can take a basic course in > FOL, and then a world wide web, where one can What is F.O.L? > > lookup clark equational theory, clark completion, > curry howard correspondence, etc.. etc.. You can always complete your journey at the Clark International Airport in the Philippines. Let me know when you do. As always, you've been greatly helpful, and mildly amusing, Mild Shock! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| Date | 2026-08-18 21:13 +0100 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <27268.48342.40320.549939@parhasard.net> |
| In reply to | #401301 |
Ar an naoú lá déag de mí Lúnasa, scríobh Johann Oskarsson: > On 18/08/2026 10:26 PM, Mild Shock wrote: > > [...] No Wonder that the EyeProlog "why" feature produces > > nonsense. Even a Flea circus is less crazy. > > Does wearing an eye patch help when writing Prolog? I ask because I > have never coded any Prolog before. I coded Prolog in 1998-1999. It is not oriented to the underlying machine in any useful way, and its syntax is not human-friendly. I don’t recommend it. > Corollary, since an eye patch would hide my central heterochromia, would > that not hinder my ability to reason? No comment. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after fourteen pints of stout’ (C. Moore)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-18 22:49 +0000 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <1162nhe$26tip$5@dont-email.me> |
| In reply to | #401305 |
On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: > I coded Prolog in 1998-1999. It is not oriented to the underlying > machine in any useful way, and its syntax is not human-friendly. I > don’t recommend it. I did briefly flirt with it, a decade earlier. I found it “very high level”, in that its brute-force pattern-matching-plus-backtracking execution paradigm was well-suited to solving certain kinds of logic problems (it’s in the name of the language after all). Though I guess you’d get a blowup in execution time and memory in more complex real-world situations. You know the old “Who Owns The Zebra?” logic puzzle (or some variant thereof)? You basically code the given clues directly into Prolog, run the result as a program, and out pops the answer.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-19 08:32 +0800 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <NQ6hS.1098979$la89.205442@fx06.ams4> |
| In reply to | #401315 |
On 19/08/2026 6:49 AM, Lawrence D’Oliveiro wrote: > On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: > >> I coded Prolog in 1998-1999. It is not oriented to the underlying >> machine in any useful way, and its syntax is not human-friendly. I >> don’t recommend it. > > I did briefly flirt with it, a decade earlier. I found it “very high > level”, in that its brute-force pattern-matching-plus-backtracking > execution paradigm was well-suited to solving certain kinds of logic > problems (it’s in the name of the language after all). Though I guess > you’d get a blowup in execution time and memory in more complex > real-world situations. > > You know the old “Who Owns The Zebra?” logic puzzle (or some variant > thereof)? You basically code the given clues directly into Prolog, run > the result as a program, and out pops the answer. Dear Lawrence, Have you thought to code yourself as a logical puzzle solving character in text adventures, with or without the help of Prolog? Do you think you can do so without ever mentioning Python? Or do you love snakes so much you cannot live without it? Are you perhaps a graduate of the Slitherin magical university? I have added rec.arts.int-fiction to this discussion, and alt.fantasy, even though we don't discuss Slitherins there. Happy coding yourself in a text adventure game! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Anthk GM <anthk@disroot.org> |
|---|---|
| Date | 2026-09-15 17:10 +0000 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <slrn118buud.mqi.anthk@hyperbola.home> |
| In reply to | #401319 |
On 2026-08-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: > On 19/08/2026 6:49 AM, Lawrence D’Oliveiro wrote: >> On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: >> >>> I coded Prolog in 1998-1999. It is not oriented to the underlying >>> machine in any useful way, and its syntax is not human-friendly. I >>> don’t recommend it. >> >> I did briefly flirt with it, a decade earlier. I found it “very high >> level”, in that its brute-force pattern-matching-plus-backtracking >> execution paradigm was well-suited to solving certain kinds of logic >> problems (it’s in the name of the language after all). Though I guess >> you’d get a blowup in execution time and memory in more complex >> real-world situations. >> >> You know the old “Who Owns The Zebra?” logic puzzle (or some variant >> thereof)? You basically code the given clues directly into Prolog, run >> the result as a program, and out pops the answer. > > Dear Lawrence, > > Have you thought to code yourself as a logical puzzle solving character > in text adventures, with or without the help of Prolog? > > Do you think you can do so without ever mentioning Python? Or do you > love snakes so much you cannot live without it? Are you perhaps a > graduate of the Slitherin magical university? > > I have added rec.arts.int-fiction to this discussion, and alt.fantasy, > even though we don't discuss Slitherins there. > > > Happy coding yourself in a text adventure game! There's a clause based language called Dialog which is Prolog's cousing (think something like CLIPS, constraint based solvers): It targets the Z-Machine, like Inform6: https://linusakesson.net/dialog/ Intro https://dialog-if.github.io/manual/dialog/0m03/intro.html
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-15 18:08 +0000 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <YQfqS.118094$3vg8.60241@fx37.iad> |
| In reply to | #402099 |
Anthk GM <anthk@disroot.org> writes: >On 2026-08-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> On 19/08/2026 6:49 AM, Lawrence D’Oliveiro wrote: >>> On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: >>> >>>> I coded Prolog in 1998-1999. It is not oriented to the underlying >>>> machine in any useful way, and its syntax is not human-friendly. I >>>> don’t recommend it. >>> >>> I did briefly flirt with it, a decade earlier. I found it “very high >>> level”, in that its brute-force pattern-matching-plus-backtracking >>> execution paradigm was well-suited to solving certain kinds of logic >>> problems (it’s in the name of the language after all). Though I guess >>> you’d get a blowup in execution time and memory in more complex >>> real-world situations. >>> >>> You know the old “Who Owns The Zebra?” logic puzzle (or some variant >>> thereof)? You basically code the given clues directly into Prolog, run >>> the result as a program, and out pops the answer. >> >> Dear Lawrence, >> >> Have you thought to code yourself as a logical puzzle solving character >> in text adventures, with or without the help of Prolog? >> >> Do you think you can do so without ever mentioning Python? Or do you >> love snakes so much you cannot live without it? Are you perhaps a >> graduate of the Slitherin magical university? >> >> I have added rec.arts.int-fiction to this discussion, and alt.fantasy, >> even though we don't discuss Slitherins there. >> >> >> Happy coding yourself in a text adventure game! > >There's a clause based language called Dialog which is >Prolog's cousing (think something like CLIPS, constraint based >solvers): The first graphical MUD was built using the TUTOR language. https://en.wikipedia.org/wiki/TUTOR https://en.wikipedia.org/wiki/Dnd_(1975_video_game) https://en.wikipedia.org/wiki/Empire_(1973_video_game)
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-09-15 20:21 +0200 |
| Subject | You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) |
| Message-ID | <118c2b4$8nro$2@solani.org> |
| In reply to | #402101 |
Hi, Interesting. This PLATO ting from University of Illinois could maybe predate Hack: Dirk Pellett of Iowa State University and Flint Pellett of the University of Illinois made substantial enhancements to the game from 1976 to 1985 https://en.wikipedia.org/wiki/Dnd_%281975_video_game%29 Hack was created in 1982 by Jay Fenlason with the assistance of Kenny Woodland, Mike Thome, and Jonathan Payne, while students at Lincoln- Sudbury Regional High School. https://en.wikipedia.org/wiki/Hack_%28video_game%29 Bye BTW: Doom predecessor could have been this one: The first version was developed by high school students Steve Colley, Greg Thompson, and Howard Palmer for the Imlac PDS-1 minicomputer during a school work/study program at the NASA Ames Research Center. 3D multiplayer first-person shooter maze game https://en.wikipedia.org/wiki/Maze_%281973_video_game%29 Scott Lurndal schrieb: > Anthk GM <anthk@disroot.org> writes: >> On 2026-08-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> On 19/08/2026 6:49 AM, Lawrence D’Oliveiro wrote: >>>> On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: >>>> >>>>> I coded Prolog in 1998-1999. It is not oriented to the underlying >>>>> machine in any useful way, and its syntax is not human-friendly. I >>>>> don’t recommend it. >>>> >>>> I did briefly flirt with it, a decade earlier. I found it “very high >>>> level”, in that its brute-force pattern-matching-plus-backtracking >>>> execution paradigm was well-suited to solving certain kinds of logic >>>> problems (it’s in the name of the language after all). Though I guess >>>> you’d get a blowup in execution time and memory in more complex >>>> real-world situations. >>>> >>>> You know the old “Who Owns The Zebra?” logic puzzle (or some variant >>>> thereof)? You basically code the given clues directly into Prolog, run >>>> the result as a program, and out pops the answer. >>> >>> Dear Lawrence, >>> >>> Have you thought to code yourself as a logical puzzle solving character >>> in text adventures, with or without the help of Prolog? >>> >>> Do you think you can do so without ever mentioning Python? Or do you >>> love snakes so much you cannot live without it? Are you perhaps a >>> graduate of the Slitherin magical university? >>> >>> I have added rec.arts.int-fiction to this discussion, and alt.fantasy, >>> even though we don't discuss Slitherins there. >>> >>> >>> Happy coding yourself in a text adventure game! >> >> There's a clause based language called Dialog which is >> Prolog's cousing (think something like CLIPS, constraint based >> solvers): > > The first graphical MUD was built using the TUTOR > language. > > https://en.wikipedia.org/wiki/TUTOR > https://en.wikipedia.org/wiki/Dnd_(1975_video_game) > https://en.wikipedia.org/wiki/Empire_(1973_video_game) > > >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-15 20:05 +0000 |
| Subject | Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) |
| Message-ID | <FyhqS.41147$mg2f.11636@fx23.iad> |
| In reply to | #402102 |
Mild Shock <janburse@fastmail.fm> writes: >Hi, > >Interesting. This PLATO ting from University >of Illinois could maybe predate Hack: > >Dirk Pellett of Iowa State University >and Flint Pellett of the University of >Illinois made substantial enhancements Their father had a sense of humor. The third son was named Chert...
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-08-21 02:08 -0400 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <89pf8ll816is7kuhpjqjg8akpsou0sqvts@4ax.com> |
| In reply to | #401315 |
On Tue, 18 Aug 2026 22:49:18 -0000 (UTC), Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: > >> I coded Prolog in 1998-1999. It is not oriented to the underlying >> machine in any useful way, and its syntax is not human-friendly. I >> don’t recommend it. > >I did briefly flirt with it, a decade earlier. I found it “very high >level”, in that its brute-force pattern-matching-plus-backtracking >execution paradigm was well-suited to solving certain kinds of logic >problems (it’s in the name of the language after all). Though I guess >you’d get a blowup in execution time and memory in more complex >real-world situations. > >You know the old “Who Owns The Zebra?” logic puzzle (or some variant >thereof)? You basically code the given clues directly into Prolog, run >the result as a program, and out pops the answer. If the task involves a rule-based decision system, then Prolog can be a reasonable tool for the job. But in my experience most Prologs don't interface well - to the world, or to libraries written in other languages. Prolog uses backward chaining Horn logic - essentially you start with a [generic] "answer" in the form of a rule and look to see if the rule can be supported by facts in your database. Sometimes you want to work the other way, ie. go forward from facts to rules that are supported by them. Prolog can't do that. There are plenty of problems that can benefit from a Prolog-style rule system, but if you need one I think it is better to use an embeddable implementation, and write your main program in a language that is more suitable to interfacing with the world. There are embeddable Prologs and [Horn logic] workalike libraries available for a number of languages.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-21 15:25 +0800 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <D3ThS.205749$_cVb.160791@fx11.ams4> |
| In reply to | #401386 |
On 21/08/2026 2:08 PM, George Neuner wrote: > On Tue, 18 Aug 2026 22:49:18 -0000 (UTC), Lawrence D´Oliveiro > <ldo@nz.invalid> wrote: > >> On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: >> >>> I coded Prolog in 1998-1999. It is not oriented to the underlying >>> machine in any useful way, and its syntax is not human-friendly. I >>> don’t recommend it. >> >> I did briefly flirt with it, a decade earlier. I found it “very high >> level”, in that its brute-force pattern-matching-plus-backtracking >> execution paradigm was well-suited to solving certain kinds of logic >> problems (it’s in the name of the language after all). Though I guess >> you’d get a blowup in execution time and memory in more complex >> real-world situations. >> >> You know the old “Who Owns The Zebra?” logic puzzle (or some variant >> thereof)? You basically code the given clues directly into Prolog, run >> the result as a program, and out pops the answer. > > If the task involves a rule-based decision system, then Prolog can be > a reasonable tool for the job. But in my experience most Prologs > don't interface well - to the world, or to libraries written in other > languages. > > Prolog uses backward chaining Horn logic - essentially you start with > a [generic] "answer" in the form of a rule and look to see if the rule > can be supported by facts in your database. > > Sometimes you want to work the other way, ie. go forward from facts to > rules that are supported by them. Prolog can't do that. > > > There are plenty of problems that can benefit from a Prolog-style rule > system, but if you need one I think it is better to use an embeddable > implementation, and write your main program in a language that is more > suitable to interfacing with the world. > > There are embeddable Prologs and [Horn logic] workalike libraries > available for a number of languages. Indeed. I recall reading a book that showed how to implement Prolog style logic reasoning in Lisp. Not sure if that was S.I.C.P. Or am I remembering the famous lectures, from the 80s? In any case, implementing Prolog-style rules and then just using them in a larger programming language seemed trivial at the time. I have no practical experience with this, however. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-08-21 16:28 -0400 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <83ah8lphjecqntpehi9rfjk1ct642qcf4t@4ax.com> |
| In reply to | #401391 |
On Fri, 21 Aug 2026 15:25:23 +0800, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 21/08/2026 2:08 PM, George Neuner wrote: > >> There are embeddable Prologs and [Horn logic] workalike libraries >> available for a number of languages. > >Indeed. I recall reading a book that showed how to implement Prolog >style logic reasoning in Lisp. Not sure if that was S.I.C.P. Yes, S.I.C.P. presents a simple implementation of logic processing. [It was targeted to Scheme though - not Lisp]. Far better - and more on topic in C.L.L - is Tanimoto's "The Elements of Artificial Intelligence Using Common Lisp". >Or am I remembering the famous lectures, from the 80s? No doubt you might be. Rule-based decision logic was a hot topic back then. >In any case, implementing Prolog-style rules and then just using them >in a larger programming language seemed trivial at the time. I have >no practical experience with this, however. Horn logic is simple. 8-) What is not so simple is how best to organize the rule-base for rapid searching. Recall that the rule/fact-base is /content/ addressable memory, and that rules can modify it by adding or deleting facts and rules. You might immediately think "well, a hash table is a CAM" - and certainly hash tables will work - but any simple implementation is guaranteed to be poorly performing. Also implementing a fast unification style matcher is a PITA - fortunately there are good match libraries to use. The other hurdle is search backtracking /with cuts/. Backtracking is not difficult, but implementing cuts can be problematic. In Prolog, cuts (the ! operator) prevent backtracking from the cut point - it has the effect of constraining the search to trying to match the current rule [Note that searching / matching the "current rule" still may involve backtracking. Cuts don't stop backtracking, but rather they give the programmer some control over it.]
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web