Language feature selection

George Neuner wrote:
> On Fri, 10 Mar 2017 16:49:21 -0700, Don Y
<snip>
>
> Once you introduce heap-based closures the lifetime of closures
> becomes indefinite: it can be *estimated* by a compiler - e.g., using
> region analysis - but runtime GC generally is better at noticing
> disuse in a timely fashion.  Module reference counting by the compiler
> is no longer sufficient and must be augmented by runtime GC.
>
>

IMO, this is and always will be difficult, and it's never been that
clear to me that  simply constructing systems of frames of objects
that are explicit in lifetime isn't more rigorous and more
deterministic.

I have also found that having all closures have the same lifetime as the 
main program/thread that owns them to not be that big of a burden.
If something needs a transient lifespan, I'd be happier if it were made
explicit and transactional.

But I like the 50,000 foot view, which is declining
in popularity.

<snip>
>
> George
>

-- 
Les Cargill

On 3/11/2017 3:35 PM, Les Cargill wrote:
> George Neuner wrote:

>> Once you introduce heap-based closures the lifetime of closures
>> becomes indefinite: it can be *estimated* by a compiler - e.g., using
>> region analysis - but runtime GC generally is better at noticing
>> disuse in a timely fashion.  Module reference counting by the compiler
>> is no longer sufficient and must be augmented by runtime GC.
>
> IMO, this is and always will be difficult, and it's never been that
> clear to me that  simply constructing systems of frames of objects
> that are explicit in lifetime isn't more rigorous and more
> deterministic.

The problem then shifts to handling different lifetime extents.
E.g., it's not uncommon for a "program" to "run forever" (c.a.e).
At the same time, it is very possible for portions of it to "come
and go" with some frequency.

How do you address the differences in resource constrained
(regardless of the magnitude of those resources) systems and
those that are more open?  E.g., zombie processes are no big
deal on a desktop machine.  But, in a machine with tighter
constraints, you want to harvest the zombie earlier, rather
than later.

> I have also found that having all closures have the same lifetime as the main
> program/thread that owns them to not be that big of a burden.

How do you define ownership?  Does init() own the objects that it instantiates?
Does init() then need to persist beyond the cumulative lifespans of all of
those surrogates?  Does init() transfer ownership to some other entity after
instantiating it (or an object that it uses)?

> If something needs a transient lifespan, I'd be happier if it were made
> explicit and transactional.

Why not *implicit*?  Let some active entity (e.g., OS) take responsibility
for the clean-up?

> But I like the 50,000 foot view, which is declining
> in popularity.

Walter Banks wrote:
> On 2017-03-10 8:14 PM, Paul Rubin wrote:
>> Walter Banks <walter@bytecraft.com> writes:
>>>> Do you mean C?
>>> More like the whole crop of interpreted languages now being used.
>>
>> Oh ok, but those languages are generally sugared-up re-inventions of
>> Lisp, which is even older than C, and which the cogniscenti have
>> been using all along ;-).  E. W. Dijkstra in his Turing Award lecture
>> back in 1972 had already observed:
>>
>> With a few very basic principles at its foundation, it [LISP] has
>> shown a remarkable stability. Besides that, LISP has been the carrier
>> for a considerable number of in a sense our most sophisticated
>> computer applications. LISP has jokingly been described as "the most
>> intelligent way to misuse a computer". I think that description a
>> great compliment because it transmits the full flavour of liberation:
>> it has assisted a number of our most gifted fellow humans in thinking
>> previously impossible thoughts.
>>
>> By all means give the interpreters a try if you haven't.  They make
>> programming more productive along several axes, at the cost of some
>> hardware resources (cpu and memory) that are generally plentiful
>> with today's computers.
>>
>>> I tend to think of C as something of our generation.
>>
>> Yes, I was less surprised that good stuff was being done in
>> interpreted languages, as that it's now relatively rare for even
>> their expert users to have ever used C for anything.
>>
> It is our generation that is obsessed with optimization execution and
> data space. Some of the programs I have seen be developed in by these
> people tend to be using algorithms that are exchanging our sense of
> optimization for application performance. (VR applications for example)
>
> Related to that we have almost always treated processor resources as a
> rare resource and when I changed that mind set on some of the massively
> parallel systems I have been working on to processors are just a
> resource that needs to be managed like memory in applications I was
> suddenly seeing huge leaps in application performance.
>
> w..
>
>


We've been at the von Neumann bottleneck for close to 20 years now
for most architectures. I haven't seen anything CPU bound in a very
long time, but I'm not in that market space.

