...
This is exactly what I mean. It was a long time ago a skilled assembler programmer could outperform a decent compiler. Assembler as a hobby - well I guess everybody is kinky in some way :-)
-- --
That is - the problem domain. Not technical details. Making ut FAR more easy to maintain in the long run.
Indeed.
A high level language and a profiler makes a good match. But the profiler only needs to be considered when the high level language was proven NOT to fulfill the spec.
A skilled assembler can always outdo a compiler for which no natural language mappings exist.
I.e. with INTEL I/O, IN and OUT instructions cannot be performed by C.
They can be performed by a C compatible library subroutine of course, but that puts huge overhead in a low cycle instruction.
Or they could be inlined if the compiler is specific to the architecture.
Which breaks code portability. But then if you are using hardware ports, code unportability tends to be unavoidable....
Future generations will wonder in bemused amazement that the early twenty-first century?s developed world went into hysterical panic over a globally average temperature increase of a few tenths of a degree, and, on the basis of gross exaggerations of highly uncertain computer projections combined into implausible chains of inference, proceeded to contemplate a rollback of the industrial age.
Richard Lindzen
I'm not quite in agreement with that - very few programs (in my experience) have a time-to-perform specification, but have some rather vague concept of being "usable". Of course there are exceptions. Even then, being able to speed up part of the program by identifying bottlenecks may allow new functionality to be added.
A Raspberry Pi model 1 works, but model 3 is much more pleasant to use, so being able to improve performance may not be part of the spec, but it often a worthwhile aim. Most of my software is written for human interaction, and I do hear complaints about how slow comparable programs are.
But next year's CPUs will be faster, won't they?
-- Cheers, David Web: http://www.satsignal.eu
Very interesting article in the register....
-- A lie can travel halfway around the world while the truth is putting on its shoes.
Agreed, though for many program structures/types of problem the profiler may not be needed.
I've found a profiler is nearly essential for SQL/database optimisation and program performance nearly irrelevant if the database is badly designed and optimised, while often all you need to spot the problem in a interactive process is a transaction usage frequency count.
IME most analysts and designers (and I include myself here) haven't the first clue about estimating transaction use frequency and the user population's use estimate is no help either.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Humph. Try reading this first-hand account before believing that's anything like the whole story. It appears that RL never visited the Arctic, and knows little about its non-linear processes, particularly w.r.t. methane release and replacing ice with darker earth and sea:
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
ic over a
I also recommend a look at the link below. This guy does his research.
-- W J G
It is an interesting article but one would need to see the hand-written code alongside the compiler output to get a real answer as to why the Ada output was better. At the end of the day, an assembly programmer can always produce code that is at least as good as a compiler.
That said, compilers and programmers tend to work differently. IME for small modules programmers nearly always win. But as modules get larger the compiler gains the advantage.
An interesting thing I have found is that the /source/ code is often better than the /target/ code - and that applies in either direction, even when assembly is the source. Trying to convert some assembly to C, for example, can end up with rather complex C for simple assembly.
Basically, assembly programmers can use facilities that are simply not conveniently expressible in high level languages. They can use things like flags registers, bit accesses, subregister accesses, rotations, and specialised instructions - features that HLLs do not support.
That said, the really big gain - IMO - of an HLL is in allowing the generated code to run on different hardware. Assembly code often has to be written carefully to get the best out of a specific CPU. By contrast, HLL code can be written once and compiled for multiple target CPUs. That is often an enormous advantage.
-- James Harris
My first hand knowledge is dated (I've barely written -- as opposed to read -- assembler for 20 years or so), but even in those days received wisdom was that given the non-deterministic instruction execution timings implied by caching and memory access, managing the relevant trade-offs to generate code with the best expectation execution speed was hard, and a compiler generally did a better job than anyone other than a serious expert.
Yes, there were a few cases where a human knew more about the expected timing behaviour of the code than the compiler, and the relevant section was worth devoting the considerable effort of giving to a guru to optimise by hand, but those cases were few and far between.
I'm *guessing* that now out-of-order execution is commonplace, there'll generally be bugger all difference between the performance of various logically equivalent instruction sequences, as timings will be dominated by real data dependencies.
I freely grant that this may well not be true for microcontrollers, DSPs and the like, though: I have no relevant experience.
Pleased to be corrected if any of this is wrong!
-- Cheers, John
That's the same for most peripheral chips, Intel or not: to write, you put the byte in the write register and then loop waiting for the result to appear in the status register. Reading is the same, but reversed: you loop watching the status register until its says a byte has been read, then fetch it from the read register.
Disk controllers are similar except that you also have to tell it which sector to read or write before issuing the read or write command and then loop waiting for the operation to complete.
For single tasking OSen: Flex, CP/M, DRDOS, etc this stuff is buried in the ROM as callable routines and the OS is configured by adding a custom module that it calls to access the ROM routines.
In C and other high level languages calls to this low level code is buried in clib or its equivalent. The only variation is that in multitasking OSen the wait loops are not used and the status test is an additional, separately callable routine.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
IMO anybody who doesn't look at XKCD isn't paying attention.
OK, some are incomprehensible to non-USAians but the rest are generally worth your time and some are brilliant.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
*cough* I think you'll find that the "assembler code is always better" crowd are looking back *40* years rather than a mere 20 *cough-hack pfttang* years.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Sorry, you wont get me to change my mind over ANYTHING 'published' in the 'new scientist'.
Anyway the proof of the pudding is in the temperature record, which shows almost no correlation with measured CO2 whatsoever.
-- If I had all the money I've spent on drink... ..I'd spend it on drink. Sir Henry (at Rawlinson's End)
In the wrong places.
-- "What do you think about Gay Marriage?" "I don't." "Don't what?" "Think about Gay Marriage."
??? Obviouly you have never progtammed I/O on an intel chip and pereiphreal.
Which is written in assembler.
The only variation is that in
-- "In our post-modern world, climate science is not powerful because it is true: it is true because it is powerful." Lucas Bergkamp
30 years, on micros.
-- No Apple devices were knowingly used in the preparation of this post.
If you believe that I have this bridge between Manhattan and Brooklyn you'll certainly want to buy.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Oh, a newby.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
No thanks. Its clear you were conned into buying it yourself.
Some suckers will believe anything.
-- Canada is all right really, though not for the whole weekend. "Saki"
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.