Slashdot Mirror
The Sacrifices of Portablility?
hackwrench asks: "There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused. One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit. I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware. We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"
As I understand it, 16 bit code can only address 64k of flat address space. I suppose this would be a performance hit.
Also, wouldn't it waste space in a 32 bit register to hold a 16 bit integer? If so, half of your register space is wasted... I'm not sure about this though. If anyone knows better, please correct me
Is the problem that the compiler optimizations are not producing the right outputs? or too much of the code is compiled with debug flags (ie: -g). I would expect the compiler to handle things, but i've found that I rarely have the desire to run the non-debug code as when things do go south it's rare and i'd rather have ease of solving the problem being available to me. There are some cases where I don't do this where performance matters, but that's rare in my experience.. People have done many studies of what compiler optimizes things better, eg: gcc vs intel compiler. gcc vs sun compiler. Generally the one written by the vendor does a slightly better job.
The hardware / software industry (generally speaking) doesn't care about quality, as long as they are so busy competing with eachother in a high pace. Because companies are competing they will seek some features others haven't and most fo the time the relevancy of those features is very small, especially if the company has become very big (exceptions of course are always there). The crowd isn't very picky either, though it is clear open source has put value to the development of portable software. People buy a amd64 (not only because of the price, ofcourse some geeks also for the 64 bit feature) but the majority runs still 32 bit binary windows software on it. So most people don't care so much I would say. They just buy something because it's cheap, to play games on and do things like patience, free cell and the basic things like word etc. There is so much technology to know about that at some point people don't care anymore. The next day there will always be newer and faster hardware.. Even when you only wanted to make a simple document. But then you have to use Vista (for some) so then you would need a faster computer.. Portabillity is only useful for people who don't want to keep buying software and are fed up with it. A very few of them make their hands dirty and migrate to open/free source software or start to write alternatives themselves. To those people these thing really matter. They want to make something durable and it simply takes time for software to mature. Portabillity of code really matters if there are more open source/ free software users and developers. Then people will experience the benefits of portable code.
See http://en.wikipedia.org/wiki/64-bit: "A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as most operating systems must be extensively modified to take advantage of the new architecture. Other software must also be ported to use the new capabilities; older software is usually supported through either a hardware compatibility mode (in which the new processors support an older 32-bit instruction set as well as the new modes), through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor die (as with the Itanium2 processors from Intel). One significant exception to this is the AS/400, whose software runs on a virtual ISA which is implemented in low-level software. This software, called TIMI, is all that has to be rewritten to move the entire OS and all software to a new platform, such as when IBM transitioned their line from 32-bit POWER to 64-bit POWER. While 64-bit architectures indisputably make working with huge data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks. Theoretically, some programs could well be faster in 32-bit mode. Instructions for 64-bit computing take up more storage space than the earlier 32-bit ones, so it is possible that some 32-bit programs will fit into the CPU's high-speed cache while equivalent 64-bit programs will not. However, in applications like scientific computing, the data being processed often fits naturally in 64-bit chunks, and will be faster on a 64-bit architecture because the CPU will be designed to process such information directly rather than requiring the program to perform multiple steps. Such assessments are complicated by the fact that in the process of designing the new 64-bit architectures, the instruction set designers have also taken the opportunity to make other changes that address some of the deficiencies in older instruction sets by adding new performance-enhancing facilities (such as the extra registers in the AMD64 design)."
In 32 bit protected mode, 16 bit instructions require a prefix to tell it that the following instruction is 16 bit, wasting a byte and a CPU cycle. In 16 bit real mode, the same is true of 32 bit instructions. But modern processors aren't optimized to preserve 16 bit performance. If they can improve 32 bit performance just a little, they'd be willing to sacrifice a lot of 16 bit performance to do it. Also, if you're mixing 16 and 32 bit variables in C/C++, it'll do a lot of expensive conversions to make it all work. I've done very little with 64 bit though, aside from playing with MMX on one occasion.
You can fit two 16 bit integers in the space of a 32-bit register or any other memory device. Existing 16 bit code shows that you can code useful routines that fit in 64k. Also, it's not like 16-bit code and 32-bit code can't communicate with each other. 32-bit code can have several 16-bit routines within its space.
So you decided to post a /. story but you didn't have anything to say ?
>One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
Idiotic example. What are you talking about ? 16 and 32 bit data types ? If so you don't trust your compiler to optimize ? damn. Oh, you're tlking a bout code then ? a combination of 16/32 bit is amazingly rare. For app practical purposes it means running DOS programs on windows, and speed isn't an issue here. Sorry.
>We are beginning to replace systems and programs designed primarily to run in pure 32-bit
>mode with systems designed to run in pure 64-bit mode,
Converting a 32bit application to 64 but will mean nothing, unless it's a special purpose program that can take advantage of the expanded address space. Consider it close to nil percent of desktop software, but important for those few that uses it.
However hardware vendors will jump to 64 bit, they will support it, develop it and 64 bit systems will in short be the ones pushing more GHz through marketing ads. And running in 32 bit compatibility will have a (small) performance hit.
So yes. It's worth it from a performance point for laymans, in the near future, but likely they wont have any use of the gains.
Which area of "worth it" did you want to discuss ? Performance, reliability, investement or something else.
And for whom ? Weather centers needing big iron to predict next weeks weather ?
In 32-bit protected mode, there are 32-bit segments and 16-bit segments. The determination of which is which is stored in a flag in a descriptor stored in a descriptor table. In 32-bit segments, 16-bit instructions require a prefix and in 16-bit segments, 32-bit instructions require a prefix. However, both segments can and do exist side-by-side.
that this transition isn't all that painful.
My personal experience with this was Linux on Alpha, where certain programs assumed a 32-bit environment, rather than querying the system they were built on for size of int, pointer, etc. As a result many programs were funky on the Alpha, and the 'pc-isms' (what we once would have called Vaxocentrisms) caused great waste of time as they had to be tracked down an eliminated.
Your code, if you've been worrying about anything other than 32-bit PCs, should already be 64-bit clean, as you've had 15 years of Alpha, SGI, Power, Itanium, and Sun 64-bit systems to support. If it isn't, hopefully it's something such as user interface which will still run in the 32-bit environment, though not necessarily optimally.
Personally, I think that writing robust, portable, code is worth the effort. Unless you're talking about running on an embedded system where every byte counts, it doesn't hurt you at all to design clean algorithms and data structures, and put in checks to actually determine the size of ints, longs, pointers, etc, rather than just assuming that everyone will run x86 (or MIPS-64 or whatever) from now until the end of time. I have research programs that were written in the 70s (in their original form), on Cyber 205 and similar long-gone architectures, which still work because they were written in a mostly portable manner, with only the most critical nasty bits tied specifically to that machine. Your code is going to be in use longer than you think; be nice to your successors and make it portable now.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
Does "hackwrench" even know how to program? Does he know anything about Computer Architecture? "Hennesy" or "Patterson" ring a bell? Sounds like "Cliff" likes to feed trolls. Maybe "hackwrench" will choke while digesting this one:
What is the inherent "slowness" of "16 bit code" WTF is "16 bit code" anyway? Sounds like has been duped by the marketing droids...
So-called "32-bit" processors are typically designed to perform (up to) 32-bit arithmetic efficiently. For integer operations, 8bit, 16bit and 32bit arithemetic usually each take the same amount of time (8bit add = 16bit add != 16 bit multiply) .
Because "32-bit" processors can do "32-bit" arithemtic efficiently, it makes sense for them to use (up to) 32 bits for addressing. Arithmetic involving addresses comes up more often than you would think... (Branch/Jump instructions, memory operations, and even the basic updating of the program counter). Since these processors data paths are (typically) 32-bits wide, instructions are typically coded using up to 32-bits. (In a 32-bit RISC processor, most of the instruction bits are reserved to allow large immediate operands for memory offsets, jump targets, and arithmetic/logic operations).
The only thing a "32 bit" processor typically isn't good for is "64 bit" arithemtic. (And any arithmetic over 32 bits for that matter). Which means on these, a "64 bit" addition could be performed using 3 "32-bit" additions and a branch. "64-bit" multiplications get even worse...
But if a program doesn't access much memory ( packed arithmetic whereby it can treat a 32-bit integers as a pair of 16 bit integers and a single operation can calculate both results... But this by itself is hardly justification alone for using such a processor.
So guess what folks: There will likely never be a "1024bit" processor. (At least not for general purpose computing). I'm not trying to sound like Bill Gates with his "640k is enough" quote, but I don't see why processors will ever use much more than 64 or 128bit addressing. (Keep in mind that EACH BIT *doubles* the range of integer numbers/addresses the procesor can handle efficiently).
Yes we now can have 2^32 bytes of memory in computers (4GB). But WTF is anyone going to do with 2^64 bytes of ram? Thats probably many orders of magnitude greater than the total capacity of all electronic devices ever produced from the 1950s until now...
In conclusion, WTF? Mod Editor Down!
For instance, consider a video game. The faster it is the more likely it is that players will like it. But there are many more important factors including is the game just plain fun. So in video games, there is really a basic threshold of speed that needs to be met and after that is met, other factors are more important.
Next consider a real time system for trading stocks. This system is all about speed and reliability. You can control the deployment hardware and it is economically worthwhile to spent a lot in development if it makes more money in the long run. So coding your own memory pooler that uses the size of the pointer and a specific struct to make the code allocate and deallocate memory in constant time (it is very possible) is worthwhile because it can save alot of time per transaction.
But all of these issues come down to what exactly you are writing and both the technical and business requirements of your project. Without knowning those in advance, we can't really answer your question.
"Those that start by burning books, will end by burning men."
It used to be that computers were expensive and people were relatively cheap. Nowadays, the reverse is generally true.
So, unless these systems have performance critical portions, like high-speed digital signal processing where every FLOP counts, it really isn't worth the extra effort to optimize your code for the platform - you'll just end up having to hand-tweak (or even worse, un-tweak) it again on the next hardware upgrade.
When information is power, privacy is freedom.
This is the compiler's job. If your compiler targets a particular processor poorly, get a better compiler.
There is no such thing as portable code:
When most developers talk about portability they are talking about OS portability. The portable-to-other-processors debate has long since left the building largely due to incredible speed increases in processors. There's no reason, apart from esoteric algorithm tweaking, to code something in a processor specific manner.
Code porting to another OS is only an issue because operating systems and the hardware they run on are still changing at a dramatic pace. There is no standardized language that covers all the common aspects of a modern operating system, because they are aiming at a moving target. Even the ultra-portable Java has to be extended outside of the official specification to cover serial ports, complex sound, complex graphics, etc.
Portability hasn't been about processor speed for a very long time, and at this point it shouldn't be - a better compiler or a faster processor is a *ton* cheaper (time, money) than writing processor specific code in all but a few extraordinary cases.
-Adam
A 16-bit memory access instruction can only access 16-bits of memory, period. It can't trash more than that. That's a rather trivial benefit, but it exists and if it exists there might still be others which would require experimentation. Here's a better one: The instruction is smaller so you can fit more instructions in RAM which means less flushes to disk. Attacking problems from a "every byte counts" perspective can help you decide what you want to do when every byte doesn't count. Besides, all things being equal, why not go for the smaller code size?
I used to code for QuickBasic. It didn't have routine pointers and a friend wrote a routine that checked the return address on the stack, scanned for the next CALL assembly instruction, put the pointer for the routine into DX:AX, popped the return address and jumped to the instruction after the call to the next routine. You could declare two names for a routine, one with no parameters and one with, and set the pretend call to the parameters name after the address finding routines. It seems that the tools today are setup to make such poking around impossible.
Oh, and there's also this code: SuperPUT replaces the innards of QB's PUT
``As an introduction the properties of a "hardware platform" are described, and it's showen that getting the same behaviour of software on different hardware platforms isn't "portability". After repeating the tasks of an operating system, it is explained what an operating system needs to provide in the lower layers to be portable. The article ends with a case study of the NetBSD operating system.''
Full article here.
16-bit code is code written with 16-bit addressing. 16-bit code is slow on processors designed to perform reads on 32-bit or 64-bit alignment boundaries. 32-bit code has 32-bit addressing. The Intel processors that do 32-bit addressing are designed to read memory 32-bits at a time on 32-bit alignments. For some reason, they can't read 32-bits from the second, third or fourth byte positions. I haven't progressed my understanding beyond this, but there are probably other mechanisms in play. 16-bit addresses means smaller code. Smaller code means less flushes to disk, more calcs per read, and less calcs per instruction.
Current ideas that fall into the current portability mindset has more to do with making the program know as little as possible about its environment. The result is a compiler munging your code and data structures into what it is perceived the processor is happiest with while getting the same apparent behavior across machines instead of switching the processor into different modes to deal with code that is more efficient one way or another.
I want to be able to tell the compiler:
preserveargs funct1(arg1, arg2,arg3)
preserveargs funct2(arg1, arg2,arg3)
preserveargs funct3(arg1, arg2,arg3)
flushargs funct4(arg1, arg2,arg3)
and be able to call any combination of funct1,2,3 in any order and finalize with 4 instead of depending on whether or not the compiler will figure out that doing this will result in faster code.
It doesn't hurt for the compiler to pass speculations up to me, or even to generate potentially more efficient sample source code, but I want to have the final decision on the result of my code, and to have optimizations reflected in the code. That way, no matter what compiler I use, I can be sure to get the same optimizations even if one compiler guesses better than another. This also enables me to pass the code through different compilers and adopt the best optimization results from both into my code. Got a new platform? Run it through a compiler for that platform and have it explain to you why optimizations that were better on another platform are now not so good on the new platform. This helps you be knowledgeable about the different systems you work on which can be used to write better code.
The way it is implemented currently, it makes it so that code in no way reflects the computing archetecture. It's like having the abstraction of functional languages without the benefits of functional languages. One portability implementaion can result in code that is equally suitable for callee popped arguements and caller popped arguements, but if the algorithm favors leaving parameters on the stack for several procedures to access, well sorry, that functionality is not generic enough, so you can't specify that in your solution.
e t32
Also, this code is currently impossible:
routine32bit{
do 32-bit stuff
16bit segment border start
32-bit land call to 16 bit code
Jump overroutine16code1
routine16code1{
16-bit routines
16-bit return
}
overroutine16code1:
More32bitstuff
r
A couple of points about optimization.
1) Premature optimization is evil. Everybody says this, but so many people do not take it to heart. I'd rather have software that works, than software that is fast but crashes. As a programmer, its nice to work on non-buggy software, even if its not as fast as it could be.
2) Target-specific optimization is generally evil, unless you're sure your code will not live very long (eg: a game). The thing is that micro-optimizations generally tune for a particular processor, and actually pessimizes the code in the long run. In comparison, if you write good general code, it'll still be fast ten years from now when processors look very different.
3) The bottlenecks that people, especially C/C++ programmers worry about, are usually not the bottlenecks that usually matter. If you worry that your code could be faster/more memory efficient if you use a 16-bit field here or there instead of a 32-bit one, your algorithms better be absolutely perfect. Most code does not use perfect algorithms. That's why so much software is still so slow. Most programmers just don't get the time to use the best algorithms, much less get down to the level of micro-optimizations.
That's why I always find language performance debates entertaining. C/C++ programmers will freak out if you tell them language X is very productive, but is maybe two-thirds as fast as C (something that is true of a number of high-level, but compiled, languages). Meanwhile, they will write code that runs at maybe 1/3 of what the machine is capable of, because they spend so much time writing the code they have little time to optimize it.
A deep unwavering belief is a sure sign you're missing something...
Generally, the time you spent adding useless annotations to your source code would be better-spent with a pencil and paper trying to figure out a way to improve your algorithm. Compilers, generally, are good enough these days. Especially now that GCC is decent and runs on most of the interesting processors. The gains in performance, and this is is something that even the Linux kernel guys have realized, are going to come from good algorithms. This is especially true because of the recent multi-core phenomenon. More and more, "good code" is going to be code that implements good scalable algorithms. Lower complexity beats smaller constant factors any day of the week.
A deep unwavering belief is a sure sign you're missing something...
You shouldn't be hand optimizing at all unless you've determined that something is too large or too slow.
...so you'd have to know your architecture well...
That's not true at all. There is nothing inherently wrong with hand-optimizing just because you feel like it.
You also say that size and speed are mutually exclusive. While that is generally the case on current x86 architectures, that doesn't always have to be the case. I don't know what causes the penalty for unaligned reads, but Intel could redo its architecture to grab 32 or 64 bits at a time from any base byte, but the current tools that blithly accept the current limitation and don't let coders explore how their code might be different if such a barrier was removed doesn't give Intel an incentive to do so, and that's one of my points.
That's another one of my points. The current focus of portability results in programmers not knowing their hardware well. There's plenty of room for compilers to explain to the coder why the compiler thinks that a given optimization is best suited for the machine, but the current focus has the coder blindly accept whatever the compiler thinks is best.
I don't see any reason why the CPU can't see the register as both 1 32-bit register and 2 16-bit registers. After all, MMX reused the floating point registers.
The problem with writing portable code as things now stand is that it is oblivious to fitting things into cache, as it must remain cache-size independent. Since current tools are built with that sort of attitude about portable code, the designers refuse to implement features to allow the coder to code to cache sizes.
Done properly they can achieve the same goals. Think of the annotations as ways to improve your algoritm, and you might begin to see what I'm getting at here.
That's true, of course, but the compiler can only be as good as the language it's compiling permits.
In higher level languages, you can express design intent more completely than you can in lower level languages. C isn't a high level language, it's a portable assembly language. That's a role it plays very well, but as long as programmers are writing in C, the compiler will have to deal with aliasing, for example. In a higher level language, perhaps the compiler could deduce exactly where a specific piece of data would be accessed, know that there won't be any aliasing, and optimise accordingly.
That's a rather specific optimisation, but more generally, think of compiling for architectures that have multiple processors, dual-core chips, hyper-threading, or some other form of true parallel execution. If your program is written in C, or C++, or Java, it's going to be hard to take advantage of that extra processing ability without touching the code to give the compiler a hint. On the other hand, in many declarative programming languages, it's entirely possible that the compiler could analyse the data flow, find independent paths, and assign them to separate threads on separate (pseudo-)processors algorithmically, without any further help from the programmer.
So, while it may be possible to write somewhat portable code in any language above assembly, the degree of portability you can have, and the degree to which a compiler can help you with it, will always be limited by the expressive power of the programming language itself.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Not quite everyone says that. While I agree with the general principle, premature pessimization is the root of naff code, particularly when insufficient allowance is made for fixing it up once the code is working correctly but slowly.
Consider, for example, passing a large bit of data as a parameter to a function. In languages that use pass-by-reference semantics, this will typically be cheap. In languages that use pass-by-value semantics, this will typically be expensive. In C++, you have a choice, but the natural (that is, default) is by value. Would you tell a C++ programmer not to use const-reference parameter types from the start, because it's a premature optimization?
In some types of software, you simply have to plan for performance from the start. Obviously algorithmic improvements make more difference than anything else, but even so, there's a scale between large-scale algorithm and data structure changes and assembly-level micro-optimisation, not a switch. If you write all your code to be beautifully maintainable, yet fail to consider the continuous nature of this scale from the start, you will never catch up with those who did, no matter how much time you invest in micro-optimisations at the end of the project.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The problem is that when you profile a piece of code, quote often the slowest routine is something you never would have expected. Hand optimizing a routine that gets run 1% of the time is pointless. Quite often this sort of hand optimization makes code ugly, and why make your code ugly for no reason?
Another argument is that generally you don't ever have to do crazy platform specific optimizations to make your program run blazingly fast. For instance, if you determine that the slowest point of your program is the part that for loops through 1000 strings looking for a specific one, the smart thing to do isn't to go nuts hand optimizing the assembly of the loop or making the sure the strings are cache aligned or something. Switch your algorithm so the strings are kept sorted and then do a binary search. Or maybe make a hash table. Either way it's going to be an instant order of magnitude speedup--way way more than you could ever get by hand optimizing the original for loop.
I'm not sure I understand your assertion that the tools are holding you back. Take this structure:There is no implied packing in the C standard--C specifically strives to be platform neutral. Every compiler I've seen will put padding bytes in there to make the accesses fast (or doable at all--must ARM busses can't do unaligned transfers). But if Intel magically put together some hardware that made unaligned accesses just as fast as aligned accesses then the compiler would be able to remove the padding bytes on that architecture.
If you don't need the speed and need your structure smaller then you can tell the compiler to pack the structure (on gcc I think it's something like __attribute__((packed))). So there's nothing holding you back--they just make the default sane for most situations.
The point of C is to let the compiler do the stupid little architecture optimizations for you. So it seems to me like your main point is that you don't trust the compiler. Maybe you should try some of your ideas out in assembly and see if they are worthwhile. If you can show that a particular optimization is worthwhile write it up and send it to the gcc guys.
-David
There. Now go play some cool javascript games!
Lets say you have a 16*32 element array. If you have a 512 element cache, you don't have to have the overhead of logic to group instructions on the data. If you have a 256 element cache, to execute efficiently you would have to employ logic to break your instructions into three pools. One for instruction groups that can work the first half of data and then the second, one for the reverse, and one for instruction groups that thrash the cache, unless of course you can demonstrate that that's always avoidable without adding extra logic. A 128 bit cache incurs even more logic. I would really like to see a demonstration that I am wrong, but this is the point where the other person either doesn't reply or tells me to read the documentation without telling me what the documentation is that I should be reading, or tells me to read something that is highly technical that requires me to have done prior reading, and I can't figure out what those books are.
Yes, and the first hit for "premature optimization is the root of all evil" demonstrates my point exactly. To paraphrase, a good software developer will have developed a feel for where performance issues will cause problems. Making it easy to hand optimize can only help one to develop the feel.
You say, "The point of C is to let the compiler do the stupid little architecture optimizations for you." and you also say "Quite often this sort of hand optimization makes code ugly, and why make your code ugly for no reason?"
C has a conflict of interest. If it has structures to allow you to write beautiful hand-optimization it loses its reason for existing, so guess what, it doesn't. Ugly hand-optimization is a fault of C, not of hand-optimization.
The statement, "There's no implied packing in C" is a bit inaccurate. It's more accurate to say that there's implied non-packing in C, which gets in the way of beginners trying to write to a file data format.
My main point is more like, "The C compiler is not an agent of my will. It has a mind of its own and isn't interested in telling me what's on its mind."
When I programmed in QuickBASIC, I could depend on the fact that a string was coded as a pointer and a length and a memory area described by the two. I could depend on the fact that arrays were coded as all of the dimension entries and a pointer to a memory area. I knew exactly how long a structure was, and if I wanted to write a routine that accepted a variable of a different structure than the one passed to it, I could do that simply by putting a different declaration of the routine in the calling file.
I would know, for example, that:
were identical in size and I could call the same routine, passing one or the other with
DECLARE SUB RoutDef1 ALIAS "MyRout" (A as PalDef1)
and
DECLARE SUB RoutDef1 ALIAS "MyRout" (A as PalDef2)
Your string optimization routine
Because QB always maintained the length of a string, I knew that the fastest way to find an unsorted string was to:
Interesting how that doesn't come up as a potential solution for you in your string performance scenario.
The only final decision you should be worried about with a modern compiler is, "is that result correct?" You've fallen into the trap of believing that your programs are the first to be written that way (they aren't), and that you're smarter than the teams of people who write compilers, and the computer scientists whose algorithms those compilers employ (chances are, you aren't).
Once again, from the real world, I have moved a quarter of a million line parallel Fortran program to a new 64-bit architecture, which was easy because the authors had isolated the machine-specific bits, and had abstracted them as far as possible, so very little actually had to be changed. After that, it was a matter of verifying the code via the official test suite and some personal results (basically, similar jobs, but larger). That code is heavily optimized by algorithmic choice, does a few (carefully isolated) architecture-dependent tricks to save memory, and makes heavy use of system math libraries (i.e. good algorithms, carefully tuned). The kind of bit-twiddling you're advocating, while probably personally fulfilling, is making very little difference in the overall performance of your code, if not actively reducing it.
Your idea of second-guessing the compiler, optimization by optimization, is (politely) impractical, on anything much over a couple of hundred lines. Go to http://www.g95.org/g95_status.html/, pick one of the simulation codes listed, such as AbInit, and convince yourself that you will consistently hand-generate better code than a modern compiler. I know some groups who do hand-coding in assembler, but that tends to be for mathematical primitives. Higher-level functions are written to call those primitives, and left to the compiler to optimize.
I said this elsewhere, but it applies here as well, "Machines should work, People should Think".
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
What happens when you have a 32*32 element array? That's the problem with optimizing to a given data size, you're rarely in the situation (at least in modern programs), where you can count on your data being a given size. It's a far better idea to make your program cache friendly. Depending on your algorithm, perhaps it already is. If you're just reading data linearly, then you probably won't see a significant performance loss going from a 512 element cache to a 256 element cache, even with 1024 elements of data. If you do random access, it'd be worth it to get your program to operate on the data in tiles (say, in 32-element pieces), so your working set will still usually fit in cache.
A deep unwavering belief is a sure sign you're missing something...
Name one such processor feature. What on earth are you talking about?
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
Huh? You are not making sense. What does this have to do with portability? Are you talking about memory models or sizes of variables holding data. In either case it doesn't make any sense. Nobody "purposely uses a combination of 16-bit and 32 bit" because they want to be "portable". If they "purposely uses a combination of 16-bit and 32 bit", it's because that's what the spec says they should, or because the business logic dictates it.
I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware.
If you are talking about memory models, it's not just a performance advantage, it's an advantage. While a computer can do just about anything, there are things that are easy to do, and there are things that are not so easy to do. Mixing 16- and 32-bit memory models in a program is not easy, it introduces a lot of extra complexity, which will no doubt result in more bugs. It was pretty much what made windows 95/98/ME such a mess (and that was the operating systems division, which are paid to handle this sort of thing, imagine the troubles if someone in the app-division did the same!)
If you are talking about mixed-mode arithmetic with arguments of different data sizes, then one can argue that this is in fact a limitation of current hardware. But it's also a limitation that's here to stay. Making everything fast results in a combinatorial explosion of complexity in a CPU. The way it's done today is to either make it slow, or to make it impossible (i.e. require a 16-bit variable to be "promoted" to a 32-bit variable before calculations are done). This allows the common case to be fast, without making the processor more complex. It's likely to stay that way forever!
We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"
The purity is definitely worth it (as explained above). Whether it's worth it to replace working 32-bit systems with new 64-bit systems is an entirely different question. Do you need 64 bits now? Will you ever need it in the future? Will you need it within 1 year, or 10 years? How long do you plan to care for your systems? Are you working on embedded systems, desktop systems, or server systems? Etc...
32-bit systems are going to stay for a long time. Especially in the embedded space, where there is no imminent need for anything more.
Your successors will want employment, right? Unportable code provides jobs. Maybe it even provides a future job for you.
I disagree here. Read the page you linked to again. The point is that you have to have a feel for the overall design of the program you are making and how that design will work in the end. It is not about how fast you can make memcpy() go (for example)--that can only get you so far. Take for example:
That is because in the context of C (which the discussion is about) the lengths of strings are not known (quickly). For large numbers of strings your algorithm is still orders of magnitude slower than keeping the strings sorted and doing a binary search. That was my real point, and Knuth's point. That optimizing your overall algorithm can yield vast improvements that hand optimizing little sections of code just cannot come close to. This is what the linked essay says that good programmers develop a feel for, not silly little tricks to speed up a single for loop. That's the kind of thing you do very last and only if you have an intensely speed critical application and you've already exhausted optimizing your algorithms--because you're only going to speed things up by small percentages.
If the reason you are talking about is some semblance of portability then you are right. Have you ever read the C rationale? It explains the reasoning of the decisions the C committee made and helps you see things from their point of view. It was very enlightening for me when I first read it. It apparently used to be part of the C standard but they broke it off into a separate document at some point.
-David
There. Now go play some cool javascript games!
It is up to the developers to find out how many strings there will be in a typical scenario and to profile the program to see where the bottlenecks are hiding.
So, programming 'cache friendly' is simply reading linearly (tiles have size, so we are back to cache size considerations). What a great idea!
I still remember when cache was only for high level hardware, and a 0 sized cache was the norm.
I agree with the parent poster, programming should be free of those kind of considerations (cache sizes, hardware priorizations, etc).
It would be much better to use our expanding computing capabilities to create self-examining machines... think about a system able to detect that a program is incurring in recurring cache misses and transparently reconfigures itself to improve the program performance.
In 32-bit mode you can still accees the upper and lower halves of the lower 16-bits as [abcd]h and [abcd]l. There is also a command to swap the lower 16 bits with the upper 16-bits
They'll tell you all about how portability is not that important and how everyone will just embrace the new 64 bit architecture.
EAX vs. AX isn't usually the problem, since references to AX can be understood as references to EAX. The real hiccups come when you use AH and AL relative to either AX or EAX, since you can have a mixture of reads and writes to portions of AX/EAX. I'm pretty sure this is why there's no way to address the upper half of EAX while ignoring the lower half.
Program Intellivision!
Caches fundamentally reward spatial and temporal locality. Proper data structure and algorithmic design will help you on any modern system. If you want to go back to the bad-old-days of 10MHz and slower machines, we can get rid of the cache. Caches let you go faster and get the GHz rates we're hooked on.
I don't think you should hard-code for a cache size unless your target is very specific. One place where you would code to particular cache sizes and layouts is the embedded space. (I should know, I work there.) Even then, you can do so in a parameterized manner: #define is your friend here.
As for self-examining systems... We have that today, to a certain extent. Look up Intel's VTune. It's hard to see how you'd change a particular data structure's implementation at run time, though, based on such fine-grained detail. That sort of fine detail is best given to the programmer. Really, what you want to do is have a well-known way for CPUs to inform programs of cache sizes so they can size arrays, queues and other scalable structures appropriately as part of the program's initialization. For instance, if you're operating on large matrices and you can tile your accesses to that matrix, you would set your tile size based on the size of your L1D cache. Otherwise you risk having a tile that's too small (to cater to a large number of systems easily, but incurs a larger fraction of loop overhead) or too big (and thus thrashes some systems).
Other neat tricks include using things like space-filling curves (such as Hilbert curves) to define your traversal through large multidimensional arrays. These sorts of curves have the neat property that they localize accesses pretty close to optimally regardless of the cache size. Their downside is that they're not super general. For instance, I don't see how to readily implement a matrix multiply by traversing the matrix in Hilbert-space order. Large image filters though, sure.
--Joe
Program Intellivision!
Yes, promoting locality, and so on... all those things allow us to fine tune the program at the source code level, my proposal is more radical..
I am thinking on a system (hard/soft) that examines his own behaviour and adapts itself to optimize execution time or power consumption or other external criteria.
Think about repeating usage patterns, ie, libs are almost always in the same place, but each program keeps searching for each one of them at each execution.
Why not to speed the lib detecting process from outside the program?
If a program loads libs A, B, C in that order at start, then why not to allow the system to preload libs B and C while loading lib A at the program start?
If the boot or loging sequence is not changed, why it is not optimized after some executions?
A lot of code is about environment detection/usage, tipicaly that code just goes from generic to particular (load libs, reserve mem, file detection, etc) and it is by nature very estatic (1 load lib A, 2 check dir B, etc). Why the system does not take that in consideration en speeds up the whole process?
Only the system can 'predict' what the program will ask for at a given point and adapt acordingly.
That's an indirection level that I think it deserves consideration.
Whenever you are optimizing, the first thing to do is to use a smarter algorithm or an advanced data structure. No amount of bit twiddling will gain as much as an improvement from say O(n^2) to O(n log n) does. Coding an advanced algorithm on top of low level "performance tuned" code is next to impossible. Therefore, write high level, portable code. After tuning, it is still high level, still portable, and it also performs.
If performance still is not adequate (don't guess, ask the profiler), isolate the ugly bits behind a clean interface, then code machine specific implementations if there's something to be gained.
However, this statement alone
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
tells me that you're far from "seeing it". If you're counting bits, your code will be slow despite being non-portable.
Odds are you do not have a choice. x86-64 is coming fast. Microsoft has Windows running on it, and is likely to make it mainstream sometime soon. They have promised they will anyway.
Apple is moving from PPC to x86 (no word that I know of on 32 or 64, but I would assume both).
Linux runs on so many systems that anything other than portable code will get you flames if you are open source. If it runs on linux it better run on at least all 4 BSDs, and Solaris, if not more.
This is good. In my experience, the porting your code more than makes up for the costs, even if the portable code isn't used outside of test. There are too many 1 in a million bugs on your target platform that happen every time on the other system.
I have used many compilers, on many platforms, and not one of them has ever generated code that is ALWAYS better than what I could hand code in assembler. Compilers are large, complicated pieces of software that do a damn good job. So what if you could make some parts of your code run better on this processor or that, do you want to have to sit down and code routines for every processor? In the bad old days we had to do this, we didn't have compilers, we coded in assembler. That's why it took months to port code from one device to another. A friend of mine has just ported two full EA games in 30 hours. Can you imagine how long it would have taken had you to port it from Z80 to 6502? Far more problematic is porting from one language to another, but that's another whole can of worms. You have a straight choice, write production quality code in your prefered language and live with any minor performance issues, or write software for a processor and live with the fact that you will probably have to code the lot again in the future. Having said that there is one alternative, use Elate, then you have binary portability and you shouldn't have to compile the damn thing every again.
has nothing to do with compiler optimisation nor which compiler is used. Of course if you use an environment, a toolset, a framework which isn't well suited for cross-platform development, you won't get optimal results. But if you use a suited environment like wxWidgets (http://www.wxwidgets.org/) you'll achieve identical results as with platform-specific development.
O. Wyss