5 ms·
This is great! I independently figured a lot of this stuff out around 1995 while writing shareware games in college (limited by absurdly slow 30 MHz memory bus
by zackmorris 4y ago
This is great!
I independently figured a lot of this stuff out around 1995 while writing shareware games in college (limited by absurdly slow 30 MHz memory busses and single-threaded execution before video cards) and 2005 at a job where I used MATLAB. Basically that computers ran many thousands of times slower than they should have, which today translates to many millions of times slower for the transistor counts. We perceive computers as fast today, but that's just the video card doing most of the work, at enormous programmer expense due to having to use separate languages and paradigms separate from the host OS.
The article jumps the shark at chapter 5 Transputer Languages on page 63, so I'd recommend skipping that. It's fun to learn about stuff like Occam, but it's kind of the assembly language of Erlang or Go (if Go had full process isolation) so is probably too low-level for large programs to be understandable by humans. They didn't really understand process isolation like we do today, so got lost in the weeds with libraries/intrinsics/threads, rather than having a language self-parallelize all code like something like Julia (from what I understand, I haven't fully learned it yet).
I'd largely skip Chapter 6 Software Environments on page 88 as well, which covers various environments for transputers, which are fun for their historical significance. But again, I wouldn't use any of them today, since we have much simpler approaches with stuff like containerization now.
Chapter 7 Transputer Family Hardware on page 101 is quaint. The principles are good, but break down with the memory and network speeds available today and the fact that we work at higher levels of abstraction.
I didn't know there was an Atari Transputer Workstation (ATW) in 1988, wow!
I've written extensively about multicore processing in my comments here for over a decade, with no meaningful progress in industry from what I can tell. Personal hardware got abandoned for stuff like elastic compute on AWS.
That said, it's pretty obvious what a transputer today would look like. I'd suggest a 1 GHz processor with at least 1 GB of onboard ram and at least 256 cores for under $100. It should have gigabit ethernet and use something like content-addressable memory to allow the chips to self-organize with LRU caching for data locality. It would use web metaphors so that the location of a core or memory doesn't matter, even running across a warehouse or over the internet. So 4 of these would look like a single desktop computer with a kilocore (kC, like IBM's from 2006) and easily scale to probably 64kC or even 1 MC without too much extra work. It would be the software equivalent of something like BitTorrent vs FTP. And largely buildable with FPGAs, had they continued to evolve instead of getting hamstrung by their GPU competition.
It would be programmed with existing C-style languages and a self-parallelizing compiler that uses techniques from compiler optimization to detect for-loops on immutable data and spread the workload over any number of processes. Programs would be inverted to identify mutability and treat it as unsafe code that can't be statically analyzed or evaluated lazily. So synchronous blocking higher-order methods on immutable data would be highly encouraged. Stuff like shader memory layout optimizations would largely go away due to the use of content-addressable memory and the avoidance of hardware caching other than what's needed to make the distributed memory appear as a single address space.
It's all so easy and obvious to me that I've all but given up on it ever happening. Writing this out for the umpteenth time makes me feel tired. To the point that I struggle to program in my daily life, because it feels like I'm having to do everything the hard way with async approaches (today's GOTO) and highly-specialized shaders that break constantly because I just can't see what I'm doing or debug them properly so it feels like all I ever get is a blank screen.
I wish so badly that a startup would jump on this and bring us real computers with real power so that we could play around with stuff like genetic algorithms and running machine learning in simulation so that we could evolve our own AI digital assistants. Instead of having to rely on closed/proprietary/cookie-cutter solutions that are pay-to-play or have other artificial limitations to prevent terrorism or whatever.
It's the same old story, I'm thrilled to see stuff like DALL-E 2 bring the predictions of sci-fi to life, but saddened that it happened decades later than it should have due to poor hardware architecture choices. It's like having to watch electric cars go mainstream 20-30 years after the lithium ion battery was invented, because the fossil fuel industry prevented that from happening every step of the way.
- contingencies 4y agoI like your thinking but devil's advocate... How much of what we do on current-era machines is IO-bound? Not a great deal. And when it is, it's usually a network and not a local hardware limitation. How much would UX improve? Not a great deal, most usage is CRUD/web/vid. Would new applications become available? Sure. But what are they? Is the value proposition vs. total addressable market compelling? If you can convincingly answer the above you can definitely go get funding and do it.
- kingludite 4y ago> Would new applications become available? In the 80ś-90ś I thought of software as prototyping. If we keep a healthy separation of [shall we say] mission critical application and entertainment, today, as far as normal users are concerned, a good 99% is pretty well defined. We are now developing stuff users don't want, rent seeking schemes and prisons therefore. Not sure if it was my failure to predict or the industries but I thought the most obvious requirements in the obvious applications would find their way into the high level language abstractions (in increasingly large chunks) and gradually migrate to lower language features and so on closer to the metal until the email client is just an array of similar email processors that can be powered on with some basic query. Have a mailto with params, a new mail notification with some custom sounds entirely separate from other audio, some way to export the attachments and the database i/o preferably with a mechanical switch that completely rules out any other process accessing the mailbox unless the user specifically enables it. Yeah, it should probably beep loudly for as long as remote reading or writing is enabled with a red led blinking above the tumbler switch. That way no one has to ponder how to ruin the protocol, add emoji's, data mine the user, insert ads or otherwise turn email into a first person shooter MMO next level email experience. Regardless what fantastic thing email could grow into it would just not be possible. After all, we've already turned the fantastic document distribution network (www) into a fantastic application platform. Ideally such things should not be possible but it was and we did and the result is ofc wonderful... except that documents are now multi GB advertisement machines that make 500+ requests. (I cant even view the images in this topic because this laptop cant do such websites) Email has the potential to be a superior application platform much superior to the www but I really hope(ed) we could glue its components into place. (toasters that cant run doom) The next chunk of hardware can do news groups, one for IRC, one for torrents, one for word processing, one for tabular data, one with maps, one with a web browser, a real terminal(!) and eventually we can have a hardware implementation of HN. Each such application can have its own signal from the keyboard and mouse and its own video output. Some other chip to combine the pictures into windows with some title validation so that one cant mimic hardware implementations without the user knowing it. I was completely wrong or was I? That wonderful pdf in the topic makes an analogy replacing a single supper fast bar tender with multiple bar tenders but this seems a poor fit. The general purpose stuff is like a college degree. It is some college! Its product is state of the art and it is improving all the time. But if you want to develop, manufacture and finance the development of the next level drink dispenser you cant keep throwing [however excellent] college graduates at it and expect it to scale. Our college is to produce the finest surgeons who are also the finest pilots, the best mathematicians, greatest artists and stand up comedians. Good luck with that?