From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Thu, 10 May 2018 23:05:44 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com> <87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com> <16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com> <87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com> <87efiuope8.fsf@nightsong.com> <87lgd1heva.fsf@nightsong.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> <87fu342q1o.fsf@nightsong.com> <87mux9645j.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net EKXzNLOKKeluBs+73NdWhQJIXfWMb4HKgE5fxy6rhPB2mrIa4K Cancel-Lock: sha1:bIaJgQPhNxO0rJJTdPCk+5c93tg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87mux9645j.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52209 Date: 2018-05-10T23:05:44+03:00 List-Id: On 18-05-09 03:53 , Paul Rubin wrote: > Niklas Holsti writes: >> I think there was more to it: Lisp and relatives did not then provide >> the standard functionality that most mainstream applications needed: >> database functions, GUIs, real-world interactions, and so on. They >> were good in their niche, but it would have needed bravery (and >> probably nonstandard language extensions) to embark on translating a >> COBOL application into Lisp. > > Of course GUIs originated in Smalltalk and Lisp systems, I should have said "UI" rather than "GUI", but my fingers were entrained by the currently more common acronym. I had in mind the vendor-specific SW tools for creating UIs to databases and other on-line systems, before the standard windowing systems and before the web. > The smallest such systems, true, but the average smart phone these days > has GB of memory and multi-core GHz processors. Yes, but energy efficiency is becoming very important even there, for battery life and to avoid scorching the user's hands. If a 4x increase in execution time means the battery has to be charged 4x as often... However, I suppose that with a proper OS, it is easier to divide the programs running on the device into "hot spots" -- programs/services that are always running and account for the major part of the energy -- and "cool spots" -- programs that are called up now and then, and for which the energy consumption is not critical -- and to choose the language for each program accordingly. > MicroPython uses garbage collection and works fine (if > the program is not too big) with 32k of ram. Yes, "if the program is not too big". But I agree that there are many applications that fit in such small systems, even with GC and other less-than-100% efficiencies. > This functional Lisp dialect for MCUs (written in Finland if you're > feeling nationalistic) was also really cool for a while: > https://github.com/sbp/hedgehog Looks nice, and why not. There are certainly applications for microcontrollers where it is worth-while to use larger HW models to gain programming convenience and margins. >> [bump allocation] In a multi-threaded system I believe a lock would be >> needed > > I think GHC might use a separate minor heap for each thread. > Surprisingly a quick scan of various literature doesn't establish this > firmly though. I do know that Erlang uses a separate heap per > lightweight process, so some processes can run while others are GCing. A thread can have its own initial heap, for short-lived thread-local data, but in my applications the bigger chunks of data usually end up being sent from one thread to another, implying either copying between heaps or some kind of inter-thread locking at some later point. >>> idiomatic Haskell runs around 4x slower than idiomatic C >> Not sufficient in most of the embedded applictions I have worked on. > > I'd expect those applications have hot and cold spots like everything > else, so the 4x should also usually suffice. The system engineers (a couple of levels above me in the industrial contractor-subcontractor hierarchy) are damnably good at specifying HW that is just about sufficient for the SW applications they specify. So one tries not to waste HW resources. There are certainly "cool spots" in the applications that do not contribute much to the CPU load, and could be 4x slower without blowing the budget. Sometimes one can relax to a more functional programming style in those parts, but using different languages and run-time systems in "hot" and "cool" spots would be cumbersome in such bare-metal, single-program systems. > Many space applications were historically written in Forth on much > slower hardware than you're using now. (I found a list of Forth applications in space at http://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/. Almost all from the USA, and most using the Harris Forth-oriented processor.) Certainly some of the HW was slower. But the crux of the matter is not the absolute HW power, but the cost of margins: can one afford to buy, launch, and supply energy to a 4x more powerful processor, just to have the luxury of a functional or GC programming language? When the necessary algorithms can be implemented more or less as easily in a conventional, procedural, non-GC language? > Forth traditionally used a simple threaded-code interpreter > that (while quite memory efficient) was maybe 10x slower than assembly > or compiled C code. You'd use assembly for speed-critical subroutines > and Forth for the rest. Indeed, on small processors with weak instruction sets and short registers, using an interpreter can be very advantageous, decreasing code size with minor impact on speed. Even the Apollo spacecraft had part of their guidance SW implemented in that way. > The convincing obstacles to Haskell or Lisp are > more likely to be memory and nondeterminism, than pure speed. It depends. In embedded SW there are often both very time-critical functions and less time-critical functions. Some space-based SW have used Lisp-like languages for the latter -- things like higher-level planning; failure detection, isolation and recovery; and other functions were AI methods are slowly entering. >> While my current application has 8 MiB of RAM (up from 4 MiB in the >> preceding app)... But the processor clock is only some 60 MHz > > That's a big fast system compared to the historical Lisp environments! Sure, but the application requirements are also larger. The CPU load in my current application is about 40%. Slowing down the code by factor of 4x would be impossible with this HW. The system engineers do trade-offs between dedicated HW (FPGAs etc) and processor HW (SW functions) and do not provide lavish margins for the latter. Some functions in space-based SW do have almost ridiculous amounts of time available. Many anomalies and failures can take hours or days to become critical -- say, a loss of attitude control leading to a loss of solar electrical power, which must be corrected before the batteries are drained. For such functions, the ability to easily program complex, AI-like algorithms would be welcome, and I believe is coming into use. A final note: a couple of years ago, there seemed to be a group within the European Space Agency who were promoting Java for on-board SW (I'm not sure if this was some real-time Java with limited GC, or normal Java). I haven't seen any results so far, but then I don't have much visibility into ESA. The hot topic in ESA today seems to be model-based design and automatic code generation, which means that the coding language is seen as less important. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .