From: antispam@fricas.org
Michael S wrote:
> On Fri, 17 Oct 2025 20:54:23 GMT
> MitchAlsup wrote:
>
>> George Neuner posted:
>>
>> >
>> >
>> > Hope the attributions are correct.
>> >
>> >
>> > On Wed, 15 Oct 2025 22:31:32 GMT, MitchAlsup
>> > wrote:
>> >
>> > >
>> > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= posted:
>> > >
>> > >> On Wed, 15 Oct 2025 05:55:40 GMT, Anton Ertl wrote:
>> > >>
>> > :
>> > >> > In any case, even with these languages there are still
>> > >> > software projects that fail, miss their deadlines and have
>> > >> > overrun their budget ...
>> > >
>> > >A lot of these projects were unnecessary. Once someone figured out
>> > >how to make the (17 kinds of) hammers one needs, there it little
>> > >need to make a new hammer architecture.
>> > >
>> > >Windows could have stopped at W7, and many MANY people would have
>> > >been happier... The mouse was more precise in W7 than in W8 ...
>> > >With a little upgrade for new PCIe architecture along the way
>> > >rather than redesigning whole kit and caboodle for tablets and
>> > >phones which did not work BTW...
>> > >
>> > >Office application work COULD have STOPPED in 2003, eXcel in 1998,
>> > >... and few people would have cared. Many SW projects are driven
>> > >not by demand for the product, but pushed by companies to make
>> > >already satisfied users have to upgrade.
>> > >
>> > >Those programmers could have transitioned to new SW projects
>> > >rather than redesigning the same old thing 8 more times. Presto,
>> > >there is now enough well trained SW engineers to tackle the undone
>> > >SW backlog.
>> >
>> > The problem is that decades of "New & Improved" consumer products
>> > have conditioned the public to expect innovation (at minimum new
>> > packaging and/or advertising) every so often.
>> >
>> > Bringing it back to computers: consider that a FOSS library which
>> > hasn't seen an update for 2 years likely would be passed over by
>> > many current developers due to concern that the project has been
>> > abandoned. That perception likely would not change even if the
>> > author(s) responded to inquiries, the library was suitable "as is"
>> > for the intended use, and the lack of recent updates can be
>> > explained entirely by a lack of new bug reports.
>>
>> LAPAC has not been updated in decades, yet is as relevant today as
>> the first day it was available.
>>
>
> It is possible that LAPAC API was not updated in decades, although I'd
> expect that even at API level there were at least small additions, if
> not changes. But if you are right that LAPAC implementation was not
> updated in decade than you could be sure that it is either not used by
> anybody or used by very few people.
AFAICS at logical level interface stays the same. There is significant
change: in old times you were on your own trying to interface
Lapack from C. Now you can get C interface.
Concerning implementation, AFAICS there are changes. Some
improvemnts to accuracy, some to speed. But bulk of code
stays the same. There is a lot of work on lower layer, that
is BLAS. But the idea of Lapack was that higher level algorithms
are portable (also in time), while lower level building blocks
must be adapted to changing computing environment.
There were attempt to replace Lapack by C++ templates, I do not
see this gaining traction. There were attempts to extent Lapack
to larger class of matrices (mostly sparse matrices), apparently
this is less popular than lapack.
There are attempts to automatically convert simple high level
description of operations into high performance code. IIUC
this has some success with FFT and few similar things, but
currently is unable to replace Lapack.
I would say the following: if you have good algorithm, this
algorithm may live long. Sometimes better things are invented
later, but if not, then old algorithm may be used quite long.
Goal of algorithmic languages was to make portable implementation
of algorithms. That works reasonably well, but if one aims
at highest possible speed, then needed tweaks freqiently are
machine specific, so good performance may be nonportable.
In case of Lapack, it seems that there are no better algorithms
now compared to time when Lapack was created. Performance of
Lapack on larger matrices depends mostly on performace of
BLAS, so there is a lot of current work on BLAS. IIUC sometimes
Lapack routines are replaced by better performing versions,
but most of the time gain is too small to justify the effort.
Concerning "being used by few people": there are codes which
are sold to a lot of users were performance or features
matter a lot, such codes tend to evolve quickly. More
typical is growth by adding new parts: old parts are kept
with small changes, but new things are build on it (and
new things independent of old thing are added). There is
also popular "copy and mutate" approach: some parts are
copied and them modified to provide different function
(examples of this are drivers in an OS or new frontends
in a compiler). However, this is partially weakness of
programming language (it would be nicer to have clearly
specified common part and concise specification of
differences needed for various cases). Partly this is
messy nature of real world. Lapack is a happly case
when problem was quite well specified and language
was reasonable fit for the problem. They use textual
substitution to produce real and complex variants
for single and double precision, so in principle
language could do more. And certainly one could wish
nicer and more compact description of the algorithms.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
