Can you run your apps on each other's operating systems?

[NickJohnson]

Those of us who do everything through direct machine code or assembler aren't likely to want to give up the ability to craft our code for absolute speed

Once I've written a code-optimisation program to go with it, it will do all that hard work for me and leave me at no disadvantage, so my code will never run slower than yours, but it will probably run faster in many places and it will certainly be a great deal more compact. We can have a code race to see who's right when everything's finished,....

So you claim that it's possible to write a program that completely optimizes machine code, but that compilers must produce suboptimal machine code (by saying that hand-coding is faster)?

[DavidCooper]

Not Invented Here Syndrome. You cannot "demonstrate" an institution, can you?

It didn't sound like any of them, so I thought a typing error might have been made.

Eeeerrrrmmmm... you're the one kicking off this whole show here about being able to run apps on each other's operating systems, and now you're telling us you have to write stuff like Valgrind or gprof yourself because you cannot port them?

Well, I'd actually never heard of them. It would also be more work to port them than to write my own tools - I've already got a very capable monitor program which does most of the job, so it would only take a few additions to that to give me a powerful code optimisation tool.

[gerryg400]

Well, I'd actually never heard of them. It would also be more work to port them than to write my own tools - I've already got a very capable monitor program which does most of the job, so it would only take a few additions to that to give me a powerful code optimisation tool.

May I ask what those additions would be ?

[DavidCooper]

So you claim that it's possible to write a program that completely optimizes machine code, but that compilers must produce suboptimal machine code (by saying that hand-coding is faster)?

You'd be hard pushed to get a compiler to produce code that can't be speeded up by making a few intelligent low-level tweaks to it here and there.

[NickJohnson]

So you claim that it's possible to write a program that completely optimizes machine code, but that compilers must produce suboptimal machine code (by saying that hand-coding is faster)?

You'd be hard pushed to get a compiler to produce code that can't be speeded up by making a few intelligent low-level tweaks to it here and there.

Yes, but compiler designers probably have come up with whatever low-level optimizations you plan to automate. I understand that hand-coded assembly can be faster than compiled HLLs, but you're just being contradictory if you say that you want to avoid compilers so that you can hand-code, but want to optimize the resulting program automatically. If you think that you can hand-code better than a machine (compiler/optimizer), then hand-code without an optimizer. If you think that a machine can code better than you, let it, but don't write your own optimizer when you could be simply writing in a HLL...

[gerryg400]

So you claim that it's possible to write a program that completely optimizes machine code, but that compilers must produce suboptimal machine code (by saying that hand-coding is faster)?

You'd be hard pushed to get a compiler to produce code that can't be speeded up by making a few intelligent low-level tweaks to it here and there.

You may be correct, but I think you're simply guessing. What about some evidence ?

What optimisations can you make to code that gcc has optimised for speed that will futher speed it up ?

[DavidCooper]

May I ask what those additions would be ?

Let's jump a step and just assume you intend to ask what those additions would be. The monitor program currently interprets machine code programs, displaying the contents of the registers and showing which instructions are being run, along with the names of any indexed bytes (starts of routines, names of called subroutines, and names of variables pointed at by the code). If a called subroutine is labelled in a particular way (bit 7 being set in one of the name bytes in the index), the monitor program runs the subroutine directly instead of interpreting it, so speed-critical code interacting with hardware isn't slowed down.

