On Wednesday, 10 May 2017 at 12:18:40 UTC, Patrick Schluter wrote:
On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote:
[...]
The likelihood of a randomly picked C/C++ programmer not even
knowing what a profiler is, much less having used one, is
extremely high in my experience. I worked with a lot of
embedded C programmers with several years of experience who
knew nothing but embedded C. We're talking dozens of people
here. Not one of them had ever used a profiler.
I've worked 10 years in embedded (industry, time acquisition
and network gears) and I can say that there is a good reason to
that. It's nearly impossible to profile in an embedded system
(nowadays it's often possible because of the generalization of
Linux and gnu tools but at that time it wasn't). The tools
don't exist or if they do, the instrumentation breaks the
constraints of the controller. This was also one of the reason
we chose our embedded CPU's very carefully. We always chose
processors for which there existed mainstream desktop versions
so that we could at least use the confortable tooling to test
some parts of the code on a nice environment. We used Z80
(CP/M), 80186 (MS-C on DOS) and then 68030 (Pure-C on Atari TT).
TL;DR profiling for embedded is order of magnitudes harder than
for nice OS environments.
That doesn't mean they shouldn't know what a profiler is. The
response would then be (assuming they're competent) "I wish I
could use a profiler, but I can't because...", not "how can two
programs output the same thing in different amounts of time".
Also, there's a good way around this sort of thing and it applies
to testing as well: run the tools on a development machine (and
the tests). Write portable standards-compliant code, make a thin
wrapper where needed and suddendly you can write tests easily,
run valgrind, use address sanitizer, ...
There's no good reason why you can't profile pure algorithms: C
code is C code and has specified semantics whether it's running
on a dev machine or a controller. The challenge is to write
mostly pure code with thin IO wrappers. It's always a win/win
though.
Atila
