[seqfan] Re: Programming languages

Thu Sep 21 10:32:09 CEST 2023

Sean,
Thanks for your detailed reply
john

On Wed, Sep 20, 2023 at 9:41 PM Sean A. Irvine <sairvin at gmail.com> wrote:

> I would second Allan's comments.
>
> Prior to about Java 1.8 dealing with the overhead of object creation in
> Java was a big problem.  We had a lot of software where we carefully
> managed our own object pools and so on to reduce churn.  For example, it
> was common to run out of memory simply because the garbage collector could
> not keep up.
>
> However these days the garbage collectors are much better and understand
> about short-lived objects so that they can be handled efficiently.  In
> fact, a lot of the things that used to be done now get in the way and
> actually reduce performance.
>
> The same is also true of the runtime optimizations performed by the JIT.
> We used to have some code that we loaded with multiple ClassLoaders within
> the same runtime simply so it could be (JIT) optimized differently with
> different usage patterns.  This gave us a 10x at the time it was done, but
> on never releases of the JVM is probably now a net negative.
>
> Likewise the JIT is looking for particular patterns of code that it knows
> how to deal with. So, for example, taking some of the micro-optimization
> techniques you might use in C across to Java don't always work as expected
> because the JIT no longer recognizes what is going on.
>
> Finally, it is not always true that newer releases of the JVM are faster.
> So if you really must have the best speed possible it is worth trying 1.8,
> 1.11, 1.17, OpenJDK vs Oracle etc. and the best can vary depending on the
> specific code.
>
> Sean.
>
>
> On Thu, 21 Sept 2023 at 06:50, Allan Wechsler <acwacw at gmail.com> wrote:
>
> > I do a lot of programming in Java for my work.
> >
> > If you are concerned about creating a lot of objects that are used only
> > temporarily, and then dropped, you are probably underestimating Java's
> > garbage collector. Java is actually very good at cleaning up transient
> > objects. We've been surprised several times, on occasions where we wrote
> > some code the simple, easy-to-understand way, expecting that we would
> have
> > to go back through it once it was working, and cut back on gratuitous
> > object creation -- only to find that there was no increased load at all,
> > that the Java compiler had figured out that the objects were transient,
> and
> > that they were getting recycled immediately after use.
> >
> > On Wed, Sep 20, 2023 at 1:33 PM John Mason <masonmilan33 at gmail.com>
> wrote:
> >
> > > Hi
> > > Thanks for the replies.
> > > 1. Profiling. I have used profiling in a previous life, probably in C.
> I
> > > will take a look at what Netbeans offers.
> > > 2.  "If it works, for God's sake don't change it". I've paid the price
> > for
> > > not adhering to that rule!
> > > 3. "Aaron Siegel - Polyformer". Interesting video, thanks.
> > > 4. COBOL. Been there. And Assembly Language too.
> > >
> > > I would also be interested if anyone had an opinion on the specific
> > problem
> > > of programming Java with or without objects. I realise that a better
> > > written program will save programming and debugging time. But if a job
> > has
> > > a foreseen runtime of 50 days, maybe some effort in increasing
> efficiency
> > > will be worth it.
> > >
> > > John
> > >
> > > On Wed, Sep 20, 2023 at 7:02 PM SvenHSimon via SeqFan <
> > > seqfan at list.seqfan.eu>
> > > wrote:
> > >
> > > > Having some programming experience too I do not have much
> guidelines. I
> > > > prefer to code with a strikt syntax and with some effort to minimize
> > > those
> > > > small errors. It takes a lot of time to find errors in the code
> later,
> > so
> > > > efforts in advance pay out. Testing is important. On the long run
> > better
> > > > programming is often throwing quicker hardware to unchanged software.
> > So
> > > > still there are Cobol programs - no one wants to pay the cost to
> change
> > > > these old packages.
> > > > Sven
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: SeqFan <seqfan-bounces at list.seqfan.eu> Im Auftrag von Fred
> Lunnon
> > > > Gesendet: Mittwoch, 20. September 2023 18:17
> > > > An: Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
> > > > Betreff: [seqfan] Re: Programming languages
> > > >
> > > > << Premature optimization is the root of all evil. >>
> > > >
> > > >   Perhaps mildly exaggerated ... but excellent advice, nonetheless.
> > > > And incidentally, not unrelated to a more general principle,
> enunciated
> > > by
> > > > R. A. (Tony) Brooker (and doubtless many engineers in many
> disciplines:
> > > >     " If it works, for God's sake don't change it! "
> > > >
> > > >   I (mis-)spent a large part of my youth hand-coding combinatorial
> > > problems
> > > > --- including various polyomino sequences --- in assembly language
> for
> > > > early and now long-deceased computers.I learnt much about software
> > > > implementation that way, but it was an expensive education.
> > > >
> > > >   Probably any relatively inexperienced programmer initially
> approaches
> > > > such challenges from the same direction: sitting down to write the
> most
> > > > efficient program possible, before executing it as much as
> practicable.
> > > > But in the long term, there's so much totally arse-forwards about
> such
> > a
> > > > naïve strategy that it is hard to know where to start (or stop) the
> > > > critique.
> > > >
> > > >   It largely boils down to determining what exactly are you really
> want
> > > to
> > > > achieve:
> > > > more specifically: what criterion of "efficiency" should you attempt
> to
> > > > optimise?
> > > >   Speed of execution?  For square polyominoes, run-time is an
> > exponential
> > > > function of the tile count, so  just one more output will cost 4x as
> > long
> > > > period.
> > > >   Memory usage?  Most speed-up eventually starts to involve caching
> > data
> > > > in tables and running into data size limitations.
> > > >   Programming effort?  For the wet-ware effort devoted to writing one
> > big
> > > > fast program, you might write  k  short small programs for different
> > > > problems, running them in parallel on separate hardware cores,
> > > multiplying
> > > > your productivity  k-fold.
> > > >
> > > >   There are also theoretical obstructions.  From computability
> studies
> > it
> > > > emerges that there exist problems for which _no_ fastest algorithm
> > > exists:
> > > > and this feature  trickles down even into elementary combinatorial
> > > > problems.  And you have already found, you can bust a gut to
> implement
> > > some
> > > > involved algorithmic "improvement", only to discover that it results
> in
> > > no
> > > > practical increase in speed (or even a decrease).
> > > >
> > > >   Finally repetitive wet-ware effort devoted to similar individual
> > > > problems might ultimately have instead been devoted to a more general
> > > > algorithm, designed to input a tile specification, rather than
> simply a
> > > > number of tiles.  For example, have you considered the following, or
> a
> > > > similar approach?
> > > > Aaron Siegel - Polyformer
> > > > https://www.youtube.com/watch?v=8NA4Y5S5dt0
> > > >
> > > >   Of course, if you spend long enough deciding on the optimal
> strategy,
> > > > there is always the risk that you never actually get anything else
> done
> > > at
> > > > all ...
> > > >
> > > > WFL
> > > >
> > > >
> > > >
> > > > On Wed, Sep 20, 2023 at 1:22 PM <hv at crypt.org> wrote:
> > > >
> > > > > John Mason <masonmilan33 at gmail.com> wrote:
> > > > > [...]
> > > > > :With objects: 24 seconds
> > > > > :Without: 24 seconds
> > > > > :So apparently my fears were unjustified.
> > > > > :Does anyone have a similar experience?
> > > > > :Does anyone want to tell me I'm using the wrong programming
> language
> > > > > anyway?
> > > > >
> > > > > Premature optimization is the root of all evil. :)
> > > > >
> > > > > Generally, I'd expect to write the fastest code in the language(s)
> > I'm
> > > > > most familiar with.
> > > > >
> > > > > In most cases, however, I start off not knowing much about a
> problem
> > > > > I'm
> > > > > investigating: at that stage speed and flexibility of development
> are
> > > > > more important than speed of execution.
> > > > >
> > > > > As such I tend in almost all cases to start off exploring and
> > > > > prototyping in Perl (which I know very well), and rewrite in C
> (which
> > > > > I know pretty
> > > > > well) only when I'm fairly confident that a) I won't get execution
> > > > > time down to something reasonable just with Perl, and b) I know
> what
> > > > > algorithms and data structures I'm going to need in C.
> > > > >
> > > > > Of particular value is a good profiler: for Perl we are blessed
> with
> > > > > an especially good one, Devel::NYTProf [1]. I'm not aware of
> anything
> > > > > remotely as powerful for Java (or for C/C++).
> > > > >
> > > > > Hope this helps,
> > > > >
> > > > > Hugo van der Sanden
> > > > >
> > > > > [1] https://github.com/timbunce/devel-nytprof
> > > > >
> > > > > --
> > > > > Seqfan Mailing list - http://list.seqfan.eu/
> > > > >
> > > >
> > > > --
> > > > Seqfan Mailing list - http://list.seqfan.eu/
> > > >
> > > >
> > > > --
> > > > Seqfan Mailing list - http://list.seqfan.eu/
> > > >
> > >
> > > --
> > > Seqfan Mailing list - http://list.seqfan.eu/
> > >
> >
> > --
> > Seqfan Mailing list - http://list.seqfan.eu/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>