C++ and stuff on embedded processors, again

On a sunny day (Mon, 02 Oct 2017 07:28:05 -0700) it happened John Larkin wrote in :

That is a lot of money 12 * 9 = 108 dolars..., I think more than I pay for the server space at my site.

Drop..??? I have written a script: let's see to_website2 pressure_each_hour_april_4_til_now.gif now you see it:

That script also puts it in the local backup server... l /usr/local/httpd/htdocs/pub/pressure_each_hour_april_4_til_now.gif

10128 Oct 2 16:59 /usr/local/httpd/htdocs/pub/pressure_each_hour_april_4_til_now.gif

'l' is short for ls -rtl.. I use zsh as shell, not bash.

That was from the Raspberry air pressure log that looks like

2017/04/04 20:00.00 UTC 1030.1 hPa lat 53.251265 lon 5.599568 2017/04/04 21:00.00 UTC 1030.4 hPa lat 53.251313 lon 5.599620 2017/04/04 22:00.00 UTC 1030.2 hPa lat 53.251318 lon 5.599471

changed to make a simple file 'q2': cat pressure.log | awk //'{print $4}' > q2

q2 looks like this:

1030.1 1030.4 1030.2

Then I started gnuplot: # gnuplot

G N U P L O T Version 4.4 patchlevel 3 last modified March 2011 System: Linux 2.6.37.6-smp

Copyright (C) 1986-1993, 1998, 2004, 2007-2010 Thomas Williams, Colin Kelley and many others

gnuplot home:

faq, bugs, etc: type "help seeking-assistance" immediate help: type "help" plot window: hit 'h'

Terminal type set to 'x11' gnuplot> plot "q2" with lines

Then I took a screenshot of the display: import pressure_each_hour_april_4_til_now.gif send it to the world: to_website2 pressure_each_hour_april_4_til_now.gif

All less than a few minutes

But complicated, I admit ;-) My computah speaks english.

Hey I forgot to mention that the Raspberry running xgpspc has voice output, it tells you what alarm, like for example 'water' or 'CO', or whatever. Thats uses the festival speech synthesizer.

You could use that to address the animal car by saying: 'Be nice to the cat'

:-)

Programming is fun:

/* alarm states */ #define ALARM_STATE_NO_ALARM 0 #define ALARM_STATE_AIS_COLLISION 1 #define ALARM_STATE_AIS_PROXIMITY 2 #define ALARM_STATE_ANCHOR 4 #define ALARM_STATE_WATER 8 #define ALARM_STATE_HEADING 16 #define ALARM_STATE_STEERING 32 #define ALARM_STATE_DEPTH 64 #define ALARM_STATE_DEPTH_SENSOR 128 #define ALARM_STATE_STEPPER_END_STOP 256 #define ALARM_STATE_WIND_SENSOR 512 #define ALARM_STATE_CO 1024 #define ALARM_STATE_SPECIAL 2048 #define ALARM_STATE_PRESSURE 4096 #define ALARM_STATE_PLANE 8192 #define ALARM_STATE_X_ANGLE 16964 #define ALARM_STATE_Y_ANGLE 32768 ....

That's true of any OOPL, so I don't think it is a benefit of using C++.

The aggro I found with C++ was that I had to crystallise my low-level implementation/coding strategy before I was able to understand its consequences. When, not if, I found the pain points, it was remarkably difficult to reverse them.

Now that was a long time ago, and I'm quite prepared to believe that since then people have developed design patterns that would avoid my missteps. But by the time that had happened, the general tardiness in developing decent libraries meant I had moved on to better things.

And there has never been, and probably will never be, general agreement on which low-level design design patterns should be employed. For language lawyers and framework developers, that's probably an advantage, but it is an impediment when a mere mortal is told to "drain a swamp".

You've heard of move constructors/assignment and copy elision riiiiight....

Which language standard mandated those?

If none, then it is pot-luck as to whether an individual implementer and compiler use them correctly.

Move semantics have been part of the ISO standard since C++11, and most compilers have supported them since C++0x. The better part of a decade now!

The compiler rarely does dumb stuff like make a superfluous copy of a large object returned from a function when all you want to do is say place it in a container, anymore. It just constructs it in-place in the container.

If for whatever reason you're working with an older library that doesn't support move construction/assignment templates like std::vector have a method called something like "emplace_back" where you can tell it to do that explicitly.

Dynamic linking is mostly obsolete...sort of like compiled code for many applications.

Fancy video games for example just write the 3D engine/physics stuff in C/C++ and also a virtual machine. Everything else gets handled by the virtual machine via scripting. Been that way for probably 20 years now.

Alternatively, it only took 23+ years to get that far!

Far too slow; the world had moved on several times by then.

And the library purchased from a different company?

Riiiighhhhtt..... by some definition of "obsolete" that avoids condemning essentially every Linux package in the world.

In your dreams.

