Fantastic exchange from DConf
Adrian Matoga via Digitalmars-d
digitalmars-d at puremagic.com
Sun May 14 05:04:54 PDT 2017
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.
IMO it's just different. The thing is, the tools you can use
don't need to be marketed as "profilers".
People will always find excuses if they lack time, will or
knowledge. In practice, there's always a way to profile and
debug, even if you don't have dedicated tools for it. It's also a
lot easier to reason about performance on small chips with no
caches, ILP, etc. and with fixed instruction timing, than it is
on modern complex CPUs with hundreds of tasks competing for
resources.
One universal tool is oscilloscope, for sure you have one on your
colleague's desk if you really do embedded stuff. A common way to
profile on home computers from the '80s such as Atari XE (6502),
was simply to change screen colors. That way you always knew the
time taken by the measured code with 1-cycle precision. 13.5
scanlines are white? That's 1539 cycles! The time it took to
execute a tight loop could even be computed accurately with pen
and paper by just looking at the assembly. It's also a lot easier
to implement a cycle-exact emulator for such simple chips, and
then you can measure everything without observer effect.
More information about the Digitalmars-d
mailing list