On 11/16/2021 9:47 AM, Arne Vajhøj wrote:
> On 11/16/2021 7:15 AM, Bill Gunshannon wrote:
>> On 11/15/21 9:23 PM, Arne Vajhøj wrote:
>>> On 11/15/2021 8:44 PM, Bill Gunshannon wrote:
>>>> On 11/15/21 7:35 PM, Arne Vajhøj wrote:
>>>>> On 11/15/2021 6:28 PM, Bill Gunshannon wrote:
>>>>>> On 11/15/21 4:18 PM, Robert A. Brooks wrote:
>>>>>>> ACME_SERVER and SECURITY_SERVER are written in ADA.
>>>>>>>
>>>>>>> Both are being rewritten in C.
>>>>>>
>>>>>> Were there ever any internal benchmarks run against them so that
>>>>>> a comparison of performance when the C conversion is done could
>>>>>> be looked at?
>>>>>
>>>>> Depending on how many checks were disabled in the Ada version, then
>>>>> the C version may be a little or a lot faster,
>>>>>
>>>>> But I cannot imagine it having any significance on modern hardware.
>>>>>
>>>>> They did not rewrite in C to save CPU cycles but because they did
>>>>> not have an Ada compiler for the new platform.
>>>>
>>>> I realize all that. I would just like to see some comparisons.
>>>> I don't know that any were actually done. It all goes back to
>>>> a comment I got from someone from the Ada Users Group about 30
>>>> years ago. I mentioned an interest in a version of Unix rewritten
>>>> in Ada and was quickly informed that while it could be done it
>>>> would result in a useless operating system because the Ada version
>>>> would be very inefficient. Needless to say, I never tried it.
>>>> Might be fun to dig up some benchmarks and try it, but I always
>>>> prefer real world examples to contrived benchmarks.
>>>
>>> But there are two very different questions here.
>>>
>>> Would Ada vs C for OS mean something 30 years ago (VAX 6000 and 3000)?
>>>
>>> Would Ada vs C for OS mean something today (16/24/32 core x86-64)?
>>
>> Thus the reason we have so much bloatware today. If the program
>> runs badly, throw more cores at it. I am not interested in whether
>> or not something ran faster or slower on todays machines vs. yesterdays.
>> I am interested in whether or not ADD A TO B GIVING C is faster, slower
>> or the same between Ada and C.( and other languages as well!) Throwing
>> more cores at the above will not result in faster performance.
>>
>> When I first started with programming we cared about programming and
>> efficiency. We profiled our programs in order to find the bad parts
>> and we fixed them. It is sad that efficiency is no longer considered
>> important to software development today. And they call it engineering
>> while we just called it programming.
>
> I would say that there is a lot of focus on efficiency today.
>
> But there are two types of such focus.
>
> There is the hacker/nerd crowd that focus on micro-benchmarks
> of all sorts of things. ADD A TO B GIVING C will fit fine in
> that.
>
> And then there is the engineering/professional crowd that
> focus on actual solution/system performance. But what measurement
> in this area prove to be relevant has changed over the last 30 years.
> Unless one is in a specialized area like HPC then ADD A TO B GIVING C
> is not relevant for solution/system performance today. They are
> looking for round trips between tiers, interpreted vs compiled,
> data models etc..

Lipstick on a pig, huh ???

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/16/2021 10:08 AM, Dave Froble wrote:
> On 11/16/2021 9:47 AM, Arne Vajhøj wrote:
>> I would say that there is a lot of focus on efficiency today.
>>
>> But there are two types of such focus.
>>
>> There is the hacker/nerd crowd that focus on micro-benchmarks
>> of all sorts of things. ADD A TO B GIVING C will fit fine in
>> that.
>>
>> And then there is the engineering/professional crowd that
>> focus on actual solution/system performance. But what measurement
>> in this area prove to be relevant has changed over the last 30 years.
>> Unless one is in a specialized area like HPC then ADD A TO B GIVING C
>> is not relevant for solution/system performance today. They are
>> looking for round trips between tiers, interpreted vs compiled,
>> data models etc..
>
> Lipstick on a pig, huh ???

Not sure what you mean.

There are lots of performance disasters.

But typical it is the high level design that is wrong not
the low level code.

Example 1: a system where reports was painful slow - turned out that the
report made 6000 database queries to get the data for the report.

Example 2: a web page was painful slow - turned out that the
client side JavaScript fetched data using 2000 AJAX requests.

Arne