With CUDA, anything is increasingly possible.

-- 
Les Cargill

On Sat, 11 Mar 2017 14:20:27 -0800 (PST), jim.brakefield@ieee.org
wrote:

>On Saturday, March 11, 2017 at 7:42:00 AM UTC-6, Niklas Holsti wrote:
>> On 17-03-11 04:46 , jim.brakefield@ieee.org wrote:
>> > On Sunday, March 5, 2017 at 8:43:28 PM UTC-6, Don Y wrote:
>> >> A quick/informal/UNSCIENTIFIC poll:
>> >>
>> >> What *single* (non-traditional) language feature do you find most
>> >> valuable in developing code?  (and, applicable language if unique
>> >> to *a* language or class of languages)
>> >
>> > A plug for array operators: as in Numpy, IDL/PV~wave, APL and Julia.
>> > That is: array and vector operators baked into the language.
>> 
>> In a language that allows operator overloading, programmers can define 
>> their own array operators.
>> 
>> > I've found that programming at this level yields shorter programs with
>> > less debugging: You windup making your data structures and algorithms
>> > use the fewest operators possible/practical.
>> 
>> I agree that array operators are useful, but only for relatively simple 
>> cases such as the basic arithmetic operations on arrays. However, taking 
>> it to the APL extreme with complex vector/matrix restructurings (outer 
>> products, lamination, ...) can create code that is hard for others to 
>> understand.
>> 
>> > There is a theoretical vantage point for this style of programming
>> > (which I call "programming in the large" as opposed to "programming
>> > in the small"):
>> 
>> You may call it that, but I hope you know that most people understand 
>> these large/small terms differently; see 
>> https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small.
>> 
>> 
>> -- 
>> Niklas Holsti
>> Tidorum Ltd
>> niklas holsti tidorum fi
>>        .      @       .
>
>]> You may call it that, but I hope you know that most people understand 
>]> these large/small terms differently; see 
>
>Was not aware of this definition.  Tend to consider this type of "programming in the large" as solving an organizational problem and an architectural problem.
>
>Another form of programming in the large is characterized by provisioning a complete 64-bit computer: e.g. one with a complete 64-bit address space.
>
>]> I agree that array operators are useful, but only for relatively simple 
>]> cases such as the basic arithmetic operations on arrays. However, taking 
>]> it to the APL extreme with complex vector/matrix restructurings (outer 
>]> products, lamination, ...) can create code that is hard for others to 
>]> understand.
>
>My experience was with scientific programming, so yes this argument has some validity.  Am still convinced that it is a useful exercise: Push low level details down into the operators and data structures, consider the various ways of doing this so that the high level operators (that need to be written) emerge.
>
>Also consider programming well with "array" operators to require greater experience, know-how and good judgement than doing low level coding.
>
>Jim Brakefield

FORTRAN had complex number support from the beginning.

The array support has been added more recently. It seems that array
support was added ,more recently.. IMHO Fortran is still a viable
option for solving mathematical problems after recent updates.

On 11/03/17 22:19, Don Y wrote:
> On 3/11/2017 2:58 PM, Tom Gardner wrote:
>> On 11/03/17 20:05, Don Y wrote:
>>> On 3/10/2017 5:46 PM, Tom Gardner wrote:
>>>> On 11/03/17 00:02, Don Y wrote:
>>>>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>>>>> Most of my time now is working on both tools and ISA's. There has been
>>>>>> some really significant changes in both approaches to compiling for
>>>>>> heterogeneous parallel environments and execution environments that have
>>>>>> hundreds to thousands of processors in them.
>>>>>
>>>>> But they are (largely) *static* environments (?).  The toolchain doesn't
>>>>> have to decide when to bring another processor on-line... or, when it can
>>>>> retire a running processor and migrate its workload to some OTHER
>>>>> processor, etc.  Or, which aspects of an application should be bound
>>>>> to specific processors (nearness of related I/Os) and which aspects
>>>>> should AVOID particular processors (as they were in insecure locations).
>>>>
>>>> The more advanced toolchains are doing similar things.
>>>> They instrument themselves, determine what the code+data
>>>> is *actually* doing at runtime, and optimise the **** out
>>>> of that.
>>>
>>> I don't see how that can happen -- unless you can force all possible
>>> uses of the code to occur while that analysis is being undertaken.
>>
>> That would be counterproductive, since you want to
>> optimise the common case. (Just like hardware and
>> software caches do).
>
> But "common" may have little *value*.  E.g., I can tolerate my
> ECU producing a slightly richer burn but can't tolerate my
> brakes failing to respond in a timely fashion.

