5 ms·

My instinctive response is "but it's garbage collected, so what use does that have on embedded?". Most of the stuff I'm doing is fairly soft real time though.

My instinctive response is "but it's garbage collected, so what use does that have on embedded?". Most of the stuff I'm doing is fairly soft real time though. Am I being too closed minded and a garbage collector that ran quickly enough would still allow for a useful design space?

grey-area 9y ago
The GC is now pretty fast, and pause times are minimal (sub ms) even on large heaps. https://twitter.com/brianhatfield/status/634166123605331968 https://twitter.com/brianhatfield/status/634166123605331968
shandor 9y ago
Impossible to answer in general context :) Nowadays anything from 16kB to 2GB of RAM gets called "embedded". Storage is the same but x10. I would be surprised if there's nothing to use Go for in all that design space, but generalizations are probably plain impossible.
- rkangel 9y ago
  I agree about the definition of embedded. My personal definition is "doesn't have an MMU".
  - TickleSteve 9y ago
    a significant portion of the embedded market have MPUs (subtly different from an MMU, namely Cortex-M and PIC32 level devices). Not always used tho.
  - simias 9y ago
    By this definition embedded development will go extinct very soon. And maybe it should. I think as far as software is concerned embedded development is not all that special anymore. Everything is running advanced ARM SoCs that have the same power you'd have on a workstation ~15 years ago. It's still meaningful if you're working on electronics though, you generally have wildly different constraints regarding ECM, power draw, heat dissipation, environmental constraints etc...
    - TickleSteve 9y ago
      No, the majority of embedded systems are still on Cortex-M level systems, not "A". Despite what the maker-movement and IoT-hype would have you believe, most embedded systems are not running Linux. Bear in mind that the vast majority of processors sold these days are micro-controllers and go into things like electricity meters, light switches, alarm clocks, etc.... mundane stuff.
      - pjmlp 9y ago
        There are commercial Java and Oberon compiler variants for Cortex-M level systems, though.
        TickleSteve 9y ago
        True, but with practically zero customers.
        pjmlp 9y ago
        Astrobe is operating since 1997. MicroEJ is operating since 2004. If they had practically zero customers, they would have closed doors by now.
      - simias 9y ago
        Sure but it's definitely moving that way in my experience. As the price difference becomes more and more negligible people prefer to stick more fully featured chips in products where it wouldn't have made sense 10 years ago. There's benefit for companies to do that too, developers who can work efficiently on an MMU-less bare metal/small RTOS system tend to be experienced and cost a lot. Now if you run Linux (or maybe even android these days) on your embedded product you can basically have any half competent junior coder develop on it without problem. At the rate this is going I would only be half surprised if my electricity meter ran Linux in a decade, especially since the trend is into making "smarter" ones. Also while Cortex-M are definitely more microcontroller-ish than the A versions they're still pretty impressive beasts compared to the microcontrollers of yore. They can run at frequencies on the order of hundreds of MHz, often come with advanced IPs like USB, ethernet, DMA and more. Maybe we should have an intermediate category for "millicontrollers".
teknico 9y ago
Yes to the latter. As for the former, it's up to you to decide. ;-)
pjmlp 9y ago
Yep a bit closed minded. :) Have a look at Project Oberon, Mesa/Cedar at Xerox PARC, Modula-3 at DEC/Olivetti, Singularity/Midori at Microsoft https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.ocp.inf.ethz.ch/wiki/Documentation/Front https://en.wikipedia.org/wiki/SPIN_(operating_system) https://en.wikipedia.org/wiki/SPIN_(operating_system) https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000 https://archive.org/details/bitsavers_xeroxparcteCedarProgra... http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... All of them produced workable graphical workstations that were used for a couple of years until the projects were shutdown for political/monetary reasons. Oberon GUI is the genesis how Plan 9/Inferno GUIs work, specially the ACME text editor. For something with more constraints, Real-Time Java implementations are powering battleship weapons tracking systems, here two examples http://www.military.com/equipment/aegis-weapon-system http://www.military.com/equipment/aegis-weapon-system http://www.marketwired.com/press-release/ibm-raytheon-deliver-technology-solution-ddg-1000-next-generation-navy-destroyers-nyse-ibm-719837.htm http://www.marketwired.com/press-release/ibm-raytheon-delive... Having said this, of course there are environments where not having a GC at all is a better approach for the use case being solved. What many in the anti-GC crowd don't realise it that these GC enabled systems languages also allow to switch off the GC on critical code sections, or make use of manual memory management in unsafe code. So it it not necessary to throw away the productivity to get the full benefit of performance, if the language offers the necessary knobs.
- rkangel 9y ago
  Thank your for the detailed answer - that was the sort of information I was interested in.
- themihai 9y ago
  Go doesn't allow you to switch off the GC on critical code sections. The switch-off is only for debug/dev purpose.