On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/15/2021 1:34 PM, Simon Clubley wrote:
>> On 2021-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> But Ada did fall out of fashion.
>>>
>>> There are probably many explanations for that, but my guess
>>> is that the complexity of the language turned out to be a
>>> problem.
>>
>> There's also the problem that the Ada compiler situation overall is not
>> good and that Adacore's Community Edition version of GNAT is pure GPL
>> with no runtime exception. See https://www.adacore.com/community for
>> details.
>
> I know about that restriction. It has been discussed before.
>
> If they really wanted it then they would pay ACT for the commercial edition.
>

Unfortunately, that's still an issue when you don't have that problem
with other languages such as C and C++.

People might want to explore other languages (including Ada) but there
are plenty of production-quality free language compilers available today.

Adacore's policy is a barrier to attracting those types of people.

> > There's still the FSF distribution of GNAT (at least for the targets
> > it supports) however.
>
> Unfortunately then most GCC dists does not include gnat.
>
> Supposedly m2 is going to be in standard GCC dist going forward,
> so maybe Modula-2 instead of Ada??
>

Interesting. I didn't know that, thanks. I wonder if uppercase
keywords will be an optional feature instead of being mandatory ?

I wonder if you will be able to do bare metal coding with it ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/15/2021 1:51 PM, Simon Clubley wrote:
>> On 2021-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/14/2021 5:05 PM, Simon Clubley wrote:
>>>> On 2021-11-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> One really doesn't need a language or compiler to get in the way of what needs
>>>>> to be done.
>>>>
>>>> There is a move towards more safe languages for systems programming.
>>>>
>>>> The current fashion, Rust, has horrible syntax, and I have no confidence
>>>> that code written in it today will still compile on the Rust compilers
>>>> of 5 to 10 years from now, but its use is being driven by the desire
>>>> for using safer languages.
>>>>
>>>> When Rust falls out of fashion, it would be nice if whatever follows
>>>> Rust would address both of those problems.
>>>
>>> Rust seems to be getting some traction.
>>>
>>
>> Unfortunately so. I like the concepts and desire to move to safer
>> languages but I find the Rust syntax itself ugly. People seem to
>> have forgotten that you write the code once (hopefully!) but then
>> read it many times.
>
> What do you think about Go?
>

It doesn't seem to be a language designed for writing bare metal code
or operating systems in general so I have not really used it.

On a non-technical level, given how Google treats its projects, I would
also worry that suddenly one day Go would no longer be supported by Google.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/16/21 1:43 PM, Simon Clubley wrote:
> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/15/2021 1:34 PM, Simon Clubley wrote:
>>> On 2021-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> But Ada did fall out of fashion.
>>>>
>>>> There are probably many explanations for that, but my guess
>>>> is that the complexity of the language turned out to be a
>>>> problem.
>>>
>>> There's also the problem that the Ada compiler situation overall is not
>>> good and that Adacore's Community Edition version of GNAT is pure GPL
>>> with no runtime exception. See https://www.adacore.com/community for
>>> details.
>>
>> I know about that restriction. It has been discussed before.
>>
>> If they really wanted it then they would pay ACT for the commercial edition.
>>
>
> Unfortunately, that's still an issue when you don't have that problem
> with other languages such as C and C++.
>
> People might want to explore other languages (including Ada) but there
> are plenty of production-quality free language compilers available today.
>
> Adacore's policy is a barrier to attracting those types of people.
>
>>> There's still the FSF distribution of GNAT (at least for the targets
>>> it supports) however.
>>
>> Unfortunately then most GCC dists does not include gnat.
>>
>> Supposedly m2 is going to be in standard GCC dist going forward,
>> so maybe Modula-2 instead of Ada??
>>
>
> Interesting. I didn't know that, thanks. I wonder if uppercase
> keywords will be an optional feature instead of being mandatory ?
>
> I wonder if you will be able to do bare metal coding with it ?
>

It would seem to me that bare metal coding isn't a compiler thing,
it's a library thing. Create the necessary libraries for your bare
metal and have at it.

bill

On 2021-11-15, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> I realize all that. I would just like to see some comparisons.
> I don't know that any were actually done. It all goes back to
> a comment I got from someone from the Ada Users Group about 30
> years ago. I mentioned an interest in a version of Unix rewritten
> in Ada and was quickly informed that while it could be done it
> would result in a useless operating system because the Ada version
> would be very inefficient. Needless to say, I never tried it.
> Might be fun to dig up some benchmarks and try it, but I always
> prefer real world examples to contrived benchmarks.
>

