In article , Jeff Barnett
wrote:

I bet some embedded stuff for ultra cheap mass market stuff is still
done in assember, or something only very slightly higher level.

Yes. Define "need". Compact code is noticeably more efficient - so runs
faster. Yes, for a lot of things, the returns don't justify the effort -
for a lot of things that are only done once, or where speed doesn't
matter, or - these days - to _some_ extent where modern processor power
can hide the inefficiency of the code.

compact code is not necessarily more efficient. a simple example is an
unrolled loop, which is less compact yet will run faster. another is
having a large lookup table versus calculating a value each time.

That depends on the length of the loop body and the number of
iterations: crossing cache boundaries can extract performance hits. In
fact, unrolling some loops can punish performance by factors of tens or
even hundreds. If you carry your argument far enough and force paging
you may cause arbitrary slow downs. As to look up tables the problems
are the same. If all the values and indices fit in a small amount of
storage (i.e. they are COMPACT), well and good. Otherwise all hell can
break loose.

they were simple examples to make a point. they were not meant to be a
treatise on every possible scenario.

however, modern processors are far from simple, which is one reason why
a compiler can do a better job of optimization than humans can.

Almost always true and more so as the years go by.

yep.

and then there's the issue of portability. anything written in a high
level language can be recompiled for another processor, normally with
little to no problem, whereas anything in assembler would need to be
entirely rewritten from scratch.

Unless you are coding in C or one of its derivatives. There are enough
places where a C compiler can choose the meaning of an expression (and
not necessarily consistently) that you have to code in a modest subset
of the language. And find a compatible compiler for portability.

c is not an issue unless the programmer makes mistakes and ignores any
compiler warnings.

I suspect IrfanView, for example, is mostly coded in either assembler,
or at least quite low-level code (or just possibly using an excellent
optimiser - which are rare with ultra-high-level languages, such as
scripting interpreters).

Scripting interpreters are not a good example of an "ultra-high-level"
anything. Most are, in fact, among the worst documented, least reliable,
and least consistent from version to version of any software meant to be
used by non developers of that software. Of course you may argue that
they are completely consistent since documentation typically gives no
serious details of what is supposed to be done in boundary cases.

irfanview isn't using a scripting interpreter.

it's highly unlikely any of it is in assembler.