[seqfan] Re: Programming languages

[Alonso Del Arte]

Allan's definitely right, the JVM garbage collector has gotten very good. A
lot of work has been done on young generation tagging, minimizing pause
targets and reducing the need for stop-the-world collection events.

At about the same time Java first came out, I was adapting Mandelbrot and
Julia set programs for QBasic. It took about five minutes to draw the
Mandelbrot set, no zoom.

Last year, I wrote a Mandelbrot set drawing program for Java. I had already
written a ComplexNumber class so I decided to give that a whirl in a
Mandelbrot/Julia viewer. I worried it would be too slow and then I'd have
to rewrite it hard-coding complex number addition and multiplication in
loose primitives like in my old QBasic program. To my surprise, my Java
program drew the Mandelbrot set no zoom in like not even a second. That's
gotta be like a million ComplexNumber objects going through young
generation collection to make thousands of changes to a single Graphics
object in old generation.

So, to calculate a B-file for the OEIS using a data structure for a few
thousand integers, even if there's a lot of boxing and unboxing going on,
it's nothing to worry about.

Al

On Thu, Sep 21, 2023, 4:32 AM John Mason <masonmilan33 at gmail.com> wrote:

> 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/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>