I think that person was talking (mostly) nonsense.

For example, the original version of RTEMS was written in Ada before
it was ported to C (IIRC, because C was more common in the open source
world and supported more architectures).

Also, look at the sheer amount of boundary checks and descriptor decoding
that VMS does in its APIs. (For example).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/16/2021 1:43 PM, Simon Clubley wrote:
> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/15/2021 1:34 PM, Simon Clubley wrote:
>>> On 2021-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> But Ada did fall out of fashion.
>>>>
>>>> There are probably many explanations for that, but my guess
>>>> is that the complexity of the language turned out to be a
>>>> problem.
>>>
>>> There's also the problem that the Ada compiler situation overall is not
>>> good and that Adacore's Community Edition version of GNAT is pure GPL
>>> with no runtime exception. See https://www.adacore.com/community for
>>> details.
>>
>> I know about that restriction. It has been discussed before.
>>
>> If they really wanted it then they would pay ACT for the commercial edition.
>
> Unfortunately, that's still an issue when you don't have that problem
> with other languages such as C and C++.
>
> People might want to explore other languages (including Ada) but there
> are plenty of production-quality free language compilers available today.
>
> Adacore's policy is a barrier to attracting those types of people.

Maybe.

But for very serious use then paying should not be a problem.

And for just trying it out then GPL should not be a problem.

GPL being unacceptable and not willing to pay is a group in between.

>>> There's still the FSF distribution of GNAT (at least for the targets
>>> it supports) however.
>>
>> Unfortunately then most GCC dists does not include gnat.
>>
>> Supposedly m2 is going to be in standard GCC dist going forward,
>> so maybe Modula-2 instead of Ada??
>
> Interesting. I didn't know that, thanks.

https://www.phoronix.com/scan.php?page=news_item&px=Modula-2-GCC-Mainline-Hope-2021

> I wonder if uppercase
> keywords will be an optional feature instead of being mandatory ?

I doubt it.

> I wonder if you will be able to do bare metal coding with it ?

No idea.

Arne

On 2021-11-16, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> It would seem to me that bare metal coding isn't a compiler thing,
> it's a library thing. Create the necessary libraries for your bare
> metal and have at it.
>

For one simple example, can you turn off garbage collection in a
language when running in bare metal mode ? (Go is a GC language)

How much of the language do you lose if you can do that ?

Go is also reported not to support low-level features such as
pointer arithmetric.

There's also the fact that at the very lowest levels, you need to
be able to write code that does not need a runtime because there
isn't an operating system under that code to support that runtime.
It wasn't clear to me if you can actually do that with Go.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/16/2021 1:54 PM, Simon Clubley wrote:
> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/15/2021 1:51 PM, Simon Clubley wrote:
>>> On 2021-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/14/2021 5:05 PM, Simon Clubley wrote:
>>>>> On 2021-11-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> One really doesn't need a language or compiler to get in the way of what needs
>>>>>> to be done.
>>>>>
>>>>> There is a move towards more safe languages for systems programming.
>>>>>
>>>>> The current fashion, Rust, has horrible syntax, and I have no confidence
>>>>> that code written in it today will still compile on the Rust compilers
>>>>> of 5 to 10 years from now, but its use is being driven by the desire
>>>>> for using safer languages.
>>>>>
>>>>> When Rust falls out of fashion, it would be nice if whatever follows
>>>>> Rust would address both of those problems.
>>>>
>>>> Rust seems to be getting some traction.
>>>>
>>>
>>> Unfortunately so. I like the concepts and desire to move to safer
>>> languages but I find the Rust syntax itself ugly. People seem to
>>> have forgotten that you write the code once (hopefully!) but then
>>> read it many times.
>>
>> What do you think about Go?
>
> It doesn't seem to be a language designed for writing bare metal code
> or operating systems in general so I have not really used it.

It was designed for servers.

But people are using it for small stuff.

Examples:

https://tinygo.org/

https://golangexample.com/a-go-unikernel-running-on-x86-bare-metal/

> On a non-technical level, given how Google treats its projects, I would
> also worry that suddenly one day Go would no longer be supported by Google.

Not likely. It has gotten so much traction that it would
be very difficult to stop it.

Docker, Kubernetes and OpenShift are all written in Go. In 5 years then
75% of the worlds server computing will be run in Kubernetes clusters.

Amazon, Microsoft, Google themselves, IBM/Redhat, VMWare etc. all
need that stuff.

Arne