What this program could do that it doesn't do now is check the order of instructions to see if they're likely to cause a blockage in the processor where a different order could enable them to be processed in parallel (though the hardware already does a lot of reordering automatically just before the code's run, so the gains may be less significant than you might imagine), and to see if addresses could be calculated earlier so that the data they point to can be cached as early as possible - I'm not sure if that really works because it suggests that any value put in any register will result in that being treated as an address and the data at that address being loaded into a cache, though it maybe only applies to some of the registers (SI and DI perhaps). There are a number of simple rules like that which you are supposed to follow which it could be applied, but I'd need to do actual tests to see if those rules work in the real world before going to the trouble of programming them in: they may be plain wrong. It should be easy enough to test them though, because all I need to do is write a little program with a loop to be repeated thousands of times and make a succession of changes to the order of the carefully-designed contents of that loop to see if it makes any difference to the speed. Once that's written, it could be run on many different processors and could produce a list of results each time in a format which would allow it be added straight into the code-optimisation program.

I could also compare my code with stuff generated by compilers to see if I'm missing any tricks. Some instructions are so slow that it's better to use two or more alternative instructions instead, so it could flag those up just in case they are used by accident. The code-optimisation program wouldn't actually run the code, so it would be able to chop and change the program as it goes, and a cut-down version of the same program could optimise the code for the specific processor in the machine just before running it. There's no reason to imagine that these programs couldn't match the code-optimisation abilities of the best compilers.

Here's a question for you though: which compiler should I be comparing my code against? Do the more expensive ones produce the fastest code or does the free Microsoft Visual C++ 2010 Edition (which I recently acquired) do just as well?

[gerryg400]

Let's jump a step and just assume you intend to ask what those additions would be. The monitor program currently interprets machine code programs, displaying the contents of the registers and showing which instructions are being run, along with the names of any indexed bytes (starts of routines, names of called subroutines, and names of variables pointed at by the code). If a called subroutine is labelled in a particular way (bit 7 being set in one of the name bytes in the index), the monitor program runs the subroutine directly instead of interpreting it, so speed-critical code interacting with hardware isn't slowed down.

You have a monitor program. It sounds a bit old-fashioned in design but that's okay.

What this program could do that it doesn't do now is check the order of instructions to see if they're likely to cause a blockage in the processor where a different order could enable them to be processed in parallel (though the hardware already does a lot of reordering automatically just before the code's run, so the gains may be less significant than you might imagine), and to see if addresses could be calculated earlier so that the data they point to can be cached as early as possible - I'm not sure if that really works because it suggests that any value put in any register will result in that being treated as an address and the data at that address being loaded into a cache, though it maybe only applies to some of the registers (SI and DI perhaps). There are a number of simple rules like that which you are supposed to follow which it could be applied, but I'd need to do actual tests to see if those rules work in the real world before going to the trouble of programming them in: they may be plain wrong. It should be easy enough to test them though, because all I need to do is write a little program with a loop to be repeated thousands of times and make a succession of changes to the order of the carefully-designed contents of that loop to see if it makes any difference to the speed. Once that's written, it could be run on many different processors and could produce a list of results each time in a format which would allow it be added straight into the code-optimisation program.

All these things can be done by compilers, so clearly your system will absolutely be required to do them if you want to produce average code.

I could also compare my code with stuff generated by compilers to see if I'm missing any tricks. Some instructions are so slow that it's better to use two or more alternative instructions instead, so it could flag those up just in case they are used by accident. The code-optimisation program wouldn't actually run the code, so it would be able to chop and change the program as it goes, and a cut-down version of the same program could optimise the code for the specific processor in the machine just before running it. There's no reason to imagine that these programs couldn't match the code-optimisation abilities of the best compilers.

Only matching the output of state of the art compilers is an epic fail. You are playing catch-up and not catching up.

Here's a question for you though: which compiler should I be comparing my code against? Do the more expensive ones produce the fastest code or does the free Microsoft Visual C++ 2010 Edition (which I recently acquired) do just as well?

I'm surprised to see this question. You've been talking like you've already tested your ideas (at least theoretically) against the best of the current compilers. It now sounds like perhaps you haven't.

[DavidCooper]

Yes, but compiler designers probably have come up with whatever low-level optimizations you plan to automate. I understand that hand-coded assembly can be faster than compiled HLLs, but you're just being contradictory if you say that you want to avoid compilers so that you can hand-code, but want to optimize the resulting program automatically. If you think that you can hand-code better than a machine (compiler/optimizer), then hand-code without an optimizer. If you think that a machine can code better than you, let it, but don't write your own optimizer when you could be simply writing in a HLL...

I don't think it is realistic to try to produce better code by hand all the time when the optimisation rules are so complex, and that's why an automatic code-optimisation program would be a very useful tool which would save a lot of pointless work and wasted time, but there are certain areas where hand coding results in faster, more compact code which can't be matched by compiled code, so why should I limit myself by using a compiler? I'm not comfortable with programming languages in any case as they impose all manner of complexities on me which I'm completely free from when I use my own programming system. I'm also working in the same way that A.I. will work when it writes its programs: that was the main reason I decided to work in machine code in the first place. I want to see and work with the actual code that's sent to the processor, or at least one version of it. You can't even see it fully clearly from assembler, so very few programmers have a proper view of what goes on in the machine. The only part of the picture I don't see is what happens when the instructions are turned into micro-ops, reordered and shoved through different pipes, the registers not even being constant any more but having a whole host that can be renamed and with multiple registers representing the same register while speculative calculations are carried out on their contents - there's a whole lot of fascinating stuff going on in there which I'd like to be able to program for directly just for the fun of it, but the next best thing's to work with machine code numbers, and why shouldn't I work that way when it's so easy to do anyway? Most of the time I'm just typing in 232 Space p/o/P/O name Space, calling lots of existing routines which do most of the hard work, with little bits of joining work involving moving things between registers or to and from memory - code which will frequently run faster than your compiled equivalents.

[NickJohnson]

there are certain areas where hand coding results in faster, more compact code which can't be matched by compiled code, so why should I limit myself by using a compiler?

Why not combine a high level language with machine code? Most OSes use assembly not only for calling special instructions, but also for optimizing important pieces. Then you have a way of using lots of portable, slightly slower code for general stuff and fast, unportable code for things that require it.

I'm also working in the same way that A.I. will work when it writes its programs: that was the main reason I decided to work in machine code in the first place.

Even if you can work backward from machine code to the semantics of a program using AI, it will still be much less efficient than working backward from a high level language. Compiler optimizers don't produce machine code then optimize it: they optimize at many levels, using the free semantic information given to them by the high level language source. It is easy to find a for loop in C source; it's hard to find a for loop in a compiled C object. If you are using some sort of AI that can work on any "language", why do you assume that language is most naturally machine code, when machine code has so much useful information stripped out of it?

[gerryg400]

The only part of the picture I don't see is what happens when the instructions are turned into micro-ops, reordered and shoved through different pipes, the registers not even being constant any more but having a whole host that can be renamed and with multiple registers representing the same register while speculative calculations are carried out on their contents - there's a whole lot of fascinating stuff going on in there which I'd like to be able to program for directly just for the fun of it, but the next best thing's to work with machine code numbers, and why shouldn't I work that way when it's so easy to do anyway?

You're correct. There is lot's of stuff you can't see. Some of it is documented and some of it is not. Some of it is possibly deliberately not documented for reasons to do with company IP. BUT, my point is that the guys who write compiler backends CAN see it and DO know how the innards of the CPU work. They have all the documentation, hardware and software simulators, proprietory analysis tools and they can see how it all works. To make code better than they do requires more than enthusiasm.

[DavidCooper]

You may be correct, but I think you're simply guessing. What about some evidence ?

What optimisations can you make to code that gcc has optimised for speed that will futher speed it up ?

I'm amazed that you even need to ask. Have you never used assembler? If you really know what you're talking about, you should be able to provide examples of your own.

You have a monitor program. It sounds a bit old-fashioned in design but that's okay.

It's simple, but I keep adding capability to it. There's actually quite a lot left to add because so far I've done all my work on old machines which lack many of the newer instructions.

All these things can be done by compilers, so clearly your system will absolutely be required to do them if you want to produce average code.

That's the whole point - to eliminate any code-optimisation advantage that a compiler might have so that none of my code runs slower.

Only matching the output of state of the art compilers is an epic fail. You are playing catch-up and not catching up.

I will catch up and then stay level on that score - the whole point is to automate as much as possible such that even keeping up with new developments is made easy. There is no epic fail and indeed no fail about it - parts of my code will run faster than compiled code, while none will run slower.

Here's a question for you though: which compiler should I be comparing my code against? Do the more expensive ones produce the fastest code or does the free Microsoft Visual C++ 2010 Edition (which I recently acquired) do just as well?

I'm surprised to see this question. You've been talking like you've already tested your ideas (at least theoretically) against the best of the current compilers. It now sounds like perhaps you haven't.

I've made no secret of the fact that I've only just started learning to program in C++ and that I've no experience in programming in assembler or any other serious programming language, the only ones I've used being Basic (which I used in the early days to poke my original machine code program into memory) and JavaScript (which I use on Web pages, often in unorthodox ways - see http://www.magicschoolbook.com/maths/graph and http://www.magicschoolbook.com/writing/small which teaches young children the right way to write the letters of the alphabet).

I don't need to compare my code with compiled output to know that many parts of my code will run faster: I can do things which the compiler simply cannot have the intelligence to do unless it's running human-level A.I. Of course, it may be that C allows you to do all the same low level stuff whenever you have to, though I have heard that you can't even access the carry flag. I use it all the time to simplify and speed up code.

[DavidCooper]

Why not combine a high level language with machine code? Most OSes use assembly not only for calling special instructions, but also for optimizing important pieces. Then you have a way of using lots of portable, slightly slower code for general stuff and fast, unportable code for things that require it.

I do combine a high-level language with machine code, but that language is natural language - I program in thoughts in my head, maybe write them down in natural language if I'm planning the broad outlines of a program, and then write the actual machine code numbers. I simply miss out the programming language stage, and A.I. will do likewise.

Even if you can work backward from machine code to the semantics of a program using AI, it will still be much less efficient than working backward from a high level language.

Why would you work backwards unless you're trying to disassemble code? The real programming isn't done in machine code or a programming language, but through a natural (or artificial) language of thought - everything else is just a translation of that, so why bother to go through a high-level programming language phase?

Compiler optimizers don't produce machine code then optimize it: they optimize at many levels, using the free semantic information given to them by the high level language source. It is easy to find a for loop in C source; it's hard to find a for loop in a compiled C object. If you are using some sort of AI that can work on any "language", why do you assume that language is most naturally machine code, when machine code has so much useful information stripped out of it?

The original program is in a language of thought, potentially stored in natural language form like a recipe. That program would then be translated directly into machine code for different kinds of processor (meaning ones using different instruction sets), but there's still room for an automated optimisation phase before running the machine code program to tune it to the processor's id. The alternative would be for a longer delay while the program is retranslated for the specific model of processor from scratch.

[NickJohnson]

Ack! You continue to speak vaguely and naively. I suggest you do some experimenting and find how well you are grounded in reality.

[DavidCooper]

You're correct. There is lot's of stuff you can't see. Some of it is documented and some of it is not. Some of it is possibly deliberately not documented for reasons to do with company IP. BUT, my point is that the guys who write compiler backends CAN see it and DO know how the innards of the CPU work. They have all the documentation, hardware and software simulators, proprietory analysis tools and they can see how it all works. To make code better than they do requires more than enthusiasm.

To make code better than the code their compilers produce requires you first to match their code-optimisation (which should be perfectly possible - testing will show up what works best, and anything missed by that testing will show up like a beacon whenever my code-optimisation program disagrees with the output of their compilers), and then to use intelligent tricks which their compilers cannot perform, though as I look through my code the only things jumping out at me are tricks to reduce the bulk of code rather than to speed it up. Tell me this though: when you call a function and send it some values, what is the mechanism by which it collects them? Likewise, how does it return values to you afterwards? Does it just stick them in registers, or do they all have to be stored in memory in between? I seem to remember that the latter was the case a couple of years ago, but I don't know if today's compiler's are any better at that. There's also an option to pass data in registers or set the carry flag to tell the subroutine that the data didn't fit and can be found at the standard alternative memory location instead. Opportunities like that frequently present themselves to low-level programmers. I use nibbles to compress text, rarer letters being prefixed (average letter size being 5 bits), so when I'm working with words (text) in compressed form they usually fit within a 4-byte register, but occasionally they will be too big.