3 ms·

Computers are more like an assembly of subsystems than a single thing, and you can just about get away with agnostic byte code as long as you ignore most of the

Computers are more like an assembly of subsystems than a single thing, and you can just about get away with agnostic byte code as long as you ignore most of the subsystems. So cross-platform byte code is sort of viable on mid-80s text terminal systems with limited memory and addressing. But as soon as you start adding graphics cards, video acceleration, sound, and AI accelerators, you need to add abstraction layers which will be limited and inefficient and limited compared to the hardware. And if the hardware isn't available you can either say 'This won't run at all' or emulate it in software, which will be even slower.

kragen 2y ago
There's some truth to that, but I think you're overstating the case. The vast majority of software we run on a day-to-day basis doesn't use any of the stuff you mentioned, so nothing is stopping it from moving to platform-agnostic bytecode, except that that bytecode doesn't exist yet. For example, 2-D graphics acceleration hardware (whether in the form of character generators or in the form of blitters and line drawing) was really important for usability up to the 01990s. This is a major reason the X-Windows protocol is so big and complicated: it needed a way to expose the acceleration capabilities of the hardware to applications so they could draw with it. This was, as you said, "limited and inefficient and limited compared to the hardware". But basically, as CPUs got faster, we gave up on all that stuff around the turn of the millennium, and now most 2-D applications really just want to fill up pixel buffers and swap the displayed buffer between screen refreshes. It's a very, very simple interface (you might say "inefficient abstraction layer"). Something similar happened with sound. In the 80s and 90s our sound cards did square and sawtooth waves, LFSR noise generation, envelopes, FM synthesis, wavetable synthesis, etc. Different sound cards had different instruments! Now all I want to do with my sound card is send it a sequence of samples, maybe get back a sequence of samples from the microphone, maybe choose from among multiple outputs. Another very, very simple interface. 3-D games do still use 3-D acceleration, of course. That's not a simple interface. They also depend pretty heavily on SIMD instructions. The same is true of video codecs. But my SSH client, my mail server, my IRC client, my text editor, my compiler, my filesystem, my Game of Life simulator, my system logger, my Sudoku game, my circuit design program (KiCad), my PDF viewer, my audio editor (Audacity), and so on — those aren't using "graphics cards, video acceleration, sound, and AI accelerators", except through the very, very simple interfaces we're talking about above. Most of them don't even use floating-point math! They could easily be in platform-agnostic bytecode because they already do ignore most of the subsystems in my computer.
- deleted 2y ago
  [deleted]
- wahern 2y ago
  > This is a major reason the X-Windows protocol is so big and complicated X was trying to, in a sense, remote hardware acceleration. Wayland doesn't bother at all, clients render their windows locally and share (or send) a pre-rendered graphic. But if you use across the network an older X app, such as one that uses server-side fonts, etc, the experience is often much smoother, IME, as compared to the Wayland-universe alternatives.[1] Once upon a time even web browsers, like ancient versions of Netscape, were shockingly responsive over the network, even with mixed text and graphics; almost indistinguishable from local (and this at a time when X11 on a 486 was a smoother experience than Windows). The popular toolkits now render the window on the client even when using X, so those capabilities are largely unused today. [1] In that case, the composition and rendering of all the widgets, text, and images within a window is truly local, i.e. on your local X server.

kragen 2y ago

There's some truth to that, but I think you're overstating the case. The vast majority of software we run on a day-to-day basis doesn't use any of the stuff you mentioned, so nothing is stopping it from moving to platform-agnostic bytecode, except that that bytecode doesn't exist yet. For example, 2-D graphics acceleration hardware (whether in the form of character generators or in the form of blitters and line drawing) was really important for usability up to the 01990s. This is a major reason the X-Windows protocol is so big and complicated: it needed a way to expose the acceleration capabilities of the hardware to applications so they could draw with it. This was, as you said, "limited and inefficient and limited compared to the hardware". But basically, as CPUs got faster, we gave up on all that stuff around the turn of the millennium, and now most 2-D applications really just want to fill up pixel buffers and swap the displayed buffer between screen refreshes. It's a very, very simple interface (you might say "inefficient abstraction layer"). Something similar happened with sound. In the 80s and 90s our sound cards did square and sawtooth waves, LFSR noise generation, envelopes, FM synthesis, wavetable synthesis, etc. Different sound cards had different instruments! Now all I want to do with my sound card is send it a sequence of samples, maybe get back a sequence of samples from the microphone, maybe choose from among multiple outputs. Another very, very simple interface. 3-D games do still use 3-D acceleration, of course. That's not a simple interface. They also depend pretty heavily on SIMD instructions. The same is true of video codecs. But my SSH client, my mail server, my IRC client, my text editor, my compiler, my filesystem, my Game of Life simulator, my system logger, my Sudoku game, my circuit design program (KiCad), my PDF viewer, my audio editor (Audacity), and so on — those aren't using "graphics cards, video acceleration, sound, and AI accelerators", except through the very, very simple interfaces we're talking about above. Most of them don't even use floating-point math! They could easily be in platform-agnostic bytecode because they already do ignore most of the subsystems in my computer.

deleted 2y ago
[deleted]
wahern 2y ago
> This is a major reason the X-Windows protocol is so big and complicated X was trying to, in a sense, remote hardware acceleration. Wayland doesn't bother at all, clients render their windows locally and share (or send) a pre-rendered graphic. But if you use across the network an older X app, such as one that uses server-side fonts, etc, the experience is often much smoother, IME, as compared to the Wayland-universe alternatives.[1] Once upon a time even web browsers, like ancient versions of Netscape, were shockingly responsive over the network, even with mixed text and graphics; almost indistinguishable from local (and this at a time when X11 on a 486 was a smoother experience than Windows). The popular toolkits now render the window on the client even when using X, so those capabilities are largely unused today. [1] In that case, the composition and rendering of all the widgets, text, and images within a window is truly local, i.e. on your local X server.