On 11/16/2021 2:19 PM, Simon Clubley wrote:
> On 2021-11-16, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> It would seem to me that bare metal coding isn't a compiler thing,
>> it's a library thing. Create the necessary libraries for your bare
>> metal and have at it.
>
> For one simple example, can you turn off garbage collection in a
> language when running in bare metal mode ? (Go is a GC language)
>
> How much of the language do you lose if you can do that ?

Bare metal and GC is not a problem.

Hard real time and GC is a problem.

But if your bare metal is also hard real time, then ...

It was not what Go was designed for.

But there are options available.

You can disable automatic and call GC when you want to.

There are external libraries available like:

https://github.com/teh-cmc/mmm

> Go is also reported not to support low-level features such as
> pointer arithmetric.

They strongly recommends against doing it.

But there is an unsafe package if you want to shoot yourself in the
foot.

> There's also the fact that at the very lowest levels, you need to
> be able to write code that does not need a runtime because there
> isn't an operating system under that code to support that runtime.
> It wasn't clear to me if you can actually do that with Go.

It is not designed for that.

But see one of the links I sent in the other post.

It looks doable.

Recommended? Questionable!

Arne

On 2021-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> https://tinygo.org/
>
> https://golangexample.com/a-go-unikernel-running-on-x86-bare-metal/
>

Interesting thanks.

I've just done a bit of reading about Go to refresh my memory and I
discovered this once again:

https://stackoverflow.com/questions/17153838/why-does-golang-enforce-curly-bracket-to-not-be-on-the-next-line

Go is the only language I know of that forces this style.

Great if you like this brace style, not so great otherwise... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/16/2021 2:33 PM, Simon Clubley wrote:
> On 2021-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> https://tinygo.org/
>>
>> https://golangexample.com/a-go-unikernel-running-on-x86-bare-metal/
>
> Interesting thanks.
>
> I've just done a bit of reading about Go to refresh my memory

You can pick and chose among lots of languages if you are looking
for high level languages for business applications.

But for low level stuff the choices are way more limited. If you want
something newer than C/C++ with some industry support and you do
not like Rust then Go becomes pretty obvious.

Alternatively you could learn to love Rust.

Arne

On 11/16/2021 7:15 AM, Bill Gunshannon wrote:
> I am interested in whether or not ADD A TO B GIVING C is faster, slower
> or the same between Ada and C.( and other languages as well!)

For some random synthetic micro-benchmark:

Language Compiler/Runtime Integer performance Floating point
performance String performance Total performance
C GCC 11.1 -O3 64 bit 1670 239 23.31 210.32
C MSVC++ VS19 /O2 64 bit 1055 239 13.76 151.39
C LLVM 12.0 -O3 64 bit 557 239 19.54 137.53
Java SUN 17.0 Server 64 bit 548 209 13.50 115.63
Java SUN 11.0 Server 64 bit 473 209 13.19 109.25
C# .NET 5.0 64 bit 668 209 8.22 104.70
Java SUN 1.8.0 Server 64 bit 473 209 9.25 97.06
C# .NET 4.0 /o+ 64 bit 556 185 8.01 93.75
Java SUN 11.0 Graal 64 bit 417 185 10.67 93.72
C# .NET 4.0 64 bit 555 185 7.91 93.30
Ada Gnat 2017 -gnatp -O3 64 bit 554 238 5.74 91.13
Ada Gnat 2017 -O3 64 bit 505 238 5.73 88.31
C MSVC++ VS19 64 bit 371 134 12.70 85.79
C GCC 11.1 64 bit 278 139 16.31 85.74
Ada Gnat 2017 -gnatp 64 bit 276 138 5.44 59.17
Python PyPy 7.3 (Python 3.7) 64 bit 401 207 2.31 57.66
Pascal FPC 3.2 -O4 64 bit 417 186 2.41 57.18
Ada Gnat 2017 64 bit 256 138 5.10 56.48
C LLVM 12.0 64 bit 103 134 12.35 55.45
Pascal FPC 3.2 64 bit 278 145 2.40 45.91
PHP PHP 7.4 GCC 64 bit 22 34 0.67 7.91
PHP PHP 7.4 MSVC++ 64 bit 9 13 1.39 5.37
Python CPython 3.6 GCC 64 bit 6 8 0.76 3.30
Python CPython 3.6 MSVC++ 64 bit 5 5 0.44 2.22

Note that this micro-benchmark is not likely to match any real-world
workload.