Caches have exactly the same properties.
So how do you ensure your systems have absolutely no
caches, neither hardware nor software?

If you have caches, you have statistical timings,
and hence your brakes could fail to respond in a
timely fashion.


> How many pixels in a multimegapixel image can you afford to
> corrupt, slightly, before the picture becomes unrecognizable as
> such?  OTOH, if you fail to snap the shutter when commanded...
>
>> For a surprising example of where an experimental lab
>> investigation became vaguely practical, see
>> http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
>> http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
>>
>>> E.g., if it never sees you hit the brake pedal in your vehicle,
>>> it's likely to spend a lot of effort optimizing ignition timing,
>>> thinking "brakes" are never/seldom used!  :>
>>>
>>>> That's as opposed to what the compiler can guess they
>>>> are doing and where a compiler has to make pessimising
>>>> assumptions.
>>>>
>>>> And such techniques also work with C. For 18 year old
>>>> (gulp) results, google for "hplb dynamo".
>>>>
>>>> And don't forget that some related techniques are implemented
>>>> in processor's hardware microarchitecture.
>>>>
>>>>> [Simulations of my first workload scheduler immediately brought every
>>>>> processor online and kept them there!  D'uh!]
>>>>>
>>>>> I've found it "trying" to come up with even a suitable set of criteria
>>>>> by which to constrain these choices.  E.g., "performance" can be evaluated
>>>>> in a variety of ways:  throughput, response time, power consumption,
>>>>> redundancy, etc.  Just coming up with *a* set of criteria is a challenge.
>>>>> And, if the user can bias this at run-time, it becomes even more
>>>>> challenging!  (perhaps userX might be willing to suffer slower response
>>>>> times for reduced power consumption?)
>>>>>
>>>>> [As I get older, I am encountering more applications where The Right Answer
>>>>> is really elusive and often not available "at compile time".  *Or*, even
>>>>> DESIGN TIME!  (I'm still at a loss to forumulate a test suite to score
>>>>> the performance of the different speech synthesizer implelmentations I've
>>>>> created -- let alone their "costs"!  sqrt(3) = 1.732 is a "better" answer
>>>>> than sqrt(3) = 1.7; but, how do you decide which pronunciation of which
>>>>> utterance is "better" -- and, how to weight the performances of the
>>>>> limitless number of POSSIBLE uterances to come up with a composite score??)]
>>>>
>>>> You are correct in presuming that you can't do an
>>>> optimal job at compile time, since the information
>>>> isn't there - and can't be there.
>>>
>>> I contend that there are huge classes of "programs" (this is c.a.E, right?)
>>> that would fail miserably with such an approach.  You're not processing
>>> payroll where you can tweek umpteen gazillion iterations of the same loop.
>>> Rather, you are at the mercy of the events that transpire in the environment
>>> AND some externally sourced notion of relative "values" (neglecting timeliness
>>> for the moment).
>>
>> If by "embedded" you mean "tiny", then I agree these
>> techniques are not currently very useful.
>
> No.  Embedded means nothing of the sort.  Rather, it signifies applications
> that tend to be driven by events sensed in the environment.  Where do I specify
> the average interarrival time of a particular event?  Or, combinations and
> interactions of events?  How do I indicate that this is "typical" behavior
> vs. worst case?  How do you know that the "optimizations" it has chosen
> make sense in any but THAT case?

Telecom call control systems have all those characteristics,
therefore telecom call control systems can be considered
to be embedded systems.

I've embedded timing measurements in my systems (over
some objections I might note). They were subsequently
used to prove that my system was fast and another
manufacturer's system was too slow culprit. There were
no objections to my PDF/CDF histograms after that :)


> How do I tune my current system without knowing what one particular set of
> users will consider "normal use" -- which may differ dramatically from what the
> next set of users will consider normal?  What if their usage patterns change
> over the course of the product's lifetime?  Or, over the course of a single
> *day*?  Should I optimize the video channel?  Audio?  Speech recognition?
> Synthesis?

You don't; in practice you couldn't do such
micro-optimisations. The system measures
itself and optimises itself depending on what
it finds.

It keeps monitoring itself and keeps re-optimising
its performance as conditions change.

The first versions of such optimisations appeared in
1986, in a Smalltalk implementation. Vastly improved
techniques were developed in the late 90s, and they
have been standard in deployed systems for over a
decade.