e3b0c 9y ago
My guess is it can be managed by something similar to the concept of critical sections. That is, GC is disabled in the critical sections and is only enabled explicitly by the programmer. That's like how the pauses caused by hardware interrupts are prevented in kernel/driver programming. After all, you won't like heap allocation/deallocation in the hot-path no matter what language is used, be it GCed or not.
- TickleSteve 9y ago
  The problem with GC in hard-real-time systems is not speed... real-time != fast. real-time == deterministic, and this is what GC is not. At all times you must know what code is able to execute in order to meet worst-case deadlines. The easiest way of managing this is to disallow any non-deterministic processes in the real-time levels of your application (this means dynamic memory allocation and by inference also GC, but it also applies to anything else). Also bear in mind that most hard-real-time systems are also safety-related and need high-reliability. systems are expected to stay running indefinitely (or at least for years) without a reset on systems with Kilobytes of RAM. For these types of systems you work out your worst-case load and statically allocate everything. This makes it much easier to reason about.
  - tuyguntn 9y ago
    Sorry for ignorance, but I always wanted to know what is that real-time systems (other than airplane managing systems) Could you please tell some of them? thanks
    - TickleSteve 9y ago
      Quick list of the top of my head: - Engine management systems (e.g. timing of firing in an IC engine) - Missile detection systems (e.g. need to react to a detection within time to activate countermeasures). - Medical systems (e.g. timing of valve closing/opening is critical to dosage). - Phone protocol stacks (e.g. transmitting during allocated time-slots). - Metering systems (e.g. must read measurement devices at correct time to ensure accuracy). - Audio systems (e.g. avoiding glitches requires deterministic processing) ...and lots, lots more. In general, things that interact with the real physical world require deterministic control.
disconnected 9y ago
Depends on your embedded system and your use case. If your embedded system is a Raspberry Pi 3 controlling a few leds or talking with something over UART or whatever, then it won't matter a whole lot whether you have a GC or not. On the other hand, if your embedded system is a 50Mhz 8-bit microcontroller with a whooping 8KB of "RAM" (and 16KB of program memory) doing ~20k sensor reads per second, then it WILL matter. They seem to be targeting armv7 and their reference device (Wanboard Quad) has a 1GHz clock and 2GB of ram, which is a monster compared to most embedded systems I've worked on. That gives them plenty of cycles and memory to waste doing garbage collection, a luxury SOME of us can't afford.
vanderZwan 9y ago
Aside from what everyone else said, you should keep in mind that garbage collection != Java memory model. Go has structs and defaults to avoiding boxed values. It also has escape analysis and tries to do stack allocation before putting objects on the heap. Compared to Java, it is a lot easier to write your code in a way that minimises or even avoids generating garbage that has to be collected in the first place.

grey-area 9y ago

The GC is now pretty fast, and pause times are minimal (sub ms) even on large heaps. https://twitter.com/brianhatfield/status/634166123605331968 https://twitter.com/brianhatfield/status/634166123605331968

shandor 9y ago

Impossible to answer in general context :) Nowadays anything from 16kB to 2GB of RAM gets called "embedded". Storage is the same but x10. I would be surprised if there's nothing to use Go for in all that design space, but generalizations are probably plain impossible.

rkangel 9y ago
I agree about the definition of embedded. My personal definition is "doesn't have an MMU".
- TickleSteve 9y ago
  a significant portion of the embedded market have MPUs (subtly different from an MMU, namely Cortex-M and PIC32 level devices). Not always used tho.
- simias 9y ago
  By this definition embedded development will go extinct very soon. And maybe it should. I think as far as software is concerned embedded development is not all that special anymore. Everything is running advanced ARM SoCs that have the same power you'd have on a workstation ~15 years ago. It's still meaningful if you're working on electronics though, you generally have wildly different constraints regarding ECM, power draw, heat dissipation, environmental constraints etc...
  - TickleSteve 9y ago
    No, the majority of embedded systems are still on Cortex-M level systems, not "A". Despite what the maker-movement and IoT-hype would have you believe, most embedded systems are not running Linux. Bear in mind that the vast majority of processors sold these days are micro-controllers and go into things like electricity meters, light switches, alarm clocks, etc.... mundane stuff.
    - pjmlp 9y ago
      There are commercial Java and Oberon compiler variants for Cortex-M level systems, though.
      - TickleSteve 9y ago
        True, but with practically zero customers.
        pjmlp 9y ago
        Astrobe is operating since 1997. MicroEJ is operating since 2004. If they had practically zero customers, they would have closed doors by now.
    - simias 9y ago
      Sure but it's definitely moving that way in my experience. As the price difference becomes more and more negligible people prefer to stick more fully featured chips in products where it wouldn't have made sense 10 years ago. There's benefit for companies to do that too, developers who can work efficiently on an MMU-less bare metal/small RTOS system tend to be experienced and cost a lot. Now if you run Linux (or maybe even android these days) on your embedded product you can basically have any half competent junior coder develop on it without problem. At the rate this is going I would only be half surprised if my electricity meter ran Linux in a decade, especially since the trend is into making "smarter" ones. Also while Cortex-M are definitely more microcontroller-ish than the A versions they're still pretty impressive beasts compared to the microcontrollers of yore. They can run at frequencies on the order of hundreds of MHz, often come with advanced IPs like USB, ethernet, DMA and more. Maybe we should have an intermediate category for "millicontrollers".