More results and source code available at:

  https://www.vajhoej.dk/arne/articles/perf.html

Arne

On 2021-11-15 21:18:13 +0000, Robert A. Brooks said:

> ACME_SERVER and SECURITY_SERVER are written in ADA.
>
> Both are being rewritten in C.

A rewrite into C which was overdue, too.

Ada and PL/I both sharing the distinction of removal.

It'll be interesting to see what happens here with C code longer term
too, given better access to ASan and other Clang tools.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-11-16 14:47:33 +0000, Arne Vajhj said:

> On 11/16/2021 7:15 AM, Bill Gunshannon wrote:
>>
>> Thus the reason we have so much bloatware today.  If the program runs
>> badly, throw more cores at it.

Can't say I see much wrong with more cores and more resources, and with
big.LITTLE and other heterogenous processor designs.

>> When I first started with programming we cared about programming and
>> efficiency. 

Because you had constraints that required that; very limited and slow hardware.

>> We profiled our programs in order to find the bad parts and we fixed them. 

That still happens. But again, you had limited and slow hardware, and
comparatively weak tooling, and you had to look at adds and multiplies.
Now, not so much.

>> It is sad that efficiency is no longer considered important to software
>> development today. 

A full VAX-11/780 server configuration cost around a hundred thousand
dollars US, back in the mid 1980s. That's closer to a quarter-million
2021 dollars. Which buys a lot of computer.

A full Mac mini M1 costs a ~hundredth of that 1980s price, is massively
faster, and massively more capable. And is dwarfed by the massive size
of the LSI-11 console, and might well consume less power than did the
RX01 console floppy.

Do I need to optimize adds and multiplies on an M1? Probably not. And
if I do, I'm probably looking at using SIMD or such via the Accelerate
framework.

Does Accelerate or other frameworks add bloat? Absolutely. But
hopefully it avoids costs and hassles when porting hardware, and the
costs adjusting existing code when newer hardware becomes available.

https://developer.apple.com/documentation/accelerate

>> And they call it engineering while we just called it programming.

Economics, mostly. Hardware has gotten cheaper faster than programmer
investments have gotten cheaper.

Folks in the 1980s grumbled about changes in computing economics and
tooling, too. Tooling that many didn't understand and didn't want to
learn about. There were massive squabbles about 2GL and 3GL back then;
about assembler and the shift to compiled languages. Adding bloat, as
was widely reported back then.

I had more than a few discussions decades ago with a very experienced
and skilled developer that was then just having to mentally shift away
from punched card app designs and limits, and was aghast at an app
having a five thousand longword array. That overnight run for that
add-heavy app went from ~overnight to ~ten minutes, given new hardware
and new software. I didn't bother to profile the add and the multiply
times for that app.

> I would say that there is a lot of focus on efficiency today.
>
> But there are two types of such focus.
>
> There is the hacker/nerd crowd that focus on micro-benchmarks of all
> sorts of things. ADD A TO B GIVING C will fit fine in that.

That instruction-level focus was wicked popular back in the VAX era,
too. Various instruction-timing tables were published. Folks optimized
individual instructions. There were folks that implemented instructions
(e.g. XFC) to get microcode speeds, too. Optimization work which mostly
vaporized when DEC released a new VAX CPU design with different
timings. And with no XFC.

If doing billions or trillions of adds as the core of the app, folks
are interested in the performance of adds and multiplies. Otherwise,
not so much.

Even back in the VAX era, folks were still throwing hardware at this
problem, too. Back then, with the FP780 floating point accelerator. The
FP780 speeded both floating point, as well as integer multiply. Or
corrupted floating point and integer multiply, if the FP780 was
recalcitrant.

For those interested in these sorts of benchmarking and performance
problems and the closely-related "instruction bumming" challenges, have
a look around for "code golf", among other discussions.

There's a performance variation awaiting here too, with algorithms now
ill-performing for the scale of the current data. I've seen these cases
arise in more than a few existing OpenVMS apps.

> And then there is the engineering/professional crowd that focus on
> actual solution/system performance. But what measurement in this area
> prove to be relevant has changed over the last 30 years. Unless one is
> in a specialized area like HPC then ADD A TO B GIVING C is not relevant
> for solution/system performance today. They are looking for round trips
> between tiers, interpreted vs compiled, data models etc..

Absent a program executing billions or trillions of adds or multiplies,
~nobody cares about the speed of an individual add or multiply across
differing programming languages. Other cost factors are involved.

