Fantastic exchange from DConf

[Atila Neves via Digitalmars-d]

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