Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

The Sacrifices of Portablility? 95

Posted by Cliff from the ease-of-design-vs-processor-efficiency dept.
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?"
This discussion has been archived. No new comments can be posted.

The Sacrifices of Portablility? More

The Sacrifices of Portablility?

Comments Filter:

  • Compiler Optimizations (Score:3, Informative)

    by jaredmauch ( 633928 ) <jared@puck.nether.net> on Saturday November 12, 2005 @11:00PM (#14018300) Homepage
    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 industry (Score:2, Interesting)

    by Device666 ( 901563 )
    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 bu

    • Re:The industry (Score:3, Insightful)

      by __david__ ( 45671 ) *
      Portabillity is only useful for people who don't want to keep buying software and are fed up with it.
      No, portability is more useful to those writing software that has to run in 2 (or more) environments. Say I want to write a game that runs on the xbox and the ps2. The more portable I make my code, the happier I will be in the long run (and the cheaper the price will be for the port to whichever platform comes second).

      -David
  • See http://en.wikipedia.org/wiki/64-bit [wikipedia.org]: "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 implemen

  • 16 bit is often slower than 32 bit (Score:5, Informative)

    by dtfinch ( 661405 ) * on Saturday November 12, 2005 @11:22PM (#14018372) Journal
    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.
    • 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.
    • The original question mentioned mixing 16 and 32 bit, not explicitely variables. When I code c I'll use 32 bit integers for variables without worrying. But for arrays, data structures, and arrays of data structures I'll put some thought into whether I need a field to be 32 or 16 bits.

      you are right that mixing 32 bit and 16 bit variables is a recipe for slowness.
    • First of all, 16 and 32 MODES have nothing to do with 16 and 32 bit variables. Secondly, variables smaller than int are ALWAYS promoted to int or unsigned int automatically in expressions. So, assuming int is 32 bit, 16 bits variables are always promoted to 32, regards if all variable involved are 16 bit or not. Besides, as long as the variables are aligned in memory (which the compiler will take care of), there is no penalty.

  • Ideally, your code is clean enough (Score:5, Interesting)

    by Frumious Wombat ( 845680 ) on Saturday November 12, 2005 @11:36PM (#14018428)
    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.
    • 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 bei
      • > A 16-bit memory access instruction can only access 16-bits of memory, period. It can't trash more than that.

        I think that in RISCs, memory access is word aligned, so if you do a load 16, what the HW will do is fetch a 32bit word and then putting 16bit in your register.
        I'm not sure how writes are handled though.
        • This depends more on the bus than the CPU architecture. I know some 32 bit busses have lines to say whether the transfer is 8, 16, or 32 bits. If you read a byte of data on the bus--lets call it 0x0d, then 0x0d0d0d0d is actually sent across the bus. Other busses will work like you said and transfer 32 bits of data from a rounded address and then let the CPU pick out the correct byte. Some will just transfer 0xXXXXXX0d where XX is something random.

          -David
      • Here's a better one: The instruction is smaller so you can fit more instructions in RAM which means less flushes to disk.

        If your instructions don't find in RAM completely, then you're screwed. Buy more RAM.

        Attacking problems from a "every byte counts" perspective can help you decide what you want to do when every byte doesn't count.

        I don't see how.

        Besides, all things being equal, why not go for the smaller code size?

        Because, all things are generally not equal. Worrying about this stuff makes sense if you're
    • Your successors will want employment, right? Unportable code provides jobs. Maybe it even provides a future job for you.
    • Personally, I think that writing robust, portable, code is worth the effort.

      I hope your manager does, too. What does he say if you're already late with the project, but you tell him you'd like to test it on another architecture?

  • 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 3
    • You right. But it also depends on what kind of bits for what kind of processor and how the innovation in software use (that affects the architecture of that processor) will be. I think before they will sell (never) 1024 bits "processors", there might be some qubits and quantum processors and a pletoria of different architectures in processors as well (if we haven't become backwards cavemen due to the centuries of patent-wars)..
    • 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 m

      • For some reason, they can't read 32-bits from the second, third or fourth byte positions.

        Ah, NO. The Intel x86 ISA allows non-aligned memory accesses... (It is probably one of the few commonly used ISAs that do this).

        16-bit addresses means smaller code. Smaller code means less flushes to disk, more calcs per read, and less calcs per instruction.

        That may be, but are you still refering to the Intel x86 ISA???? It uses variable-length instructions. These are a nightmare decode (for hardware) but ar

    • Seeing as you summon Computer Architecture [sic] onto the field, I'd like to take this chance to remind you about the existence of MMUs and memory mapping. It's not all core memory you see in that address space. Even if that were not the case, 1 GiB of core memory is no longer a rarity, and 2 GiB is getting there as well. It's not difficult to guess the direction from there on.

      As for "anyone", there's this bunch of meteorologists, biologists and astrophysicists I'd like you to
      meet...
    • NNN-bit does not necessarily defines size of addressable memory - it might as well be just size of the internal processor bus. For pretty much every modern problem that relis on heavy number crunching (like, e.g., anything based on FEM) you will benefit a lot from, say 128-bit (or 256-bit) native floating point operations even if address space still would be 64-bit. Another use would be large number vector registers (to support which you would need wide internal bus) - so I could easily imagine useful "1024
      • For pretty much every modern problem that relis on heavy number crunching (like, e.g., anything based on FEM) you will benefit a lot from, say 128-bit (or 256-bit) native floating point operations even if address space still would be 64-bit.

        Agreed. There's still room for improvement when it comes to floating point formats. While 2^63-1 is a ridiculously large number for integer calculations, with floating point, you will still see the benefit going from 64-bit to 256-bit. And then, there's also funkier th

    • The m68k is a good counter example. 8 bit and 16 bit adds take 4 clocks, but 32 bit math takes 8 clocks. But if you aren't working with embedded systems you don't need to worry about things like this.

      Also Most processors have a carry/extend flag (there are exceptions) so a 64 bit add with a 32 bit registers can be done with 2 adds.

      >>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

    • Re:Detailed Reponse to Cliff and HackWrench (Score:4, Insightful)

      by Anonymous Brave Guy ( 457657 ) on Sunday November 13, 2005 @02:45PM (#14021153)
      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?

      I don't know. Then again, ten years ago, if you'd told me that an e-mail client or web browser would require tens of megabytes of memory just to load, or it would require over 100MB just to store the quick start-up code for an office application, I'd have laughed. Right now, that's exactly what Firefox, Thunderbird and OpenOffice 2.0 are claiming on the PC where I'm writing this.

      Actually, I'm still laughing, because that says more than words about the design of those applications and the tools used to compile them. But the applications have expanded to fill the space nevertheless.

      • Yes. I too can image that in the days of 16-bit 'desktop' processors, the idea of 4GB of ram must have been absurd... But its really not when it comes to manipulating hi-resolution photos, multi-user databases, etc...

        However,think about how large 2^64 is... Isn't like the same order as the number of atoms in the universe or something like that??

        Let's guess that in the near future, there will be 10 billion people in the world (~10^10). Let's say we wanted a single computer that could store something about ev

  • It depends (Score:5, Insightful)

    by sfcat ( 872532 ) on Saturday November 12, 2005 @11:41PM (#14018447)
    There are many factors that go into deciding how to write code. Portability is just one consideration of many. I would say that it is worth it if speed is of critical importantance and development expenses are of no concequence.

    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.

    • Re:It depends (Score:5, Interesting)

      by forkazoo ( 138186 ) <wrosecrans@@@gmail...com> on Sunday November 13, 2005 @01:52AM (#14018831) Homepage
      A lot of people are writing responses that tend to assume it is impossible to write code that is portable, and also optimised for a specific platform. I recently read a book called "Vector Game Math Processors" (everybody needs a hobby, right?). Looking at how the examples were coded in that book sort of shifted my assumptions about how I should do things.

      Basically, the book covers the major vector instruction sets: Altivec, PS2, SSE, etc. Naturally, a program written with hand optimised SSE assembly won't run very well on a PowerMac G4. So, the approach the author used was to start by coding a vector math function in plain C. He only calls this function by a function pointer. So, instead of calling sw_vector_foo directly, he calls vector_foo. He then goes on to write altivec_foo, and sse_foo, and gamecube_foo. With some simple #ifdefs at compile time, the function pointer is assigned to the most optimal code path for the platform.

      So, the result is that by thinking about portability going in, he doesn't have to do hardly any work to have fairly optimal hand-tuned vector routines for a new architecture.

      In general, code written to be portable is also much cleaner, and better commented, and whatnot, just because the author was forced tos pend an extra few minutes thinking about how things ought to be put together. I really can't think of any normal case where portability shouldn't be a consideration. On some obscure embedded systems, you might really want to optimise to a super specific piece of hardware, but it is seldom worth it.

      Think about writing GUI apps for a Palm pilot before the switch to ARM CPU's. A programmer could have said, "hey, I'm using the Palm OS API's, and they only run on Coldfire CPU's, so I have no reason to make anything portable." Then, a little while later, Palms OS starts running on ARM. If he had invested a smidgen of extra effort to write his code in a portable way, he could easily start to take advantage of the ARM stuff right away. Since most of the issues of portability are in the planning phase, and get handled at compile time, the difference in memory footprint need not be appreciably larger. (Like a bunch of hand coded ASM for a different platform, which get's #ifdef'd away, or sizeof() operators...)
      • 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 specif

      • Basically, the book covers the major vector instruction sets: Altivec, PS2, SSE, etc. Naturally, a program written with hand optimised SSE assembly won't run very well on a PowerMac G4. So, the approach the author used was to start by coding a vector math function in plain C. He only calls this function by a function pointer. So, instead of calling sw_vector_foo directly, he calls vector_foo. He then goes on to write altivec_foo, and sse_foo, and gamecube_foo. With some simple #ifdefs at compile time, the

  • Does it matter? (Score:5, Insightful)

    by Jah-Wren Ryel ( 80510 ) on Saturday November 12, 2005 @11:51PM (#14018492)
    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.

    • Re:Does it matter? (Score:5, Insightful)

      by richg74 ( 650636 ) on Sunday November 13, 2005 @12:09AM (#14018553) Homepage
      It used to be that computers were expensive and people were relatively cheap. Nowadays, the reverse is generall

      For most applications, the potential performance gains from hand optimization for a specific platform aren't enough to matter. (And, as I think Brian Kernighan said, trying to outsmart the compiler defeats the purpose of using one.) Big performance gains come, in most cases, from figuring out a better way (~algorithm) to solve the problem, not from tweaks.

      There's another aspect of portability that doesn't get mentioned too much: the portability of the programmer. If you are in the habit of writing portable code, it's much easier to shift to working on a different platform. (I'd also say, from my own experience, that it makes your work less error-prone.) That versatility is potentially of significant value to your employer, and of course is of value to you personally.

      • 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,
        • 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 phenome
        • 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

  • This is the compiler's job. (Score:4, Insightful)

    by stienman ( 51024 ) <adavis&ubasics,com> on Sunday November 13, 2005 @12:05AM (#14018543) Homepage Journal
    There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused.

    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:
    • There is code that is written according to the language specification (Ansi C, Java, etc), which is what one normally considers "portable" only because standards compliant compilers exist for several platforms.
    • There is code that uses processor/platform/OS/compiler specific extensions, which is normally considered unportable because libraries don't exist for all platforms.

    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
    • It's also interesting to point out that more recent processors are designed to not have any particular features that could be supported. Even x86 processors generally only fully-support a RISC-y subset of the ISA, and microcode the weird, complex instructions.

    • This is the compiler's job. If your compiler targets a particular processor poorly, get a better compiler.

      Hear hear. You are 100% correct here.

      There's no reason, apart from esoteric algorithm tweaking, to code something in a processor specific manner.

      Agreed, but it sometimes takes some thought to even realize you are coding in a processor specific manner. For instance, if you've ever programmed for a Mac or written networking code on a PC you realize that all binary data formats were created with a cert

    • This is the compiler's job. If your compiler targets a particular processor poorly, get a better compiler.

      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 aliasin

  • Seeing you talk about mixing 16(?!) and 32bit code, you're probably on a completely different problem set, but maybe this article helps a bit understanding some other problems involved in portability:

    ``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

    • 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.
      • Well, so let your compiler pick the right data types, recompile, and be happy on your new platform, and achieve eternal happyness.

        Trying to remain binary compatible between all those platforms is just too much of a PITA. :)

  • The performance question (Score:5, Insightful)

    by be-fan ( 61476 ) on Sunday November 13, 2005 @06:27AM (#14019479)
    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.

    • Premature optimization is evil. Everybody says this, but so many people do not take it to heart.

      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 t

      • 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?

        I would tell a C++ programmer that worrying about a bit of extra

        • I would tell a C++ programmer that worrying about a bit of extra data copy in the function call is generally useless. It's really not that expensive unless your structs are monstrously large. [...] If, after profiling, you find that this is a problem, use the passing style on those few functions that the profiler points out. Doing it for everything else is useless.

          The thing is, that's not true. In isolation, it might be, but the overhead of passing a data structure that is a few words of memory by value

          • The thing is, that's not true. In isolation, it might be, but the overhead of passing a data structure that is a few words of memory by value becomes significant if your function is called from inside a loop, and potentially horrible if you do it routinely throughout your program.

            If its in a critical area, then the profiler will point it out. If its not in a critical area, then it doesn't matter. Plus, do you have any idea what the overhead really is? It's tiny. I just tried a benchmark calling a very simpl

            • Even if its a constant 20% hit in all the other functions, we're talking about a 4% overall performance decrease, which is insignificant.

              I understand what you're saying, but I think you're still missing my point. This is just one trivial but routine efficient coding practice, and you've just demonstrated that if a lot of your functions are simple things working on moderately complex data, the overhead of not doing it can be as high as 10%, all because of a stubborn insistence that no optimisation should

  • Huh? (Score:2)

    by joto ( 134244 )
    There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused.

    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

  • They'll tell you all about how portability is not that important and how everyone will just embrace the new 64 bit architecture.
  • 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

  • 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 experienc

  • 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 po

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Close