And for apps that are executing billions or trillions of adds or
multiplies, we're now looking at migrating out of iterative code and
into SIMD / AVX / Accelerate where feasible, or migrating the math
entirely off the (traditional) CPU.

For many years now, other app activities have utterly overwhelmed the
speed of integer math for most apps. DEC learned about that when the
VAX market drifted out of scientific and HPC apps, and drifted into
commercial apps. For hardware performance, Apple M1 Max will reportedly
run ~ten teraflops, give or take. And last-millennium HDD storage I/O
is glacial, as compared with NVMe and newer I/O. And in practical 2021
terms, VAX had ~-no storage and ~no memory, even the few VAX models
with extended physical addressing.

And economically, ill-chosen algorithms, and API compatibility, and of
under-maintained and un-refactored existing app code, and abstraction
layers and the rest of "bloat" will continue, as will the hardware
upgrades. Because the stuff involved still has to sell at a profit, or
management has to cover the costs of the app work from profits and
salaries. Trade-offs can and do and will shift, too. As will
gatekeeping.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/15/21 6:35 PM, Arne Vajhøj wrote:
> On 11/15/2021 6:28 PM, Bill Gunshannon wrote:
>> On 11/15/21 4:18 PM, Robert A. Brooks wrote:
>>> On 11/15/2021 4:01 PM, Bill Gunshannon wrote:
>>>> This talk of Ada, VMS and Systems programming has raised a new
>>>> question in my mind.
>>>>
>>>> Given that Ada got it's start on VMS (one of the first validated
>>>> Ada Compilers was on VMS) has any attempt ever been made to write
>>>> any part of VMS using Ada?  Device Driver? Anything?
>>>
>>> ACME_SERVER and SECURITY_SERVER are written in ADA.
>>>
>>> Both are being rewritten in C.
>>
>> Were there ever any internal benchmarks run against them so that
>> a comparison of performance when the C conversion is done could
>> be looked at?
>
> Depending on how many checks were disabled in the Ada version, then
> the C version may be a little or a lot faster,
>
> But I cannot imagine it having any significance on modern hardware.
>
> They did not rewrite in C to save CPU cycles but because they did
> not have an Ada compiler for the new platform.

Right, but that doesn't mean the performance of the Ada version is good
or that bad performance doesn't matter. In fact, ACME server performance
is pretty lousy. SET SERVER ACME/RESTART takes 36 seconds on an rx2660.
That's 36 seconds of downtime during which no one can log in to the
system, which might not matter much in some environments, but is still a
very long time to restart a service.

On 11/19/2021 8:08 AM, Craig A. Berry wrote:
>
> On 11/15/21 6:35 PM, Arne Vajhøj wrote:
>> On 11/15/2021 6:28 PM, Bill Gunshannon wrote:
>>> On 11/15/21 4:18 PM, Robert A. Brooks wrote:
>>>> On 11/15/2021 4:01 PM, Bill Gunshannon wrote:
>>>>> This talk of Ada, VMS and Systems programming has raised a new
>>>>> question in my mind.
>>>>>
>>>>> Given that Ada got it's start on VMS (one of the first validated
>>>>> Ada Compilers was on VMS) has any attempt ever been made to write
>>>>> any part of VMS using Ada?  Device Driver? Anything?
>>>>
>>>> ACME_SERVER and SECURITY_SERVER are written in ADA.
>>>>
>>>> Both are being rewritten in C.
>>>
>>> Were there ever any internal benchmarks run against them so that
>>> a comparison of performance when the C conversion is done could
>>> be looked at?
>>
>> Depending on how many checks were disabled in the Ada version, then
>> the C version may be a little or a lot faster,
>>
>> But I cannot imagine it having any significance on modern hardware.
>>
>> They did not rewrite in C to save CPU cycles but because they did
>> not have an Ada compiler for the new platform.
>
> Right, but that doesn't mean the performance of the Ada version is good
> or that bad performance doesn't matter. In fact, ACME server performance
> is pretty lousy.  SET SERVER ACME/RESTART takes 36 seconds on an rx2660.
>  That's 36 seconds of downtime during which no one can log in to the
> system, which might not matter much in some environments, but is still a
> very long time to restart a service.

It is.

So if we say that the right time is 1 second, then those extra
35 seconds - what are they used on?

Doing Ada runtime checks??

I doubt it.

I suspect there are some bad logic that need to be redesigned.

Arne

