[COFF] Fwd: Old and Tradition was [TUHS] V9 shell

Wed Feb 12 13:01:52 AEST 2020

I'm following this with some interest, though I don't have a horse in
this race, hell, I'm not even at the race track.  But still, interesting.

What little Fortran background I have suggests that the difference
might be mind set.  Fortran programmers are formally trained (at least I
was, there was a whole semester devoted to this) in accumulated errors.
You did a deep dive into how to code stuff so that the error was reduced
each time instead of increased.  It has a lot to do with how floating
point works, it's not exact like integers are.  

For the record, I *hate* floating point, for numerical work in C I have
always tried to have "domains", these 32 bits cover the domain from
0..2^32-1, these 32 bits cover the domain from 0..2^32-1 * 2^32, etc.
It's more work because you have to translate across domains but it
is exact.  Floating point lets you cheat but the price of cheating is
the accumulated error.

Maybe I'm just going off of my 35 year old training, but it seems to me
that Fortran people pretty much live in floating point, and get what you
have to do to make that work.  C / python / systems people "understand"
floating point but don't understand what you have to do to make that work.
They think they do, but they mostly don't, they just haven't hit the
accumulated error problem and wouldn't recognize it if they did.

What do you guys think?

On Tue, Feb 11, 2020 at 08:58:50PM -0500, Clem Cole wrote:
> Fwiw.  I'm sure your observations are solid and do make some good sense for
> you.
> 
> But I ask you to consider the words you used defending your choices are
> almostly exactly what was said by my CS profs at CMU and UCB on the 1970s
> but it was Pascal not C++ and Snobol not Python as the scripting front end.
>  40 yrs later Fortran has matured but as Stu Feldman famously said in 1977
> - he did not what it would look like but in the future (year 2000) we will
> still call it Fortran.  He was right and we still do.
> 
> Hey I'm a die hard systems person  and as I said C is my primary tool to do
> my own job (I don't write in Fortran) but I do understand what pays my
> salary (and has my entire career).  My experience has always been that
> Scientists (of both sexs) don't care about the computer language nearly as
> much as they do about getting their science done and trusting the data sets
> that describe it.
> 
> Don't take my word for it. Look at the URL I gave you.  Check out the same
> data from the other big sites around the world - USA, UK, EU, JP, CN, RU,
> and IN.  I think you'll discover similar graphics. Fortran has been pretty
> much constant at #1.   What has changed over the years is the languages
> used to prep the scientific data before running it throught the primary HPC
> tool.
> 
> We can take this off line if you like but imo the reason has been/continue
> s to be - is economics of the existing code base is extremely difficult to
> displace.   It's not an old guy / new guy thing.  It's when you get money
> to do your science it's not cost effective to replace something you trust
> just because you don't like the computer language.
> 
> More over i know of only one case we're a production code originally
> written in Fortran was successfully replaced - in grad school years ago, my
> old housemate Tom Quarles wrote SPICE3 in C to replace the original SPICE2.
>  but note Tom had to do a huge amount of work to maintain the performance.
> I also know of a couple of other commercial Mech E CAD and one Oil and Gas
> code that tried to go to C++ but fell back to the original Fortran.
> 
> Anyway best wishes but be careful.   Noel's email has much wisdom.  New is
> not necessarily better and old fashioned is not always a bad thing.
> 
> Clem
> 
> On Tue, Feb 11, 2020 at 7:57 PM Adam Thornton <athornton at gmail.com> wrote:
> 
> >
> >
> > ---------- Forwarded message ---------
> > From: Adam Thornton <athornton at gmail.com>
> > Date: Tue, Feb 11, 2020 at 5:56 PM
> > Subject: Re: [COFF] Old and Tradition was [TUHS] V9 shell
> > To: Clem Cole <clemc at ccc.com>
> >
> >
> > As someone working in this area right now....yeah, and that???s why
> > traditional HPC centers do not deliver the services we want for projects
> > like the Vera Rubin Observatory???s Legacy Survey Of Space and Time.
> >
> > Almost all of our scientist-facing code is Python though a lot of the
> > performance critical stuff is implemented in C++ with Python bindings.
> >
> > The incumbents are great at running data centers like they did in 1993.
> > That???s not the best fit for our current workload.  It???s not generally the
> > compute that needs to be super-fast: it???s access to arbitrary slices
> > through really large data sets that is the interesting problem for us.
> >
> > That???s not to say that that lfortran isn???t cool.  It really really is, and
> > Ondrej Cestik has done amazing work in making modern FORTRAN run in a
> > Jupyter notebook, and the implications (LLVM becomes the Imagemagick of
> > compiled languages) are astounding.
> >
> > But...HPC is no longer the cutting edge.  We are seeing a Kuhnian paradigm
> > shift in action, and, sure, the old guys (and they are overwhelmingly guys)
> > who have tenure and get the big grants will never give up FORTRAN which
> > after all was good enough for their grandpappy and therefore good enough
> > for them.  But they will retire.  Scaling out is way way cheaper than
> > scaling up.
> >
> > On Tue, Feb 11, 2020 at 11:41 AM Clem Cole <clemc at ccc.com> wrote:
> >
> >> moving to COFF
> >>
> >> On Tue, Feb 11, 2020 at 5:00 AM Rob Pike <robpike at gmail.com> wrote:
> >>
> >>> My general mood about the current standard way of nerd working is how
> >>> unimaginative and old-fashioned it feels.
> >>>
> >> ...
> >>>
> >>> But I'm a grumpy old man and getting far off topic. Warren should cry,
> >>> "enough!".
> >>>
> >>> -rob
> >>>
> >>
> >> @Rob - I hear you and I'm sure there is a solid amount of wisdom in your
> >> words.   But I caution that just, because something is old-fashioned, does
> >> not necessarily make it wrong (much less bad).
> >>
> >> I ask you to take a look at the Archer statistics of code running in
> >> production (Archer large HPC site in Europe):
> >> http://archer.ac.uk/status/codes/
> >>
> >> I think there are similar stats available for places like CERN, LRZ, and
> >> of the US labs, but I know of these so I point to them.
> >>
> >> Please note that Fortran is #1 (about 80%) followed by C @ about 10%,
> >> C++ @ 8%, Python @ 1% and all the others at 1%.
> >>
> >> Why is that?   The math has not changed ... and open up any of those
> >> codes and what do you see:  solving systems of differential equations with
> >> linear algebra.   It's the same math my did by hand as a 'computer' in the
> >> 1950s.
> >>
> >> There is not 'tensor flows' or ML searches running SPARK in there.
> >> Sorry, Google/AWS et al.   Nothing 'modern' and fresh -- just solid simple
> >> science being done by scientists who don't care about the computer or sexy
> >> new computer languages.
> >>
> >> IIRC, you trained as a physicist, I think you understand their thinking.  *They
> >> care about getting their science done.*
> >>
> >> By the way, a related thought comes from a good friend of mine from
> >> college who used to be the Chief Metallurgist for the US Gov (NIST in
> >> Colorado).  He's back in the private sector now (because he could not
> >> stomach current American politics), but he made an important
> >> observation/comment to me a couple of years ago.  They have 60+ years of
> >> metallurgical data that has and his peeps have been using with known
> >> Fortran codes.   If we gave him new versions of those analytical programs
> >> now in your favorite new HLL - pick one - your Go (which I love), C++
> >> (which I loath), DPC++, Rust, Python - whatever, the scientists would have
> >> to reconfirm previous results.  They are not going to do that.  It's not
> >> economical.   They 'know' how the data works, the types of errors they
> >> have, how the programs behave* etc*.
> >>
> >> So to me, the bottom line is just because it's old fashioned does not
> >> make it bad.  I don't want to write an OS in Fortran-2018, but I can wrote
> >> a system that supports code compiled with my sexy new Fortran-2018 compiler.
> >>
> >> That is to say, the challenge for >>me<< is to build him a new
> >> supercomputer that can run those codes for him and not change what they are
> >> doing and have them scale to 1M nodes *etc*..
> >>
> >> _______________________________________________
> >> COFF mailing list
> >> COFF at minnie.tuhs.org
> >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
> >>
> > _______________________________________________
> > COFF mailing list
> > COFF at minnie.tuhs.org
> > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
> >
> -- 
> Sent from a handheld expect more typos than usual

> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 