howto count lines - fast

[Russel Winder via Digitalmars-d-learn]

On Fri, 2017-06-02 at 10:32 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
> 
> Also, compiler implementors do still have to do the "heroics", or
> rather, teach the compiler to do the "heroics" when compiling
> straightforward code. So while the general programmer probably will
> have
> less need for it, compiler writers still need to know how to do them
> in
> order to write the optimizing compilers in the first place.

There are many different sorts of programming. Operating systems,
compilers, GUIs, Web services, machine learning, etc., etc. all require
different techniques. Also there are always new areas, where idioms and
standard approaches are yet to be discovered. There will always be a
place for "heroic", but to put it up on a pedestal as being a Good
Thing For All™ is to do "heroic" an injustice.

We should also note that in the Benchmark Game, the "heroic" solutions
are targetted specifically at Isaac's execution machine, which often
means they are crap programs on anyone else's computer.

> […]
> be able to generate optimal code in all cases. There will always be
> cases where you have to manually tweak it yourself.  Of course, that
> doesn't mean you go around micro-optimizing everything -- the usual
> approach is to write it the straightforward way first, then profile
> it,
> identify the hotspots, and find ways to improve performance in the
> hotspots. Well, at a higher level, the first order of business is
> really
> to look at it from an algorithmic POV and decide whether or not a
> different algorithm ought to be used (and no optimizing compiler can
> help you there).  Then if that's still not enough, then you dig into
> the
> details and see if you can squeeze more juice out of your current
> algorithms -- if the profiler has indicated that they are the
> bottleneck.

The optimisations are though generally aimed at the current execution
computer. Which is fine in the short term. However in the long term,
the optimisations become the problem. When the execution context of an
optimised code changes then the optimisations should be backed out and
new optimisations applied. Sadly this rarely happens, and you end up
with new optimisations laid on old (redundant) optimisations, and hence
to incomprehensible code that people darn't amend as they have no idea
what the #### is going on.

> 
[…]
> But *somebody* has to implement those computational models and
> programming languages.  If nobody knows how to write "heroic" code,
> then
> nobody would know how to write an optimizing compiler that produces
> such
> code either, and these computational models and programming languages
> wouldn't exist in the first place.

Which returns us to there are different sorts of programming, and there
are people at "the bleeding edge" of languages, techniques, and
hardware, researching these new things. Or there ought to be, it's just
that you need funds to do it.

> I know that the average general programmer doesn't (and shouldn't)
> care.
> But *somebody* has to, in order to implement the system in the first
> place. *Somebody* had to implement the "heroic" version of memchr so
> that others can use it as a primitive. Without that, everyone would
> have
> to roll their own, and it's almost a certainty that the results will
> be
> underwhelming.

It may be worth noting that far too few supposedly professional
programmers actually know enough about the history of their subject to
be deemed competent. 


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20170603/b9fa9fd8/attachment.sig>