On 11/19/21 8:38 AM, Arne Vajhøj wrote:
> On 11/19/2021 8:08 AM, Craig A. Berry wrote:
>>
>> On 11/15/21 6:35 PM, Arne Vajhøj wrote:
>>> On 11/15/2021 6:28 PM, Bill Gunshannon wrote:
>>>> On 11/15/21 4:18 PM, Robert A. Brooks wrote:
>>>>> On 11/15/2021 4:01 PM, Bill Gunshannon wrote:
>>>>>> This talk of Ada, VMS and Systems programming has raised a new
>>>>>> question in my mind.
>>>>>>
>>>>>> Given that Ada got it's start on VMS (one of the first validated
>>>>>> Ada Compilers was on VMS) has any attempt ever been made to write
>>>>>> any part of VMS using Ada?  Device Driver? Anything?
>>>>>
>>>>> ACME_SERVER and SECURITY_SERVER are written in ADA.
>>>>>
>>>>> Both are being rewritten in C.
>>>>
>>>> Were there ever any internal benchmarks run against them so that
>>>> a comparison of performance when the C conversion is done could
>>>> be looked at?
>>>
>>> Depending on how many checks were disabled in the Ada version, then
>>> the C version may be a little or a lot faster,
>>>
>>> But I cannot imagine it having any significance on modern hardware.
>>>
>>> They did not rewrite in C to save CPU cycles but because they did
>>> not have an Ada compiler for the new platform.
>>
>> Right, but that doesn't mean the performance of the Ada version is good
>> or that bad performance doesn't matter. In fact, ACME server performance
>> is pretty lousy.  SET SERVER ACME/RESTART takes 36 seconds on an rx2660.
>>   That's 36 seconds of downtime during which no one can log in to the
>> system, which might not matter much in some environments, but is still a
>> very long time to restart a service.
>
> It is.
>
> So if we say that the right time is 1 second, then those extra
> 35 seconds - what are they used on?
>
> Doing Ada runtime checks??
>
> I doubt it.
>
> I suspect there are some bad logic that need to be redesigned.

Abysmal performance of a service written in Ada may or may not have
anything to do with Ada directly or indirectly. Or it may. ACME has no
reason to do a large quantity of network I/O or disk I/O, so it has no
reason to be considered a victim of the slow network stack or the slow
disk/filesystem infrastructure endemic to VMS. So the only thing I know
is that the slowest service I've ever seen on VMS in a few decades is
that this particular service is (uncharacteristically) written in Ada,
so Ada is suspect. I do not have the time, interest, or access to the
code that would be required to prove the actual performance bottleneck.

On 11/16/2021 2:22 PM, Arne Vajhøj wrote:
> On 11/16/2021 1:54 PM, Simon Clubley wrote:
>> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> What do you think about Go?
>>
>> It doesn't seem to be a language designed for writing bare metal code
>> or operating systems in general so I have not really used it.
>
> It was designed for servers.
>
> But people are using it for small stuff.

https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/

Arne

On 2022-05-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/16/2021 2:22 PM, Arne Vajhøj wrote:
>> On 11/16/2021 1:54 PM, Simon Clubley wrote:
>>> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> What do you think about Go?
>>>
>>> It doesn't seem to be a language designed for writing bare metal code
>>> or operating systems in general so I have not really used it.
>>
>> It was designed for servers.
>>
>> But people are using it for small stuff.
>
> https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
>
> Arne
>

From that article:

|However, we want to stress that Go cannot be considered a replacement for C
|as there are many places where C is and likely will be needed, such as in
|the development of real time operating systems or device drivers.

That kills even considering Go for most embedded systems.

It sounds to me like they are writing normal applications that are
running under Linux, but just on embedded hardware.

Let me know when they are using Go to, for example, directly fly UAVs
and directly control the UAV hardware (and where Go isn't just been
used as a shim on top of C code that does the actual real-time work).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/13/2022 8:39 AM, Simon Clubley wrote:
> On 2022-05-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/16/2021 2:22 PM, Arne Vajhøj wrote:
>>> On 11/16/2021 1:54 PM, Simon Clubley wrote:
>>>> On 2021-11-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> What do you think about Go?
>>>>
>>>> It doesn't seem to be a language designed for writing bare metal code
>>>> or operating systems in general so I have not really used it.
>>>
>>> It was designed for servers.
>>>
>>> But people are using it for small stuff.
>>
>> https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
>
> From that article:
>
> |However, we want to stress that Go cannot be considered a replacement for C
> |as there are many places where C is and likely will be needed, such as in
> |the development of real time operating systems or device drivers.
>
> That kills even considering Go for most embedded systems.
>
> It sounds to me like they are writing normal applications that are
> running under Linux, but just on embedded hardware.
>
> Let me know when they are using Go to, for example, directly fly UAVs
> and directly control the UAV hardware (and where Go isn't just been
> used as a shim on top of C code that does the actual real-time work).