> The needs of presenting OTA video to a user differ considerably from those
> of *storing* OTA video for later playback!  How do I balance the resources
> devoted to these tasks -- when either, neither or *both* may be required
> at any given instant?  How does the tool know what resources are available
> *now* to meet the present workload?
>
>> OTOH I have used them successfully in HA soft realtime
>> telecom call processing systems. Those can reasonably
>> be regarded as "large" embedded systems.
>
> That's akin to a payroll system.  Reasonably constant, consistent
> traffic.  How often does it have to manage the fire suppression
> equipment protecting the switch?  Or, deal with folks entering the
> building via the front doorway?

No, it is not.

There are soft realtime performance obligations; if
the call is not placed within a defined time the
subscribers get annoyed and the network operators
start throwing chairs around meeting rooms.

Ditto if a subscriber runs out of credit and all parts
of the multimedia the call are not terminated at the
right time.

"HA" is high availability, so it has to cope with bits
of the system disappearing and reappearing without
warning. In a payroll system the transactions can be
(and sometimes are) re-run from the event logs; that's
conceptually impossible in telecom call-control systems,
for obvious reasons.



> A control system on a warship operates in hugely different conditions
> based on whether it is sailing "at peace", "on alert" or actively
> engaged in a firefight.  Does the code get rewritten as the warship
> transitions between these states?  Which is the "common case"?
> Is it defined by number of instructions executed in that state?
> Or, total elapsed time, there?  Or, the *value* of its performance
> in that state?
>     "We're really efficient at sailing on the open seas but our
>     maneuvering while under fire is really shitty!"
>
>>>> The bonus of avoiding getting toolchains to make
>>>> premature optimisations, is that the same runtime
>>>> optimisation techniques also work with different
>>>> processors.
>>>
>>> That would depend on the nature of those optimizations and their potential
>>> consequences.  Replacing an ADD with a SHIFT (assuming the SHIFT was more
>>> economical) isn't going to "color" the result, significantly.
>>>
>>> And, an application ("program") can behave differently in different
>>> execution environments -- optimizations intended to exploit cache
>>> would be wasted on a system without cache; applications hosted in
>>> a paged memory management environment will benefit from different
>>> optimizations than the same application running in a flat/unpaged
>>> environment; etc.
>>
>> If you have hard realtime embedded systems, all caches
>> are problematic since they are by definition statistical
>> in nature.
>
> Doesn't matter if HRT, SRT or NON real-time.  The point is the
> behavior changes.  Same source code.

I don't understand your point.


>> IIRC the i960 processor had a crude mechanism for freezing
>> its caches, to avoid such issues.
>>
>>>> There are disadvantages, of course. TANSTAFFL.
>

On 2017-03-11 1:43 PM, Tom Gardner wrote:
> On 11/03/17 13:19, Walter Banks wrote:
>> On 2017-03-11 3:59 AM, Tom Gardner wrote:
>>> On 11/03/17 02:16, Paul Rubin wrote:
>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>>>>> There are at least 2 compilers which do whole program
>>>>>> alias analysis.
>>>>>
>>>>> How do they do that if the program includes a library for
>>>>> which the source is not available, and for which the compiler
>>>>> flags are not known?
>>>>
>>>> "Whole program" means the compiler has all of the source code
>>>> and can munch it all as a single piece.  All kinds of added
>>>> optimizations are then possible.
>>>
>>> I thought you would say that.
>>>
>>> It means such alias analysis is impossible in many (most?)
>>> applications.
>>>
>> Yes and no. Libraries can still be precompiled and don't need
>> sources as long as the object format has the information the
>> compiler needs for its analysis.
>
> Very plausible.
>
> Does that occur with common tools, or are "specialist" tools required
> for the entire system being compiled?
>
When we are compiling without linking,libraries can be objects or
source. (Actually it is also possible to include pre-compiled code
objects) The difference is essentially library functions are only part
of the generated code if they are referenced by the application.

Most of our tools are used in embedded system applications and are by
your definition "specialist"

w..

On 2017-03-11 1:53 PM, Don Y wrote:
>> It is our generation that is obsessed with optimization execution and
>> data space.
>
> Agreed (as I stated elsewhere).  But this is only natural given our
> "upbringing" -- in much the same way that folks who lived through
> The Great Depression are far less likely to discard items than those
> who grew up in "times of plenty".
>
> And, while hardware has grown cheaper and more capable over the years,
> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards!

Developers have discovered that updating old 8 bit applications to run 
on modern 32 bit general purpose processors have had a hidden cost.
Some applications are better suited to small processors for code size 
and a variety of things emi from chips due to increased width of the 
data buses and board layout issues.

w..

