5 ms·

An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with G

by kettro 6y ago

An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.

JoeAltmaier 6y ago
My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.
- black3r 6y ago
  > And embedded is usually dog slow processor running at minimum clock, to save power. It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
  - dathinab 6y ago
    Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
    - JoeAltmaier 6y ago
      Regardless, if a lesser module for $4.50 will squeak by, then that's what the designer should specify. And the programmer will make do.
- dathinab 6y ago
  Embedded is a very wide field. It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors. Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based. I mean think about how cheap a 1+GHz ARM chip has become today.
  - JoeAltmaier 6y ago
    I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
- wahern 6y ago
  Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors. Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit. Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
- munificent 6y ago
  "Embedded" means different things to different people. Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
  - JoeAltmaier 6y ago
    Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
    - mwcampbell 6y ago
      Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?
layoutIfNeeded 6y ago
>These can run basic GC'd apps just fine LOL, this explains why every embedded GUI I encounter in these "smart" devices is awfully sluggish and a pain to use, delivering 5fps at most. Thx for the clarification!
- fmakunbound 6y ago
  Don’t know why you’re getting voted down... One only has to pick the same app, implemented natively on comparable iPhone and Android hardware to see that the underlying language runtime, that’s NOT garbage collected, is the one with the buttery-smooth UI. With JS “native” or web whatever, it’s even more pronounced on the SAME hardware.
  - layoutIfNeeded 6y ago
    Yep. Last week I had the joy of checking the infotainment system of my friend’s new car, for which Renault thought it was a good idea to use this Android fork or whatever, with a touchscreen interface of course. It was comically bad! The latency, the framerate, the whole user experience was utter crap. If they had literally glued a 2G iPhone from 2007 to the dashboard it would have been better than this embedded Android GUI. And I refuse to believe that the hardware in a 2020 executive car is less performant than a phone from 13 years ago, so the culprit has to be the software...

by kettro 6y ago

JoeAltmaier 6y ago

My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.

black3r 6y ago
> And embedded is usually dog slow processor running at minimum clock, to save power. It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
- dathinab 6y ago
  Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
  - JoeAltmaier 6y ago
    Regardless, if a lesser module for $4.50 will squeak by, then that's what the designer should specify. And the programmer will make do.
dathinab 6y ago
Embedded is a very wide field. It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors. Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based. I mean think about how cheap a 1+GHz ARM chip has become today.
- JoeAltmaier 6y ago
  I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
wahern 6y ago
Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors. Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit. Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
munificent 6y ago
"Embedded" means different things to different people. Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
- JoeAltmaier 6y ago
  Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
  - mwcampbell 6y ago
    Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?

layoutIfNeeded 6y ago

>These can run basic GC'd apps just fine LOL, this explains why every embedded GUI I encounter in these "smart" devices is awfully sluggish and a pain to use, delivering 5fps at most. Thx for the clarification!

fmakunbound 6y ago
Don’t know why you’re getting voted down... One only has to pick the same app, implemented natively on comparable iPhone and Android hardware to see that the underlying language runtime, that’s NOT garbage collected, is the one with the buttery-smooth UI. With JS “native” or web whatever, it’s even more pronounced on the SAME hardware.
- layoutIfNeeded 6y ago
  Yep. Last week I had the joy of checking the infotainment system of my friend’s new car, for which Renault thought it was a good idea to use this Android fork or whatever, with a touchscreen interface of course. It was comically bad! The latency, the framerate, the whole user experience was utter crap. If they had literally glued a 2G iPhone from 2007 to the dashboard it would have been better than this embedded Android GUI. And I refuse to believe that the hardware in a 2020 executive car is less performant than a phone from 13 years ago, so the culprit has to be the software...