You are not an easy customer to sell a programming language to.

:-)

Rust and Go is what is new with some serious momentum/backing.

If you are willing to go for more exotic options, then maybe
Hare will fit your requirements.

Arne

On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/13/2022 8:39 AM, Simon Clubley wrote:
>> On 2022-05-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
>>
>> From that article:
>>
>> |However, we want to stress that Go cannot be considered a replacement for C
>> |as there are many places where C is and likely will be needed, such as in
>> |the development of real time operating systems or device drivers.
>>
>> That kills even considering Go for most embedded systems.
>>
>> It sounds to me like they are writing normal applications that are
>> running under Linux, but just on embedded hardware.
>>
>> Let me know when they are using Go to, for example, directly fly UAVs
>> and directly control the UAV hardware (and where Go isn't just been
>> used as a shim on top of C code that does the actual real-time work).
>
> You are not an easy customer to sell a programming language to.
>
>:-)
>

:-)

That's because I know exactly what I want from a programming language
and these days, it seems like most of the time you are using the
least-worst option or the most viable option instead of the best option.
(Most viable option does not mean _best_ option BTW).

> Rust and Go is what is new with some serious momentum/backing.
>
> If you are willing to go for more exotic options, then maybe
> Hare will fit your requirements.
>

Interesting. I wasn't aware of that one.

No 32-bit ARM support however (or 32-bit support in general).

It does appear to have some package/module based support.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-16 18:02:20 +0000, Simon Clubley said:

> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>
>> Rust and Go is what is new with some serious momentum/backing.
>>
>> If you are willing to go for more exotic options, then maybe Hare will
>> fit your requirements.
>>
>
> Interesting. I wasn't aware of that one.
>
> No 32-bit ARM support however (or 32-bit support in general).

Zig has (some) support for ARMv7a, and ties into C quite well.

ARMv7a support and x86-32 support is available in the most recent 0.9.1
version, though is not presently available in Master.

For porting, Zig is self-hosting, though LLVM support was around as an
option when last I checked.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/16/22 14:02, Simon Clubley wrote:
> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/13/2022 8:39 AM, Simon Clubley wrote:
>>> On 2022-05-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
>>>
>>> From that article:
>>>
>>> |However, we want to stress that Go cannot be considered a replacement for C
>>> |as there are many places where C is and likely will be needed, such as in
>>> |the development of real time operating systems or device drivers.
>>>
>>> That kills even considering Go for most embedded systems.
>>>
>>> It sounds to me like they are writing normal applications that are
>>> running under Linux, but just on embedded hardware.
>>>
>>> Let me know when they are using Go to, for example, directly fly UAVs
>>> and directly control the UAV hardware (and where Go isn't just been
>>> used as a shim on top of C code that does the actual real-time work).
>>
>> You are not an easy customer to sell a programming language to.
>>
>> :-)
>>
>
> :-)
>
> That's because I know exactly what I want from a programming language
> and these days, it seems like most of the time you are using the
> least-worst option or the most viable option instead of the best option.
> (Most viable option does not mean _best_ option BTW).
>
>> Rust and Go is what is new with some serious momentum/backing.
>>
>> If you are willing to go for more exotic options, then maybe
>> Hare will fit your requirements.
>>
>
> Interesting. I wasn't aware of that one.
>
> No 32-bit ARM support however (or 32-bit support in general).
>
> It does appear to have some package/module based support.
>

Just what the industry needs. A few more ego languages.

bill

On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
> On 5/16/22 14:02, Simon Clubley wrote:
>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Rust and Go is what is new with some serious momentum/backing.
>>>
>>> If you are willing to go for more exotic options, then maybe
>>> Hare will fit your requirements.
>>
>> Interesting. I wasn't aware of that one.
>>
>> No 32-bit ARM support however (or 32-bit support in general).
>>
>> It does appear to have some package/module based support.
>
> Just what the industry needs.  A few more ego languages.

Programming languages is very much a matter of evolution.

New languages show up all the time. Those that are good replace
older languages. Those that are not good dies.

What if Wirth and K&R had decided in the late 60's that
Fortran, Cobol and PL/I had everything so no need for
any "ego languages".

Arne