On 3/12/2017 8:45 AM, Walter Banks wrote:
> On 2017-03-11 1:53 PM, Don Y wrote:
>>> It is our generation that is obsessed with optimization execution and
>>> data space.
>>
>> Agreed (as I stated elsewhere).  But this is only natural given our
>> "upbringing" -- in much the same way that folks who lived through
>> The Great Depression are far less likely to discard items than those
>> who grew up in "times of plenty".
>>
>> And, while hardware has grown cheaper and more capable over the years,
>> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards!
>
> Developers have discovered that updating old 8 bit applications to run on
> modern 32 bit general purpose processors have had a hidden cost.
> Some applications are better suited to small processors for code size and a
> variety of things emi from chips due to increased width of the data buses and
> board layout issues.

Of course!  Small processors also tend to offer more predictable performance,
lower power consumption, etc.

But, beyond it all, cost is still a huge factor in many applications.
When your end-user price is $20, there's not much room for "unnecessary"
silicon, regardless of how much development time you *might* trim off
your schedule, "ease of maintenance", etc.

On 12.3.2017 г. 17:45, Walter Banks wrote:
> On 2017-03-11 1:53 PM, Don Y wrote:
>>> It is our generation that is obsessed with optimization execution and
>>> data space.
>>
>> Agreed (as I stated elsewhere).  But this is only natural given our
>> "upbringing" -- in much the same way that folks who lived through
>> The Great Depression are far less likely to discard items than those
>> who grew up in "times of plenty".
>>
>> And, while hardware has grown cheaper and more capable over the years,
>> you still don't see 32b CPU's in *mice* or debouncing keys in keyboards!
>
> Developers have discovered that updating old 8 bit applications to run
> on modern 32 bit general purpose processors have had a hidden cost.
> Some applications are better suited to small processors for code size
> and a variety of things emi from chips due to increased width of the
> data buses and board layout issues.
>
> w..

Hi Walter,

I had - still have - some work done in the 80-s I don't have to part
with. It was done on a 6809 (under MDOS, the OS which used to run
on Motorola's Exorsiser systems, back then I ran it on hardware I had
built with ROM (BIOS as they now have it) I had written).
So what did it cost me? A few weeks of work to emulate the 6809
system I had on a Power architecture processor running under DPS.
46 kilobytes of code; this includes a terminal emulation (my graphics
terminal I had designed back then), can be run in multiple instances
in multiple windows - and runs about 50 times faster than the original
2MHz 09 ran (in fact than two of them, one was in the graphics
terminal, interfaced via a parallel FIFO-ed cable to the system board;
the terminal board was not emulated as if running on a 6809, just
its functionality (was easier using the dps graphics services)).

The silicon all this can run on is certainly cheaper than it
could have been back in the 80-s with the 6809...

I am not contradicting your point of course, I am sure the hidden
costs you refer to do exist. But this is probably when people
try to replicate a device programmed 30 years ago cleanly with
some new high level language stuff put together by todays
popular methods (which are very messy in my book by this is
another matter).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Sat, 11 Mar 2017 01:32:04 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 11/03/17 01:22, George Neuner wrote:
>
>> There are at least 2 compilers which do whole program alias analysis.
>
>How do they do that if the program includes a library
>for which the source is not available, and for which
>the compiler flags are not known?

Obviously "whole" analysis can't be done in that situation.  However,
in that situation, it isn't needed either.

Libary code can see only what data is passed to it: aliasing, if there
is any, can only be in function call parameters.  Of course, the
aliasing may be in parameters to different functions.

Aliasing introduced *within* the library, if any, is the fault and
concern of the library developer.


Typically most libraries *are* compiled pessimistically unless they
are deliberately intended for high performance use ... math, image
processing, etc. ... and in that case there will be all kinds of
documented restrictions on how to use the library functions correctly.

If a pessimistic canned library is a critical path for a program, then
performance may suffer and there is little the programmer can do about
it [other than find another library].  But use of canned libraries
doesn't affect better optimization of the rest of the program.


In general, it's a mistake to compile a library for distribution using
very high optimization settings.  It makes the library brittle and
hard to use correctly.  It is acceptable for applications that require
maximum performance, but most applications do not fall under that
classification.  In general, it is more important that a library be
defensive with its input and/or tolerant of user mistakes than it is
to provide high performance.

[Remember that in the real world outside of C.A.E, the average skill
level of a software developer is only slight above novice.  I've
mentioned occasionally that I believe a lot of so-called "developers"
would be doing the world a favor by finding other employment.]

YMMV,
George