Nearly everyone (including me) codes stuff using scripts for the front end and C/C++/Java for the back end, but the point of doing that is that most of the cycles are spent in the compiled code.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

as

he

ed

etter

static

e y

and instead of updating a library to fix a security hole you have to get ne w binaries for every program that uses that library

It doesn't look like it's from the 1970s, so I'm pretty sure you wouldn't be impressed. :-(

So you don't like money?

Bollocks ... and bollocks.

Large programs on windows are full of dlls. Every program comes with its own copies of standard dlls (preferably in slightly different versions) to ensure maximal waste of disk space and run-time memory. In the *nix world, distros are full of standard so's so that lots of programs can share the same library, for minimal waste of disk space and run-time memory.

And in any large system where there are lots of programmers involved in the development, it is not uncommon to modularise things by having separately compiled dynamic libraries. It helps re-use, it helps provide clean separation of parts, it helps give faster build times, and it makes life easier if different parts of the system are build with different tools and programming languages.

Of course dynamic linking is rarely used in small embedded systems, which is the most relevant type of programming for this thread - but it is not the /only/ type of programming.

Compiled code is the norm for most applications. There is, perhaps, an increasing percentage of applications that are written in languages like Python. And there is a section in the middle with byte-compiled code run with JIT compilation, such as Java. It is mostly a matter of balance between run-time efficiency and development speed.

No, video games are generally almost entirely written in compiled languages such as C and C++. It is not uncommon to use a scripting language (usually lua) as part of map/scenario files because it makes development and testing faster.

Yes, except some Java runtimes have far more performant techniques than traditional JIT. JITs are 31 years old, Hotspot techniques have only been around since the late 90s.

That was a Windows Visual Studio compiler version issue. One version wanted to do it one way, the other version an other way. Mixing .EXE program code from one version with .DLL code from an other version caused problems.

In practice you had to maintain two development systems, one for the old and one for the new compiler. You then deliver the .DLL version corresponding to the target system .EXE version.

You are telling me that newer Java VM's can be faster than older Java VM's, due to new techniques? Well, that's a surprise.

Not you; other people that might think JITs are state of the art - cf how many people think GCs use simple reference counting and have large pauses.

Plus, of course, other languages such as C# cannot, by design, make use of similar performance improvement techniques.

"State of the art" is about using the latest techniques - and that can be the latest techniques in JIT. There have been many new ideas about how to improve code generation and execution, include compilation (as is usually done with C or C++), byte-code compilation, VM's with some JIT, full JIT, full interpretation, etc. A typical case is to put more effort into compiling and optimising the most frequently used code sections - but identifying them means more overhead in tracking the statistics, and more latency while doing the heavily optimised compilation.

Garbage collection is an orthogonal issue - it can be used in compiled languages, interpreted languages, JIT'ed languages, and any mixture thereof. Yes, people often see it as non-deterministic and an overhead, leading to surprising pauses in execution. In some cases that is true - in others, gc is done in more sophisticated ways. Again there is often a trade-off - over the long term, a system that occasionally does a complete pause of the program and runs through all garbage collection is likely to be more efficient than one that makes frequent small collections with shorter pauses. But for most software, the many small pauses version would be preferable.

You've lost me. Which techniques are you talking about here? If specific techniques were mentioned, I must have missed them.

(I am not very familiar with C#.)

On 03/10/17 11:30, David Brown wrote:

Yes, for soft realtime, not hard realtime.

The HotSpot techniques which observe the code/data patterns that are actually happening at runtime, and optimise the shit out of those.

In contrast, C# is standard ahead-of-time optimisation, and so can only optimise what a compiler guesses might happen.

Curiously, HotSpot-type techniques also work surprisingly well on compiled C/C++ code (including optimised code), as demonstrated by the HP Dynamo experimental compiler.

"Abstract: Dynamic optimization refers to the runtime optimization of a native program binary. This paper describes the design and implementation of Dynamo, a prototype dynamic optimizer that is capable of optimizing a native program binary at runtime. Dynamo is a realistic implementation, not a simulation, that is written entirely in user-level software, and runs on a PA-RISC machine under the HPUX operating system. Dynamo does not depend on any special programming language, compiler, operating system or hardware support. The program binary is not instrumented and is left untouched during Dynamo's operation. Dynamo observes the program's behavior through interpretation to dynamically select hot instruction traces from the running program. The hot traces are optimized using low-overhead optimization techniques and emitted into a software code cache. Subsequent instances of these traces cause the cached version to be executed, resulting in a performance boost. Contrary to intuition, we demonstrate that it is possible to use a piece of software to improve the performance of a native, statically optimized program binary, while it is executing. Dynamo not only speeds up real application programs, its performance improvement is often quite significant. For example, the performance of many +O2 optimized SPECint95 binaries running under Dynamo is comparable to the performance of their +O4 optimized version running without Dynamo."

It is surprising how many people think "JIT==slow" without realising that kind of result.