teknico 9y ago

Yes to the latter. As for the former, it's up to you to decide. ;-)

pjmlp 9y ago

Yep a bit closed minded. :) Have a look at Project Oberon, Mesa/Cedar at Xerox PARC, Modula-3 at DEC/Olivetti, Singularity/Midori at Microsoft https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.ocp.inf.ethz.ch/wiki/Documentation/Front https://en.wikipedia.org/wiki/SPIN_(operating_system) https://en.wikipedia.org/wiki/SPIN_(operating_system) https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000 https://archive.org/details/bitsavers_xeroxparcteCedarProgra... http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... All of them produced workable graphical workstations that were used for a couple of years until the projects were shutdown for political/monetary reasons. Oberon GUI is the genesis how Plan 9/Inferno GUIs work, specially the ACME text editor. For something with more constraints, Real-Time Java implementations are powering battleship weapons tracking systems, here two examples http://www.military.com/equipment/aegis-weapon-system http://www.military.com/equipment/aegis-weapon-system http://www.marketwired.com/press-release/ibm-raytheon-deliver-technology-solution-ddg-1000-next-generation-navy-destroyers-nyse-ibm-719837.htm http://www.marketwired.com/press-release/ibm-raytheon-delive... Having said this, of course there are environments where not having a GC at all is a better approach for the use case being solved. What many in the anti-GC crowd don't realise it that these GC enabled systems languages also allow to switch off the GC on critical code sections, or make use of manual memory management in unsafe code. So it it not necessary to throw away the productivity to get the full benefit of performance, if the language offers the necessary knobs.

rkangel 9y ago
Thank your for the detailed answer - that was the sort of information I was interested in.
themihai 9y ago
Go doesn't allow you to switch off the GC on critical code sections. The switch-off is only for debug/dev purpose.

e3b0c 9y ago

My guess is it can be managed by something similar to the concept of critical sections. That is, GC is disabled in the critical sections and is only enabled explicitly by the programmer. That's like how the pauses caused by hardware interrupts are prevented in kernel/driver programming. After all, you won't like heap allocation/deallocation in the hot-path no matter what language is used, be it GCed or not.

TickleSteve 9y ago
The problem with GC in hard-real-time systems is not speed... real-time != fast. real-time == deterministic, and this is what GC is not. At all times you must know what code is able to execute in order to meet worst-case deadlines. The easiest way of managing this is to disallow any non-deterministic processes in the real-time levels of your application (this means dynamic memory allocation and by inference also GC, but it also applies to anything else). Also bear in mind that most hard-real-time systems are also safety-related and need high-reliability. systems are expected to stay running indefinitely (or at least for years) without a reset on systems with Kilobytes of RAM. For these types of systems you work out your worst-case load and statically allocate everything. This makes it much easier to reason about.
- tuyguntn 9y ago
  Sorry for ignorance, but I always wanted to know what is that real-time systems (other than airplane managing systems) Could you please tell some of them? thanks
  - TickleSteve 9y ago
    Quick list of the top of my head: - Engine management systems (e.g. timing of firing in an IC engine) - Missile detection systems (e.g. need to react to a detection within time to activate countermeasures). - Medical systems (e.g. timing of valve closing/opening is critical to dosage). - Phone protocol stacks (e.g. transmitting during allocated time-slots). - Metering systems (e.g. must read measurement devices at correct time to ensure accuracy). - Audio systems (e.g. avoiding glitches requires deterministic processing) ...and lots, lots more. In general, things that interact with the real physical world require deterministic control.

disconnected 9y ago

Depends on your embedded system and your use case. If your embedded system is a Raspberry Pi 3 controlling a few leds or talking with something over UART or whatever, then it won't matter a whole lot whether you have a GC or not. On the other hand, if your embedded system is a 50Mhz 8-bit microcontroller with a whooping 8KB of "RAM" (and 16KB of program memory) doing ~20k sensor reads per second, then it WILL matter. They seem to be targeting armv7 and their reference device (Wanboard Quad) has a 1GHz clock and 2GB of ram, which is a monster compared to most embedded systems I've worked on. That gives them plenty of cycles and memory to waste doing garbage collection, a luxury SOME of us can't afford.

vanderZwan 9y ago

Aside from what everyone else said, you should keep in mind that garbage collection != Java memory model. Go has structs and defaults to avoiding boxed values. It also has escape analysis and tries to do stack allocation before putting objects on the heap. Compared to Java, it is a lot easier to write your code in a way that minimises or even avoids generating garbage that has to be collected in the first place.