Maybe we should just stop using software until someone figures it out? How about if we make all computers analog? Yeah, that has got to work better, right? The digital stuff is boring and easy, even if no one seems to be able to do it right. I guess the whole world is just stupid...
As I said, I don't really know Ada, so I defer to your knowledge.
Again, I don't have first hand knowledge of compiler efficiency, but I have discussed this with others who do and they tell me compilers are every bit as good as hand coded assembly most of the time. That is no surprise to me as this is a problem that has been worked on for a long time. So forgive me if I don't defer to your opinion on this one.
Do you have any examples?
Closed mouth? When it went public? Was this in the early 70's? Fig forth was freely available in the 70's. Who was closed mouth about it? I remember attending a conference on Forth early in my career, about
1982 or '83. Hardly closed mouth then. What Forth did you find that the "inner interpreter" wasn't done in assembly? These days commercial Forths are compilers with no interpretation for compiled code. Speed is great with good support and documentation if not actual source. You've missed a lot.I'm currently using a Forth that runs on the target processor of a TI Stellaris Cortex M3 MCU, not even a high end one.
On Thu, 02 Jul 2015 17:54:35 -0700, John Larkin Gave us:
John Larkin in rare form tonight... NOPE, this *stupid* s*it behavior from him is his *norm*.
He blathers on about civil behavior ALL THE TIME.
How much you wanna bet that he completely ignored my tale about when I saved a part at a company I once worked for?
It was in response to his "I caught a hot iron once." remark, and I didn't cuss even once.
From John... crickets.
Only so long as Cobol programmers are in short supply. These things run in cycles.
The problem is in maintaining code which is critical to the banks core clearing operations (as opposed to the snazzy trader floor stuff).
They don't spend much on the legacy systems and they do tend to have spectacular MFUs from time to time. Some banks more than others.
If you want to sell your soul for maximum financial gain then destabilising the global stock trading systems with sophisticated high frequency trading algorithms is definitely the way to go.
One guy in the UK in his parents bedroom can allegedly do this:
People seem to get upset if you are too good at it!
I don't often defend Johns comments but on this he does have a point. For most home and office kit these days the CPU power available is so huge that efficiency literally does not matter in end user code.
The notable exceptions are video editing and 3D gaming which really do push the performance envelope. Word processing and general stuff you can trade a few percent of speed for safety without any problems.
Fast CPUs are cheap and getting cheaper in line with Moore's law whereas good software engineers are rare, expensive and getting more so.
TBH I am amazed that Moore's law has held good for as long as it has.
To be fair here, there are very few* operating systems written in COBOL. It was developed to solve other types of real problems.
I would compare it more to SNOBOL or PL/1.
He has a part of a point, but at the time that C was taking off big time most machines were pretty short of resources and C was a distinct improvement over its predecessors like B and BCPL.
They are not all cowboys. MacConnell's Code Complete published by Microsoft is quite a good introduction to defensive programming. It is just a shame that they don't always practice what they preach.
The problem stems from their sheer complexity and the fact that the customer tends not to really know what they want at the outset.
They do care. Academia dumps their rejects into the software industry.
I am somewhat annoyed that in the UK our professional body is far too supine about expressing disgust when government software projects go haywire - almost inevitably due to some combination of inadequate specifications, bad management, budget overrun and mission creep.
The Royal Society for Chemistry is a heck of a lot better at PR.
Sadly I have to concede that you have a point there.
OS/2 was a lot more robust but IBM made a total mess of selling it!
The problem is that modern management views time to market as the priority to get sales bonuses. It is only software after all and you can sell "support" to the poor suckers or maybe a years free updates.
No-one would dream of doing it for physical hardware with product recalls, messy patch wires and oudles of conformal coating.
There are static analysis tools that can find latent bugs in a codebase without executing it by using dataflow analysis. Looking for any paths through the code where variables are used before first being assigned a value or where a nul pointer could be dereferenced.
Such bugs can lurk for a long time along seldom executed paths (often but not always the error recovery for some critical system failure).
Ada was too big and complicated for it's own good. Modula2 wasn't bad for a minimalist hard realtime language with separate compilation of modules and provision for low level system operations by design.
All the mainframe compilers in that era apart from the most expensive high end FORTRAN had pretty lousy optimisers.
I think that is a somewhat jaundiced view of the situation (although I am not a particular fan of Ada). Algol68 had similar speed complexity tradeoffs in a previous era. Fortran compiler could run rings around it performance wise but for algorithm development it was still very useful.
I think you will have to elaborate on that point. Offhand I can't see anything in the Ada language specification apart from its immense size and the enormous validation suite that forced Ada compilers to be clumsy and emit slow code. I will concede that in the era where C was in the ascendency a great deal more effort was expended on its code optimiser than on any other language apart from Fortran.
I don't disagree that most of the powerful languages started out as someone's pet project that gained momentum locally and then globally.
That isn't true any more with profile directed optimising compilers. The compiler can often beat all but the very best handpicked assembler practitioners. Register colouring, speculative execution and pipeline stalls mean that most people cannot see the wood for the trees now. The compiler (with the right CPU optimising flags set) does it seemlessly.
A surprising number of modern compilers will reduce common loop constructs to almost identical canonical code. Certain constructs are faster on some Intel CPUs than on others so it chooses the right one.
I don't remember it being all that closed mouthed. It was in relatively wide use in the late 1970's for telescope control and I thought the magnetic tapes were circulating fairly freely in that community.
There was even a Forth for the venerable BBC micro in about 1983.
Den fredag den 3. juli 2015 kl. 00.03.35 UTC+2 skrev John Larkin:
up to a point, haven't you been wishing for a faster ltspice? if is was as easy as buying a faster cpu why don't you?
-Lasse
Envision trillion dollar bugs. I suspect it happens all the time, and they just clean up afterwards.
Yeah, a good fraction of MIT grads get sucked up for that.
Terrifying instability.
Den fredag den 3. juli 2015 kl. 12.52.52 UTC+2 skrev Martin Brown:
yeh, you have to be a member of "the money sucking parasite club" to manipulate prices and steal money like that
-Lasse
Maybe ricky runs a lot of 3D EM simulations. Or maybe he games a lot.
I only notice CPU runtime rarely, in Spice sims of oscillators and switchers. Most Spice sims run in zero subjective time. And they are giving me a new PC soon, 5x or so faster than what I have. Most people run Facebook and Twitter and texting, so a small ARM in the corner of a chip is plenty of compute power.
I run ATLC once in a great while, which is compute intensive, but I doubt that I've totaled four hours computing in the last year, and I can always do something else, clean my office maybe, while it's running. Upgrading my PC will take me more time that I might ever get back.
Intel must appreciate that the water-cooled gigaflop desktop biz can't be the future. They just canned a bunch of top management.
So it makes sense to trade runtime efficiency (as in, Python type things) for program quality and security.
The wall isn't too far away. EUV is still in doubt. Maybe the Moore's law feature-size progression will die from lack of demand, rather than lack of supply. If all you need is a hundred million transistors on a chip, there's no economic upside to doing that with 7 nm features and insane mask costs. About the only app that benefits from extreme resolution is memory.
40 years ago.
Amen!
It's impressive that the software industry is able to evade legal liability for the damage they do.
Burroughs wrote their OS and their Algol compilers entirely in Algol. Apparently a couple of guys read the Algol source code of the first compiler and hand-compiled that to machine code, as the bootstrap.
A small tax on transactions, like 0.1%, would have a remarkable damping effect. Maybe we can get that soon, after the next monster worldwide crash.
What I want is a 1000x speed improvement, so I can move sliders and see waveforms change instantly, just like a breadboard with pots and a scope. N-dimensional iteration at 5 minutes per trial is not intuitive, but then 1 minute isn't either.
I did that kilovolt switcher design recently, and it was running 4 minutes per pass, until I removed the leakage inductance and got it down below 1 minute. Still, I got the design done in a few hours. Since I'll breadboard it anyhow, I didn't really need Spice.
My new Dell, due soon, will be maybe 5x faster. Spice will then probably be hard drive limited rather than compute bound. It shows up at about 50% CPU utilization on my old HP.
Spice on a GPU might make sense for some people, with ramdisk for the .raw files, but I don't really need that.
Some FPGA compiles are slow, but again probably hard drive limited. Or bloatware limited.
On Fri, 03 Jul 2015 09:17:48 -0700, John Larkin Gave us:
Did you post the fixed final design?
Yes. Nobody would have used Ada absent the DoD Mandate.
Generally true. My solution was to use a mix of Fortran and assembly-coded fortran-callable subroutines and functions.
I have also used fortran in realtime systems, including to code interrupt routines. This was before fortran developed call stacks, which led to some very interesting bugs when shared routines were fought over.
Not really. I suppose the best example is priority inversion, which I first encountered when I became a embedded realtime programmer in 1974
- it was part of the lore, an entry in the long list of blunders to be avoided, but had neither a name nor a literature. My boss told me about it in 1974 while I was learning the ropes.
The developers of Ada did not even know of that lore, never having built and fielded a non-trivial embedded realtime system, and so fell into this and other traps.
When the Ada gurus figured out why they were getting these devastating random big delays, the named the cause and wrote many learned articles.
A key example is Rendezvous. As mentioned before, I built a middleware in Ada83 (plus some assembly) to replace Rendezvous, for a factor of ten reduction in message-passing latency, and the elimination of forced synchronism.
The basic interface had four APIs: Get empty message (a block of memory from a linked list), send message, receive message, release message for reuse. Message transfer is asynchronous - neither sender nor receiver wait for the other, unless they want to.
The problem with message facilities having only send-message and receive-message APIs is that the operating system and/or the application level code (like the middleware) is forced to copy the message contents time after time. DEC was very proud that the message interfaces in VMS only copied the message text seven times going and another seven times coming, for a total of fourteen times.
Given the amount of data to be sent and received in a radar, and the speed of the computers of the day, copying the message text is simply untenable, by at least two and probably three or four orders of magnitude. Only a shared-memory pass-pointer architectures can work.
Which brings me to the second key example, shared memory. Ada83 simply had no concept of shared memory and especially of multiprocessor systems with global memory, despite wide use in embedded realtime systems of the day.
To build the shared-memory pass-pointer architecture, it was necessary to implement shared memory between different processes on different processors. Ada83 simply could not do this, not even after clever pruning of the language, because the code optimizer did not know and could not be told that there were other entities that could change memory.
The solution was to realize that according to the Ada LRM, the optimizer was required to treat subroutine calls as atomic. So the shared-memory stuff was done in Ada-callable assembly, where Ada could not see, allowing us to keep Ada in ignorance of things she could not understand.
The part about "because the code optimizer did not know and could not be told that there were other entities that could change memory" also crippled hardware control by reading and writing memory-mapped control registers. Again, assembly-coded Ada-callable subroutines to the rescue.
One obvious question is why we didn't use C, versus assembly, to implement the shared-memory functions, given that we had DEC C. The problem was political: The Ada zealots were afraid of C (their main competitor), but not of assembly. The added effort of coding in assembly was still less than the added effort of fighting the zealots off if we used C. Although it would have been interesting to see how the zealots dealt with a 100:1 to 1000:1 performance problem.
The DoD had a deleterious role here. Their insistence that the entire language be implemented from the start, without being able to start small and grow, forced both compiler and validation suite to be huge, and prevented any serious efforts to optimize the generated code. Said another way, the world's supply of Ada compiler gurus was absorbed with getting obscure parts of Ada and the suite to work. It was many years before compilers good enough to be plausible emerged. It would have been far better to start with the core 10%, and to allow changes to the LRM as experience accumulated.
Data point: Back in the day, I compared the size in bytes of the DEC C compiler and the DEC Ada83 compiler, both of which were well respected. The Ada83 compiler was ten times the size of the C compiler. Complexity is not linear in size, it's more like quadratic.
I've been hearing various forms of this claim about the then latest compilers for the last 45 years, and it has never been true, for a very simple reason: No compiler understands intent, or will tell the programmer that if they only redesigned their entire program around a specific special instruction, a 100:1 speedup would be possible.
My favorite special (SEL 32/55 and I believe IBM 360) instruction is Execute Remote Indexed, which was used to implement a 3-dimensional lookup table of actions to take when a specific button on a specific control panel of a specific box was operated. The actions were single assembly instructions that could be anything from changing a date value to calling a subroutine. There were at least 20,000 selectable actions.
Coming back to optimizing compilers, the real case for them is economic: While any good assembly programmer can beat the compiler, it is not usually worthwhile to do so, because computers have gotten fast enough and cheap enough that shaving 10% off simply isn't worth it.
By 1983, the FORTH folk had gotten over it, but in 1972 or so, when it first came out, they would say very little about how it worked, and they wanted $10,000 for access. In those days, a Volvo sedan was about $3,000.
I asked for a list of ten happy users to talk to, and started calling. Only the users that had cracked the kernel were able to program in FORTH, so, I got an octal dump of the PDP-11 FORTH kernel from one happy user, and reverse engineered the kernel. Then I knew why they were so close-mouthed - it was far too small and too simple to justify such a price. So, I wrote Fifth.
Joe Gwinn
Have something to add? Share your thoughts — no account required.
Ask the community — no account required