Slashdot Mirror


Intel's New Compiler Boosts Transmeta's Crusoe

Bram Stolk writes: "Intel recently released its new C++ compiler for linux. I've been testing it on my TM5600 Crusoe. Ironically, it turns out that Transmeta's arch nemesis, Intel, provides the tools to really unlock Crusoe's full potential on linux." It doesn't support all of gcc's extensions, so Intel's compiler can't compile the Linux kernel yet, but choice is nice.

272 comments

  1. Re:Gee by joshjs · · Score: 1, Redundant

    Hell, I'll buy Transmeta. Sure, I'll have to go without food for...say...twenty minutes or so, but... =^)

  2. Take Note that... by robbyjo · · Score: 1

    Intel's C++ compiler still compiles code to x86. This is really great, considering that the approx. 28% speedup in Crusoe is not the native Crusoe. I wonder how Crusoe will fare once there is a compiler that build straight to its native.

    For me, Crusoe + icc + GNU/linux is a winning combination.

    Well, to me, it's a hasty conclusion. P4 gains 26%, Athlon XP gains 19%, and plain Athlon gains 16%.

    --

    --
    Error 500: Internal sig error
    1. Re:Take Note that... by smileyy · · Score: 2, Interesting

      You're one of those people who just doesn't get the fact that the Crusoe gets speed gains by *not* using its native instruction set.

      --
      pooptruck
    2. Re:Take Note that... by kingdon · · Score: 2, Informative

      Exactly. One benefit of x86 instructions (the only benefit? ;-)) is that they are pretty compact. And that wouldn't be such a big deal except that it means more of them fit in cache, you can fetch more instructions in one memory cycle, and that sort of thing. So using native transmeta instructions across the bus could easily slow things down (kind of a thought experiment, since as far as I know they haven't done it even for testing purposes).

    3. Re:Take Note that... by Anonymous Coward · · Score: 0, Flamebait

      If I had moderator points, I'd mod 90% of you down as (-5, Moronic)

      That's because you're an asshole.

    4. Re:Take Note that... by Anonymous Coward · · Score: 0
      Not that I wish it wasn't so but I think that corusoe will go down as one of the biggest marketing mistakes every. the primary issue is that Transmeta has not seen the light and allowed access to the native instruction set. this would have been beautifull for linux.


      Code morphing would have been nice as a bridge device, but is otherwise a waste. Normal computing operation should not be streamed through any sort of an emulator.


      The sad reality is that with all of the engineering talent Tranmeta has they could have really moved the computing world forward. The X86 instruction set is dead!!!! Intel knows this and so does everybody else. Clearly this is why Intel itself is putting so much effort into an X86 replacement.


      I hate to see a company fail but Transmeta's present business plan is doomed for failure.

      Thanks
      dave

    5. Re:Take Note that... by Ozx · · Score: 1

      The x86 instruction set is hardly dead... It is by far the currently most widely used platform for personal computing, and while Intel is developing its IA64 platform, it's years away from being a home product... Couple this with AMD's push for 64-bit x86 evolution, and Intel's current practice of extend and effectively deprecate old functionality, and one can easily see a future where the current IA32 IS serves and the foundation for future development...

      However, let us assume that the x86 is indeed dead, and that the IA32 IS is a waste... Where's Transmeta's problem again? They simply develop morphing layers for whatever springs forth, and their development is hastened by the design of their processors, and their disallowance of any sort of low-level muckery...

      This sort of pointless debate reminds me very much of the sort of idiots that read that the K6 line of processors used a RISC-ish core with microcode translation, and stepped up and said, "Wow I wonder how fast they'd be if we had access to their internal IS!"

      The point of Crusoe is a low-cost, low-power, dynamic instruction execution engine. Whether or not it fails and kills Transmeta will have had nothing to do with some obscure instruction set that would recieve even less support...

    6. Re:Take Note that... by mgv · · Score: 1

      So using native transmeta instructions across the bus could easily slow things down

      Yes, but you could compress the instruction set and just use the code morphing software to decompress the instruction codes on the fly to minimise the memory requirements of the software both on disk and in ram/cache.

      Michael

      --
      There is no cryptographic solution to the problem where the intended receiver and the attacker are the same entity.
  3. I'm confused... by srvivn21 · · Score: 1

    At first in the writeup it looked as though you were planning on compliling an image, and I thought to my self "Holy crap, self! Can complilers these days make graphics from source code?" Then I realized that you were just compiling the program to make the image. Then I looked at the example, and it looks as though you are (effectively) compiling a graphic. I'm so confused... :o)

    1. Re:I'm confused... by justinstreufert · · Score: 1

      He's compiling a raytracer; A 3-D rendering program designed to take instructions and create an image from them.

      The point here is that the raytracer code generated by icc is more tuned; it's optimized and can do its job faster.

      Justin

      --
      "Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
    2. Re:I'm confused... by Anonymous Coward · · Score: 0

      wow you're really dumb

    3. Re:I'm confused... by Anonymous Coward · · Score: 0

      You must be really new to computers.

    4. Re:I'm confused... by srvivn21 · · Score: 1

      Yeah, I got that. Figured it out by the end of the write up. Thanks for the post though.

      I have jest never been exposed to raytracing source before. Really quite interesting, the similarities between it and computer source code. I don't know what I was expecting, but what I saw certainly wasn't it.

      Again, thanks for the kind clarification. It was much more constructive than the AC that also replied.

    5. Re:I'm confused... by Elwood+P+Dowd · · Score: 2

      Uh, are you trolling? The raytracer is a program that runs on a computer. Thus, the raytracing source *is* computer source code. They're not similar, but the same.

      --

      There are no trails. There are no trees out here.
    6. Re:I'm confused... by srvivn21 · · Score: 1

      Did any of that really sound like I'm looking for an outraged reaction from the readers? I sure hope not. It was more a statement regarding the first impressions I had with ray tracing instructions. As I stated, I'm not really sure what I was expecting, but the instructions for "drawing" that fish was not it. To be quite honest, I'd take the whole thing back if I could.

    7. Re:I'm confused... by DAldredge · · Score: 1

      I think he his talking about the source the raytrace reads in to render the image...

    8. Re:I'm confused... by Anonymous Coward · · Score: 0

      That really didn't sound so outraged to me. I'm glad you were able to get your answer, but it wouldn't have been hard to figure it out on your own.

      But I'll shut up now, since this big, bad AC response will probably just hurt your feelings and ruin your Friday night.

      Have a pleasant evening.

    9. Re:I'm confused... by Elwood+P+Dowd · · Score: 1

      Dude, I'm sorry. You didn't say anything offensive at all. I thought you were saying you understood and then asking the same question. My friends call this ironing:

      "You know, I've never understood how ironing works. I just don't get it."

      "What do you mean you don't know how ironing works. Everyone knows that."

      "No, really. Like, what's the point?"

      "Well, it's to get the wrinkles out of clothing."

      "What, like stretching?"

      etc...

      --

      There are no trails. There are no trees out here.
    10. Re:I'm confused... by justinstreufert · · Score: 1

      Ahhh.. I see. Yeah, povray code freaked me out too when I first saw it. A "scene description language.." VRML looks sort of like that too.

      The cool thing is that all raytracers, as far as I know, take input like this. It's just that povray exposes it in a semi-readable symbolic format. When you push the Render button in 3DS MAX, or whatever, there is an intermediate format - basically lists of objects, polygons, transformations and attributes - that it uses to generate the image in memory.

      Justin

      --
      "Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
  4. Uh... by davster · · Score: 1, Interesting

    Intel's compiler can't compile the Linux kernel yet

    Last time i checked the kernel was in C not C++

    1. Re:Uh... by AaronMB · · Score: 2, Informative

      Intel's compiler can compile both C and C++.

    2. Re:Uh... by Anonymous Coward · · Score: 0

      C++ was born before a "C++" compiler ever existed, and used to be compiled by the C compiler (albeit converted first). C++ compilers can compile C code (of course some adjustments may need to be made), and in fact the reverse is also true sometimes.

    3. Re:Uh... by strangemoose · · Score: 3, Informative
      hmmm... The reason Intel's compiler can't compile the kernel is that the kernel uses extentions that only gcc has. like __attibute__((packed)), ARGV style macros and embeded blocks:
      #include useless_macro(a, b...) ({ printf(a, ##b); })
      --
      Sig? What sig?
    4. Re:Uh... by Anonymous Coward · · Score: 0

      I can really only think of 2 problems compiling ANSI C code with C++:

      C++ has a few more reserved words (this, public, private, etc),

      C++ has // comments

      int x = 10 //* this is legal C */ 2;

      Quite a few C compilers have supported // comments for a long time. In fact, BCPL and B, which C was based on, used // comments.

      Anyhow, the linux kernel uses some inline gcc asm, and some gcc-specific extensions. Also, the linux kernel is developed and tested with it, so it may be a while (when hell freezeee over) before any other compiler is officially supported.

    5. Re:Uh... by Billly+Gates · · Score: 3, Informative

      According to the ansi standard all c++ compilers must compile c code.

    6. Re:Uh... by YogSothoth · · Score: 1

      well, here's some C code - how does your C++
      fare when trying to compile it?

      typedef struct
      {
      int template;
      int new;
      int class;
      int throw;

      } SomeStruct;

      --
      there are two kinds of people in this world - those who divide people into two groups and those who don't
    7. Re:Uh... by Broccolist · · Score: 1

      It compiles it just fine. Of course C++ is not an exact superset of C, so all compilers have a compile-time option of some sort specifying whether the program is C or C++ (usually just the file extension).

    8. Re:Uh... by Anonymous Coward · · Score: 0
      Wow, you're clever.


      Not.

    9. Re:Uh... by Anonymous Coward · · Score: 0

      No, try (good'ol') cfront.

    10. Re:Uh... by psamuels · · Score: 1
      so all compilers have a compile-time option of some sort specifying whether the program is C or C++

      Pedantically, this is not true of gcc. The C and C++ compilers are separate programs, named cc1 and cc1plus.

      (Sure, they can both be driven by the compiler drivers, which are named gcc and g++....)

      And I don't believe there is anything in the ANSI C++ standard that dictates that a conforming compiler must have C-compiler mode -- although it must accept C function prototypes when you use extern"C".

      --
      "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
    11. Re:Uh... by pthisis · · Score: 2

      A C++ compiler won't give anything approaching the same results as a C compiler.

      Example:

      sizeof('a')

      is 4 on Intel/C, and 1 on Intel/C++. More generally, it's the same as sizeof(int) in C and it's sizeof(char) in C++.

      Example:

      char *a = malloc (10);

      Should issue a diagnostic in any conforming C++ compiler, requiring a cast of the malloc() return value to (char *) to suppress the warning (which results in a lot of dangerous casts in C++ code that things like lclint will be confused by).

      There are tons of such things, which make it nearly impossible to compile any reasonable large C project with a C++ compiler and get correct behavior. And that's assuming that you don't have variables named "new" or your own "bool" type or anything obvious like that.

      Sumner

      --
      rage, rage against the dying of the light
    12. Re:Uh... by Anonymous Coward · · Score: 0

      So don't use C. It's obsolete.

  5. Without the kernel, what good is it? by WillSeattle · · Score: 0, Interesting

    OK, the first thing you said was that it unlocked Transmeta's strengths. This is good - especially since I own some stock, I'm pleased.

    But, as you said, you are unable to compile the kernel. So, it's like saying:

    Son: "Look, ma, I got the fastest wheels in the world for my car! Now I can gain 100 mph when I speed down the road!"

    Ma: "Um, sonny, you still have to get the engine working before you can do that."

    So, again, until you can actually compile the kernel, it's a fascinating breakthrough, but one with little utility to the real world.

    -

    --
    --- Will in Seattle - What are you doing to fight the War?
    1. Re:Without the kernel, what good is it? by Trepidity · · Score: 2

      Uhh, just because you can't recompile the kernel doesn't mean you can't recompile your other programs. You can keep your gcc-compiled (slower) kernel and then recompile your other programs with the Intel compiler (faster). Just because only part of your system speeds up doesn't mean it's useless.

    2. Re:Without the kernel, what good is it? by basking2 · · Score: 2, Interesting

      What I think is being pointed out is that on-cpu time will be shorter. This has some nice pluses to it, even if the kernel doesn't get the nice optimizations of it all. I would love a faster apache server, even if my kernel is (reletivly speaking) more pokey. :-)

      --
      Sam
    3. Re:Without the kernel, what good is it? by justinstreufert · · Score: 1

      Say... The Linux kernel, and povray for that matter, ran just fine on Transmeta BEFORE icc came out. You just compiled them with gcc.

      The only thing different here is that they run a bit faster!

      Exactly how much did you learn about Transmeta before you bought their stock? ;)

      Justin

      --
      "Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
    4. Re:Without the kernel, what good is it? by geomcbay · · Score: 1, Flamebait

      How much time does the CPU spend running kernel code as opposed to user-land app code? Virtually none. Idiot.

    5. Re:Without the kernel, what good is it? by Sentry21 · · Score: 5, Insightful

      So, again, until you can actually compile the kernel, it's a fascinating breakthrough, but one with little utility to the real world.

      So what you're saying is that the only really useful use of a compiler is to compile the Linux kernel?

      That's quite possibly the silliest thing I've heard someone say. Try:

      Son: "Look ma, I got the fastest engine in the world for my car! Now I can drive faster than anyone else!"

      Ma: "Um, sonny, it can't play MIDI files or make julean fries, so it's totally useless."

      Totally wrong. There are thousands of pieces of software out there. The Linux kernel is merely one.

      --Dan

    6. Re:Without the kernel, what good is it? by arseonick · · Score: 1

      (10, Uses Car-as-Computer analogy)

    7. Re:Without the kernel, what good is it? by Anonymous Coward · · Score: 0

      icc produces gcc-compatable object files, so you might be able to compile certain portions of the kernel.

      Have fun testing, though :)

    8. Re:Without the kernel, what good is it? by Anonymous Coward · · Score: 0

      bullshit. Unless you've applied the pre-emptive kernel patch.

    9. Re:Without the kernel, what good is it? by SquierStrat · · Score: 1

      Most speed loss is via applications, not the kernel. This compiler can most definitely help out in that area. Mozilla and XFree86 are two that I bet could get a nice boost from it!

      --
      Derek Greene
    10. Re:Without the kernel, what good is it? by Anonymous Coward · · Score: 0
      but one with little utility to the real world.


      LOL! Gotta love people who think they are smart, but actually come across as complete tools. Christ, buddy, I'm not sure what "real world" you live in, but in mine there are scads of C/C++ programs that would benefit immensely from a good compiler.

    11. Re:Without the kernel, what good is it? by ksheff · · Score: 2

      wow, the compiler fixes bloated design issues too?

      Seriously though, any speed up with any program helps. Given that Mozilla's UI is in XUL and that's were a lot of the sluggish behavior seems to be, has anyone come up with a jit compiler for xul?

      --
      the good ground has been paved over by suicidal maniacs
    12. Re:Without the kernel, what good is it? by Anonymous Coward · · Score: 0

      Actually, Microsoft is going to ship a JIT compiler for JavaScript. Maybe the Netscape boys should look into it :)

    13. Re:Without the kernel, what good is it? by SquierStrat · · Score: 1

      I agree, design with those two is a big issue...i'd say particularly more so with XFree86...In a way with the networking ideas behind XFree86 it makes sense for the purpose but when it's just on your desktop machine...wtf? Err am I making sense?

      --
      Derek Greene
    14. Re:Without the kernel, what good is it? by ksheff · · Score: 2

      There is a sub-project for Mozilla called Rhino that implements the JavaScript interpreter in Java. It apparenlty can or did translate JavaScript into Java bytecode that could be processed by the JVM's jit. According to the history page, it doesn't sound like it worked all that great (leaked memory and the JavaScript->Java translation was slow).

      --
      the good ground has been paved over by suicidal maniacs
  6. My results with Linux and NetBSD by Walter+Bell · · Score: 5, Interesting
    The Linux results were interesting, but rather flat: everything benefited from it on my system. However I rebooted into NetBSD and gave the compiler a shot at 'make sys' and 'make world'. Because the NetBSD kernel does not use any nonstandard gcc extensions, it compiled just fine with the new compiler. What I found was:
    • The kernel showed a marked performance benefit on the TM5600. On my TM5400 the results were not noticable.
    • Most userspace utilities appeared to be quite a bit faster on both CPUs. However, some (one notable example being /usr/local/bin/perl) were much slower with the new compiler. I verified that this was not the case on Linux, so it is unclear to me as to why this happens under NetBSD. Further investigation is needed.

    ~wally

    1. Re:My results with Linux and NetBSD by Fillup · · Score: 1

      Thanks for a good comment. I really have to set my threshold back up to [2].

      --
      "I think there is a world market for, maybe, five computers." __ IBM Chairman, 1943 __
    2. Re:My results with Linux and NetBSD by Anonymous Coward · · Score: 0

      What I'd like to know is why you're running NetBSD on i386.

  7. How long until Intel changes the compiler? by nizo · · Score: 1, Flamebait
    Ironically, it turns out that Transmeta's arch nemesis, Intel, provides the tools to really unlock Crusoe's full potential on linux.


    Any bets on which of the next versions will spew an error about "incompatible architecture" when used on non-Intel hardware?

    1. Re:How long until Intel changes the compiler? by vrmlknight · · Score: 1

      why the hell would they optmise a compiler for a processor only to use that compiler on a different processor?

      --
      This must be Thursday, I never could get the hang of Thursdays.
    2. Re:How long until Intel changes the compiler? by Anonymous Coward · · Score: 0

      I think he means non-Intel x86, like Athlon, Crusoe or Samuel...

  8. GCC extensions?? by Reality+Master+101 · · Score: 4, Insightful

    Wait, the Kernel uses GCC extensions? I thought the Kernel was written in real C, not that bastard GCC version. I've never look at Kernel code, so I'm not sure. Is this really true?

    If it's true, I think that's a huge mistake. The Kernel should not be at the mercy of one compiler.

    --
    Sometimes it's best to just let stupid people be stupid.
    1. Re:GCC extensions?? by wmshub · · Score: 5, Informative
      Yes, the kernel uses enormous numbers of GCC extensions. It gets significant performance improvements this way. Perhaps you are willing to give up kernel performance for a portability, but from my experience as an instructor in a Linux device drivers class, you are in the vast minority. A kernel really needs assembly inlines (for example the sti and cli instructions are get inserted pretty frequently in critical code paths), and to do them well you have to use extensions to C.

      There are even some places where GCC extensions make the code easier to maintain. For example, the way that device driver entry points are defined is much cleaner (using the "structure member : value" structure initialization syntax) and less error prone than using standard C.

      Yes, it might have been helpful a few times to have been able to compile Linux on a non-GCC compiler, but not very often. And GCC runs almost everywhere, so limiting yourself to GCC doesn't limit the architectures you can port to. It really does seem that in this case the benefits outweigh the losses.

    2. Re:GCC extensions?? by Anonymous Coward · · Score: 1, Interesting

      Being at the "mercy" of GCC is not a bad thing - it is the most portable compiler on earth. What's wrong with that?

    3. Re:GCC extensions?? by srvivn21 · · Score: 3, Interesting

      It gets significant performance improvements this way.

      But are these performance increases greater than what would be realized if the Kernel could be compiled using icc?

      This doesn't address the maintainence issue, but it's something that I am looking forward to seeing in the near future. I figure someone has the time and drive to hack the Kernel source to the point that icc will compile it. Goodness knows, I don't.

    4. Re:GCC extensions?? by TheAwfulTruth · · Score: 2, Interesting

      Perhapse, but what if gcc isn't the best compiler in the world? What if, besides caruso, Intel's compiler is actually a BETTER compiler than gcc on intel hardware? Then were stuck using gcc for compiling the kernel when something better is or might be some day available. Locking the kernel to a compiler is a BAD THING[tm].

      --
      Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
    5. Re:GCC extensions?? by Carnage4Life · · Score: 2

      Wait, the Kernel uses GCC extensions? I thought the Kernel was written in real C, not that bastard GCC version. I've never look at Kernel code, so I'm not sure. Is this really true?

      Here's some kernel code. Now you've seen it.

      If it's true, I think that's a huge mistake. The Kernel should not be at the mercy of one compiler.

      Why not? The major goal of operating system design is to extract as much performance as possible with as little overhead as possible. Portable code by definition is rarely as efficient as code targetting a specific platform or compiler.

    6. Re:GCC extensions?? by yesthatguy · · Score: 1

      I totally agree with you, but just to play the Open Source advocate :)...anybody can look at the code to see what each special function in gcc does, then write their own similar compiling function, since it's well-documented. So, if Intel had a goal of making the linux kernels compile, they could do it fairly easily by implementing handles for the special functions they call. Needless to say, they can't just grab the original gcc code and re-distribute it within their closed-source program (I'm pretty sure), but that's the nature of the beast.

      --
      Yes! That guy!
    7. Re:GCC extensions?? by cb0y · · Score: 1

      its only boosted because normal GCC optimizations are not that great.

    8. Re:GCC extensions?? by cb0y · · Score: 1

      Perhaps its time the kernel uses in 5% of its space C++

    9. Re:GCC extensions?? by rgmoore · · Score: 3, Interesting
      The Kernel should not be at the mercy of one compiler.

      "At the mercy of" one compiler is a rather strange description, don't you think? After all, both Linux and gcc are released under the GPL, which means that anyone who wants to use Linux will already be willing to accept what many people view as the most obnoxious feature of gcc (the license). And it's not as though the gcc developers can yank the rug out from under Linux by making it proprietary, refusing to distribute old versions, etc. If anything it would be crazy to make serious modifications to Linux to take advantage of a compiler like Intel's that could be taken away at any minute.

      --

      There's no point in questioning authority if you aren't going to listen to the answers.

    10. Re:GCC extensions?? by p3d0 · · Score: 1

      "The mercy"? What exactly is this doomsday scenario you're afraid of?

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    11. Re:GCC extensions?? by Micah · · Score: 2

      gcc may not be the best compiler in the world, but it's open source. If there is a serious deficiency, it can be fixed without relying on a certain company. We know it will always be there.

      Now, tying an Open Source project to a single proprietary compiler or tool is certainly a bad idea. I'm trusting proprietary tool makers less and less every day (based on how Borland is handling Kylix). But tying it to Open Source tools, especially popular ones, is not a problem.

    12. Re:GCC extensions?? by Anonymous Coward · · Score: 0

      SGI did this with their MIPS compiler -- however I don't know if it compiles the Linux kernel, I think it's more targeted towards gcc'ed userspace programs on Irix.

    13. Re:GCC extensions?? by Ozx · · Score: 1

      GCC is not the best compiler on earth, however... And while you might be content with using GCC, there's little good technical reason to use extensions that don't easily translate to other compilers... In this case, the Intel compiler, which generates much better code...

    14. Re:GCC extensions?? by hawkfan · · Score: 1

      gcc may not be the best compiler in the world, but it's open source. If there is a serious deficiency, it can be fixed without relying on a certain company.
      This would be the case if a certain company didn't own the patents that allowed these optimizations.

    15. Re:GCC extensions?? by psamuels · · Score: 1
      Locking the kernel to a compiler is a BAD THING[tm].

      Have you looked to see what extensions are used, and why? I have.

      The most common one is __asm__, which allows inline assembly language in a C file. Sure, other compilers support asm statements, but they usually do not have the flexibility of gcc in terms of communicating to the compiler which variables to load in which registers, which registers to store back to variables, and which registers your inline code will clobber (very important for the compiler to know, for optimisation purposes).

      Then there is the structure initialiser code which someone else already brought up. This makes structure initialisers much easier to read and maintain. (Recently the ANSI people came up with a competing syntax to do the same thing, but the kernel was using gcc syntax long before that - there's been talk of switching over. I personally find the gcc syntax much clearer anyway.)

      If you look at how the kernel uses assembly language, you would see that it would be very cumbersome indeed to have to separate out all asm statements into their own files, to be assembled rather than compiled. And it would hinder inlining, which brings us to...

      ...kernel usage of inline. Would you rather have a kernel with no inline code at all? Because until recently, there was no C standard for what inline was supposed to mean. (C++ has such a keyword, but not C.) I'm not sure, but I believe ANSI has now said something about inline -- but again, the kernel has been around much longer than that.

      One of my favorite gcc extensions is varargs macros. I recently had to port a small application to MSVC from gcc, and I really felt the pain of not having this! The kernel doesn't use this too much.

      Anyway, to answer your accusation, the kernel is not, in fact, locked into one compiler! This is not the first time a different compiler was found to be better than gcc on a given Linux platform - two examples I know of are the Compaq compiler for Alpha and the Metrowerks CodeWarrior compiler for PowerPC. At least one of these (I don't remember which) was given gcc extensions for the express purpose of allowing it to compile the kernel. There is no reason Intel couldn't do the same with icc.

      --
      "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
    16. Re:GCC extensions?? by Yokaze · · Score: 2

      It's a very pragmatic decision.

      Different compiler do produce different code and have different extensions.

      To enable compiling the kernel with different compilers, you have to programm for the different extensions and you have to test the kernel with the different compilers. This, plus the different architectures supported gives you a (n*m) variety of possibilities and the same amount of problems.

      For the very same reason, the kernel is not only for GCC it's also only for one or two different versions of GCC.
      Maybe take a look a the LKML-FAQ, where Rafael R. Reilova gives an anwser on why not use different compilers.

      --
      "Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
    17. Re:GCC extensions?? by Anonymous Coward · · Score: 0, Flamebait

      Nor do you have the knowledge to do so. You forgot to mention that one.

    18. Re:GCC extensions?? by Anonymous Coward · · Score: 0

      "structure member : value" initialization is part of C99, though it has different syntax (".member = value", IIRC).

      Most C compilers (at least, that I'm aware of) support some form of inline'd assembly... There are tricks do doing so portably, but it's not impossible if you're willing to either use generated code (i.e., assembly to inline'd assembly conversion), or use #ifdefs to select which inlining method to use.

      A lot of gcc's extensions can be used in a more portable fashion than they are. One of my projects at work involved using both gcc and a specialized compiler against the same source, which needed to use compiler extensions.

    19. Re:GCC extensions?? by Anonymous Coward · · Score: 0

      You most likely wouldn't see more than about 1% improvement. The kernel is already pretty optimized where it matters. Most of the time is spent in very simple algorithms that execute for tiny fractions of a second. The real benefit of icc is for longer running code when the caches and branch misprediction come into play more.

  9. Real Men by Tairan · · Score: 1
    Write their optimized code in ASM. Who needs fancy c++ compilers/et al. "But Tairan, do you know how hard it is to write perl in ASM?" you ask? My answer: use a real language :)

    Seriously, anything that is going to need the optimizations that this new compiler does, should probably be written in ASM anyway. Your 'hello world' and 'count and increment an array' programs are not going to run any faster. Don't bother.

    --
    /. is a commercial entity. goto slashdot.com
    1. Re:Real Men by Electrum · · Score: 1

      That's completely false. How many programs do you have that you wish were faster? If you can notice how long it takes for a program to do something, then it's not fast enough. Wouldn't you like your Perl or PHP scripts to run faster? Should you have to rewrite them in assembly? Isn't it better to recompile the interpreter with a better compiler than write it or the scripts in assembly?

    2. Re:Real Men by porky_pig_jr · · Score: 3, Funny

      Real men write machine code directly, in hexes. Who needs the pinko sissy commy fag Assembly Language?

    3. Re:Real Men by Anonymous Coward · · Score: 0

      Real men code in code in high level languages so that they can get the job done quickly and spend time with their partners.

    4. Re:Real Men by Anonymous Coward · · Score: 0

      DUH! real man code visual basic!

    5. Re:Real Men by Anonymous Coward · · Score: 0

      Wrong. In the "real world" (as many /.-ers like to talk about, but few seem to actually know much about) many programs are millions of lines of C or C++. Switching compilers for a program of that size takes MONTHS of effort, but rewriting that code into assembler (or more logically taking some tooled executables and doing targetted optimizations) would take YEARS and probably never work right. I have been involved with at least one multi-million-line code base that we swiched to Intel's C++ compiler for a 5% gain in speed for a lot less money than it would have cost to get that speed through manual recoding.

    6. Re:Real Men by MrHat · · Score: 2, Funny

      Nah. Real men can write assembly in *any* language. :)

    7. Re:Real Men by Mindbridge · · Score: 2, Funny

      And Real Men rewrite the entire kernel when a new processor comes along.

    8. Re:Real Men by Anonymous Coward · · Score: 0

      Real men fuck around with cheerleaders, not computers. We have Linux geeks to take care of computers. Duh.

    9. Re:Real Men by kill-1 · · Score: 0
      No, real men write code like this:

      # zcat >a.out

      OK, I know it's an old joke.

    10. Re:Real Men by Knobby · · Score: 2

      Only LONELY geeks program in Hex or assembly!

      Real Men code in C++, Java, Fortran, or Objective C, get the necessary job done, then go home to f*ck the prom queen!

    11. Re:Real Men by Anonymous Coward · · Score: 0
      Granted, we could all use faster performance.

      Not that I have any experience benchmarking Perl, but let's say that we're discussing that -- to allow me to write in straightforward English.

      When evaluating performance, one has to ask what causes it to be too slow. Your argument includes the assumption that the increase in speed shall be retained when the rest of the executables you run (kernel, daemons, other executables) are changed or recompiled.

      That's not a trustworthy assumption. When the kernel changes, or when the compiler used for it changes, the environment in which Perl runs, to guarantee the speedup you desire, you must then forbid changes to the rest of the binaries that comprise your Linux installation.

      If you do not limit such changes, you run the risk of unbalancing the Linux box, taken as a whole. What if the advantage of the compiler you used for Perl as a special case consisted of unrolling loops five times? You would increase the size of each binary in the kernel and each executable loaded by that kernel. The trade-off for your faster execution of single code paths would be a reduction in PCI bandwidth available for uses other than disk I/O as well as greater stress on the parts of the kernel that perform that I/O.

      As for me, in this sort of case, I would rather ask "why is Perl slow?" The problem might lie in its design or implementation, and an improvement there might benefit everyone running Perl on every architecture.

      I would also prefer to run a vanilla Linux box, so that I could take full advantage of changes to the kernel's design or implementation or changes of compiler vetted by people working on it across the planet.

      I would also not entrust a Free project to a proprietary tool. The owner of that tool could then manipulate the project to suit their goals. I would not want to force a fork in the kernel based on the choice of compiler, which would become possible if the compiler used were not GPL.

      In the case of Intel's compiler: Intel's goals do not included the long-term benefit of Transmeta, AMD, the PowerPC consortium, or anyone other than Intel. What would prevent Intel from changing the compiler in future, to the comparative advantage of their own products?

      What of Intel's decision to make the P4 slow at executing traditional x86 floating point code? The way to improve floating performance depends on SSE2 instruction set extensions that, as of this writing, only Intel has. While this does not fork the x86 instruction set, it forces application developers to optimize floating-point for the P4 or for everybody else -- which, for x86 users who care about floating point performance, means AMD.

      Sorry, but I do not wish to open the Linux kernel to manipulation by the people who allowed Intel to cause problems for the entire PC industry by trying to force the adoption of Rambus RAM.

      Not that Intel's any different from any vendor in a position of power. Nicholas Petreley draws an analogy between control of platform standards by proprietary commercial entities and the possession of the One Ring. Quoting from his "Down to the Wire" column in the July 27, 1998 edition of InfoWorld:

      You can argue about the merits of this or that software license when it comes to applications, but when it comes to the dominant operating system, I'll argue the best possible license is the GNU public license (GPL). The GPL requires the Linux source code to remain open and available.

      This ensures that no single person or company can leverage Linux to an unfair advantage -- the antithesis of the current market standard. To be fair, the state of the market is not all Microsoft's fault. Control over the dominant operating system is like J.R.R. Tolkien's One Ring. It will inevitably corrupt whoever wears it and turn that person into a tyrant. I suspect that if Windows had lost to OS/2, for example, the Ring would simply have been passed from Microsoft to IBM. I'd be writing this column about Lou Gerstner instead of Steve Ballmer.

      Linux is like Tom Bombadil -- the only character in the Lord of the Rings trilogy immune to the seduction and effects of the evil ring. Oracle, IBM, and Sun have fantasized about owning the Ring. But they -- along with Informix, Netscape, Computer Associates, Software AG, InterBase, and Corel -- are finally facing the reality that they can't have it. And they are coming to the realization that, if they can't have the Ring, then maybe the world would be a lot better off if nobody did.

    12. Re:Real Men by morbid · · Score: 0

      Naw, both wrong. Real Men (tm) code using the switches on the front panel of the machine and the load/store button. Then , you run the paper tape punch and dump bytes out to that device (memory location). You can look for errors in the code that way and fix them with sellotape, tipex and a sharp pencil.

      --
      I'm out of my tree just now but please feel free to leave a banana.
  10. next version will do the kernel by grover · · Score: 5, Informative

    ...because this is the first question everyone asks as soon as they find out Intel's compiler works on Linux. ;-)

    I'm not surprised the compiler helped Crusoe. GCC is a remarkable achievement in portability, but architecture-tailored compilers (MSVC, ICC) do better both in terms of code size and speed - like 30% better. But if you're going to PAY for your compiler, it better not be beaten by a free alternative.

    I hope we see distros using icc, and I also hope it spurs further development in GCC.

    1. Re:next version will do the kernel by Anonymous Coward · · Score: 2, Informative

      Please stop saying that MSVC generates code that runs faster than GCC generated code - it just ain't so.

      I've compared MSVC 6.0 on Win32 to Cygwin's port of gcc 2.95.3 (with the -mno-cygwin switch, so gcc generates native win32 executables).

      The gcc generated stuff consistently runs faster. Ballpark 20% or more IIRC - I don't have the figures handy. These were on real world compute intensive programs that I use at work, not artificial benchmarks. And yes, I had full-tilt optimization on both compilers.

      While I don't doubt that gcc optimization could be improved further, and should be, my biggest complaint is often that the compiler itself runs slowly (particularly for C++).

    2. Re:next version will do the kernel by Anonymous Coward · · Score: 0
      While I don't doubt that gcc optimization could be improved further, and should be, my biggest complaint is often that the compiler itself runs slowly (particularly for C++).

      Recompile gcc using icc then! That will speed it up no end....

      Can you compile gcc using icc?

    3. Re:next version will do the kernel by mandolin · · Score: 2
      Can you compile gcc using icc?

      I haven't tried it (..that should be a new acronym..) but it should Just Work. The gcc codebase is conservative in this regard. It is written to be bootstrapped by different, older (pre-ANSI C) and sometimes quite buggy compilers. See gcc/README.Portability in the latest gcc source tarball for details.

      Now, can you use gcc to *compile* icc?

    4. Re:next version will do the kernel by Panaflex · · Score: 2

      It does on alpha.. but I'm not sure if that version of MSVC came from digital->compaq->hp or not??

      Nonetheless... gcc doesn't far well on alpha chips.

      Pan

      --
      I said no... but I missed and it came out yes.
    5. Re:next version will do the kernel by ksheff · · Score: 2

      That's because there are more people working on the Intel optimizations. It's also worth noting that some people heavily involved with the development of gcc have said there are some optimization techniques that they would like to implement, but can't because they are currently patented and are waiting for the patents to run out.

      I've always heard good things about Digital's Alpha compilers. When the Alpha division of H-Paq finally takes a dirt nap, it would be nice if they could GPL the Alpha optimizations for inclusion into gcc.

      --
      the good ground has been paved over by suicidal maniacs
    6. Re:next version will do the kernel by Chep · · Score: 1

      Read the damn INSTALL file of gcc. You'll have a perhaps very fast bootstrap compiler, but later phases will be compiled with gcc itself, so you'll end up with the exact same binary as before.

    7. Re:next version will do the kernel by mandolin · · Score: 1
      Read the damn INSTALL file of gcc.

      You misinterpret.

      1) I've done this dead project. If you knew what it took to get that, with a native *solaris* GNAT compiler as the starting point, you'd know that I've read the INSTALL file.

      2) I was only making the point that it should be possible to bootstrap gcc with icc, not that the final product would be any faster.

      3) If you are a speed freak, you should be able to kludge up a true icc-compiled gcc from the stage1 bits that the build process (normally) leaves lying around. I've done similar for '1)'.

    8. Re:next version will do the kernel by Chep · · Score: 1

      1) oh, I didn't see that. Huh.

      2) oh, huh. <blushing/> should have read better.

      3) yes (but I'm more a lazyness than speed freak; besides I don't really use that many P4's)

      All in all, I owe you an apology for not having read correctly your post. Please accept it !

    9. Re:next version will do the kernel by mandolin · · Score: 1

      Hey, it's all good...

  11. screw the kernel, recompile the system libraries! by brer_rabbit · · Score: 5, Insightful

    I wonder if Intel's compiler is binary compatible with gcc. While it's probably against the licensing to redistribute the compiler's math or C library, I wonder if you could compile the gnu math/C library with icc and produce a shared object? An optimized math or other system library would give some decent improvement in performance.

  12. This is very interesting. by Anton+Anatopopov · · Score: 3, Interesting
    It seems as if Intel is playing a very clever game here. If Intel can unlock the true potential of the transmeta's code morphing architecture, then they are giving it a great deal of credibility in the industry.

    Given that Intel makes a lot of its money from selling silicon, why on earth would it develop compiler technology which legitimized the approach of one of its major competitors ?

    I can only assume that Intel has some fairly advanced code morphing technology of its own, and has been using the transmeta devices as a testbed.

    I can just see it now, a 4GHz pentium with code morphing extensions.

    I expect this one will be fought out in the patent arena. IBM and Intel are heavyweight players and I don't see either of them giving any ground willingly.

    1. Re:This is very interesting. by tonywong · · Score: 1

      I doubt if this has much to do with Transmeta from Intel's standpoint. If anything, I'd suspect these optimizations are geared more towards some kind of funky x86-32 implementation under McKinley IA-64.

    2. Re:This is very interesting. by hexix · · Score: 4, Insightful

      I think you're reading more into this. I think it's more like intel released a compiler to generate better optimized x86 code for it's processors. And since transmeta does code morphing from x86 to whatever it's instruction set is, a side effect from better optimized x86 code would be faster code morphing of that better optimized code.

      You make it sound like it only improves transmeta's chips and not others. I really doubt that's what's going on here.

    3. Re:This is very interesting. by p3d0 · · Score: 2

      Actually, the P4 has a Trace Cache which smells something like embryonic code morphing. Clearly it is not nearly as powerful, in terms of optimizations, but it seems a future Pentium (or even the Itanium) with code morphing is not out of the question.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    4. Re:This is very interesting. by Anonymous Coward · · Score: 0

      its not it's. please!

  13. Re:Bukkake, the return! by marauder · · Score: 0, Offtopic

    If only you had spelled the search term correctly. A winnar is not you!

  14. archenemy by Anonymous Coward · · Score: 2, Insightful

    how is intel the 'archenemy' of us... just because Linus works at Transmeta? What chip are you running your OS on? I bet its an Intel chip, or an intel-clone (AMD)

    /me is wintel-free, yay Mac

    1. Re:archenemy by basking2 · · Score: 1

      Maybe arch-enemy isn't the best word for it (unless I"m mis-reading interpretting the political banter between the two).

      Trans-meta makes a chip that supports the x86 architechture using code-mophing which is very VERY similar to micro-coding. It's acctually not a "new" idea, but it's a new method of an old idea which was a clever implementation of an older idea (the micro-code thing again).

      Anyway, the bone of contension with Intel and Transmeta (as far as I understand it to be) is that Transmeta is shooting for an x86 architecture that is lowpower and quick. Low power is key because of embedded systems (which are growing fast, particularly with Linux as a foundation OS) and laptops just don't match the battery life I get from my G3 (hehehe. /me wintel free too. :-) )

      Anyway, they both are shooting at the same market. Transmeta is touting power-savings (which if they can show moderate performance, makes them very tempting), especially in the new and upcoming wave of embedded systems. Why x86 ISA? Well, I guess it's because taking on Moterola isn't a smart idea with their already RISC chip ISAs and already VERY good power consumption.

      As a side note, a lot of people would like to se the x86 architechture quietly dissappear because of hardware issues. Not "problems" but just bottlenecks and general house-cleaning has to be done before we have another VAX. :-) Well... it's not THAT bad... but it's a little ugly.

      --
      Sam
    2. Re:archenemy by Brian+Stretch · · Score: 2

      What chip are you running your OS on? I bet its an Intel chip, or an intel-clone (AMD)

      If the Athlon was an Intel clone, it wouldn't kick the P4's ass.

    3. Re:archenemy by jrockway · · Score: 1

      > What chip are you running your OS on? I bet its an Intel chip, or an intel-clone (AMD)

      Nope, G3/233 :)

      --
      My other car is first.
    4. Re:archenemy by Cato · · Score: 2

      Read the slashdot post - it referred to 'Transmeta's arch nemesis, Intel' (not enemy). Nowhere did it say anything about either of them being 'our' enemy...

    5. Re:archenemy by Anonymous Coward · · Score: 0

      Intel is the archenemy after reading in various places how and what it wants to do to compete, er, ...grind into the ground, AMD.

      If worse comes to worst, I could almost see the Intel board freeing up a few billion $ in cash to buy up MoBos/buy off Mobo makers that use AMD processors. Why not buy the processors themselves? What use is a CPU w/o a mobo, and AMD doesn't make many/any Mobos, so if you buy the MoBos with those billions, they aren't gonna go to AMD. That would be the most direct approach.

      Intel will continue to put pressure on companies that build Mobos for both P4 and AMD (think: VIA)
      to go Intel.

      But I know that, 'cept for the P3-SM (the one with 512kb cache), I probably won't buy another Intel-based system.

      For those who live in the Illinois/Wisconsin area, Aldi stores is gonna start selling PCs (that, although P4-based, look...interesting... but the flier in the Chicago Tribune didn't have a price. If it's $300 for the system... Aldi is the grocery store for the "poor")

  15. KDE performance by joshua42 · · Score: 2, Insightful

    Just a thought: Might this compiler perhaps be different in a way that improves the situation regarding the C++ library relocation issues that bothers KDE?

    --

    - El riesgo siempre vive - Private J. Vasquez
    1. Re:KDE performance by hexix · · Score: 3, Interesting

      I was wondering the same type of thing. Is this going to be helpful to KDE in any way?

      It's my understanding that the problem is with the gnu library linker, but I don't know much about compilers. Does this intel compiler have it's own library linker or does it still use the gnu one?

      If it does use it's own can we expect to see dramatic speed increases if we were to compile KDE with this intel compiler?

    2. Re:KDE performance by Anonymous Coward · · Score: 0

      it can't be using gnu linkers, otherwise it would be free.

    3. Re:KDE performance by be-fan · · Score: 2

      No, it uses the standard GNU linker. It exports a standard ELF program that ld.so links at runtime. However, you couldn't really use it with KDE anyway. Intel C++ has a different C++ ABI than G++ (the C ABI is of course the same) and thus can't link with G++ compiled libraries. Lastly, KDE doesn't even compile with icc yet. Look at this thread on kde-devel.

      --
      A deep unwavering belief is a sure sign you're missing something...
    4. Re:KDE performance by Anonymous Coward · · Score: 0

      Relocation issues? You mean like when you run a C++ program linked against another library version, and it says "relocation error: symbol [C++ mangling]"? That's a C++ ABI thing. It's no less relevant on any other compiler.

    5. Re:KDE performance by joshua42 · · Score: 1

      Nope. Check out dot.kde.org/989353453/.

      --

      - El riesgo siempre vive - Private J. Vasquez
  16. Kernel by Old+Wolf · · Score: 2, Redundant

    Why don't they use ANSI C for the kernel?

    1. Re:Kernel by be-fan · · Score: 4, Informative

      Because Linux is a real project and not some theoretical programming plaything. Kernels have all sorts of weird problems to deal with (passing parameters via registers, inline ASM, structure packing, alignment, etc) that normal application code doesn't have to bother with.

      --
      A deep unwavering belief is a sure sign you're missing something...
    2. Re:Kernel by Anonymous Coward · · Score: 0

      Passing parameters to and from ASM and C/C++, as well as inline ASM is something that ten minutes of reading can teach you. There's really not that much to "worry about"

    3. Re:Kernel by Anonymous Coward · · Score: 0

      Get a longer attention span. The OP was asking about using ANSI C, which doesn't talk about assembly at all. The response was mentioning that you can't just write a kernel that's strictly conforming (to the C standard). Your response is, well, I don't know. Clueless? Yeah, that about fits it.

    4. Re:Kernel by Anonymous Coward · · Score: 0
      Why don't they use ANSI C for the kernel?

      "No interesting program can be written in ANSI C".

      Look: what are the ANSI C functions for setting up the virtual memory page tables, for changing context with all registers, handling a processor-based exception, doing i/o with peripherals, flushing microprocessor cache ?

    5. Re:Kernel by Anonymous Coward · · Score: 0

      The kernel is written in C++?? No wonder it's so slow. Yep, the Linux kernel is just another ordinary program that's also slow.

  17. Ummm... Price? by Erioll · · Score: 1, Interesting

    I'm suprised I haven't seen anyone else post this. Intel's compiler is EXPENSIVE! $499? I think since most programmers are not exactly rich (Gates excluded), I think most Linux people are not going to exactly embrace this new compiler.

    $500? I paid less than that for my MS compiler!

    Erioll

    1. Re:Ummm... Price? by Anonymous Coward · · Score: 0

      $500 is not much for a compiler--especially if you're using it for production work. Anyway, if you're going to gripe about cost, look at what Office costs! There are more people out there who use that than C compilers. How did you think MS made a good chunk of their change?

    2. Re:Ummm... Price? by Mr.+Piccolo · · Score: 2, Informative

      Sun's compilers cost $2000 if you want C++...

      --
      Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
    3. Re:Ummm... Price? by cb0y · · Score: 1

      Big deal, anyone making software that they will SELL, will BUY it.

    4. Re:Ummm... Price? by Anonymous Coward · · Score: 0

      Oh, I'm sure that as a result of this story, you can download it from Gnutella now.

    5. Re:Ummm... Price? by be-fan · · Score: 2

      Its really not that bad. Its free for non-commercial use, and $500 isn't much for a development tool in a pro shop. Perforce licenses, for example, cost $600 per developer. There is this guy who writes programming tips-type articles (look around on /., sorry I don't remember the name). He makes the very good point that good developer tools are a drop in the bucket for the return they give in productivity.

      --
      A deep unwavering belief is a sure sign you're missing something...
    6. Re:Ummm... Price? by Anonymous Coward · · Score: 0

      Intel does offer a non-support version for free, goto download if you want. It is restricted to do freesoftware work!
      http://www.intel.com/software/products/eval/

    7. Re:Ummm... Price? by be-fan · · Score: 2

      Umm, you don't even have to do that. You can download it from Intel.

      --
      A deep unwavering belief is a sure sign you're missing something...
    8. Re:Ummm... Price? by Anonymous Coward · · Score: 0

      $500 is cheap compared to many other tools. A guy at work wants to get some UML/Java super IDE, unfortunately for 10 floating licenses it's something like $100K.

  18. Not surprising by d5w · · Score: 3, Interesting

    This isn't a particularly startling result. Many of the things an x86 compiler has to optimize for these days are similar across all processors: e.g., regular branch patterns are faster than unpredictable ones; you have very few visible registers; it's helpful to have closely associated data in the same cache lines; you're usually better with the RISCy subsets of the ISA; etc. Intel would have had to go well out of its way to optimize for their own chips and pessimize for others, and I can't see Intel bothering.

  19. Expectations by Anonymous Coward · · Score: 0

    Yes, Very interesting! I hope that in the future the Crusoe will meet expectations :)

  20. Clarifying The Comments by robbyjo · · Score: 1

    That's what I have said. My point was that the 28% gain is basically on-par with P4. Athlon gains weren't too shabby either. Meanwhile, we understand that current Crusoe performance is pretty dismal compared to P4 or Athlon. So, 2% difference on performance gain doesn't mean that Crusoe performance is now leveraged into a new level.

    If it were compiled into its native, we then can see Crusoe's raw power and compare them neck to neck. The story would have been much different.

    Note also that I am not a revisionist. I believe Slashdot community is intelligent enough figuring out what I said.

    --

    --
    Error 500: Internal sig error
  21. Here's another news flash by kijiki · · Score: 4, Insightful

    Intel's compiler boosts AMD Athlons too.

    AMD uses (or at least, used to use, I haven't checked lately) Intel's compilers for their SPEC runs.

    Intel's compiler is the best available for CPUs that implement the x86 ISA. Transmeta implements that ISA, so why does this news surprise people?

    1. Re:Here's another news flash by basking2 · · Score: 2, Interesting

      Optimization for a compiler is directed at chip-generation, not necessarily ISA's. Remember that FU latencies are the big problem in the pipeline, and since Transmeta is a RISC, this is kinda neat! :-)

      --
      Sam
    2. Re:Here's another news flash by Anonymous Coward · · Score: 1, Informative

      Transmeta is NOT RISC, it is VLIW with a x86 to VLIW optimizing translator.

    3. Re:Here's another news flash by basking2 · · Score: 1

      Doh... thanks (and sorry to those the previous post mislead)!

      --
      Sam
    4. Re:Here's another news flash by Anonymous Coward · · Score: 0

      AMD uses (or at least, used to use, I haven't checked lately) Intel's compilers for their SPEC runs. (Score:1, Redundant)

      It looks like the jackbooted AMD fanboy moderators are gunning for this one, as it the only post that mentions this fact.

      Guess some folks can't handle the truth -- That AMD is a big fat IP leech.

    5. Re:Here's another news flash by Anonymous Coward · · Score: 0

      Yep, even AMD uses the intel compiler v5.0.1 for itsSPEC 2000 Athlon MP 1800+ benchmarks.

    6. Re:Here's another news flash by _Bean_ · · Score: 1

      The suprise was that Transmeta gained a bigger performance increase than the P4 or the athlon.

    7. Re:Here's another news flash by Anonymous Coward · · Score: 0

      How exactly does this make AMD an IP leech? AMD makes processors, not compilers. Why not use the best compiler for the instruction set? Since Intel sells the compiler, maybe AMD is advertising for them.

    8. Re:Here's another news flash by Anonymous Coward · · Score: 0

      AMD makes x86 CPUs under licence from Intel. The Transmeta results are more interesting because they are clean design with no Intel IP. (Although both AMD and Transmeta are seem to be optimizing for the common case of P6-compiled code, where Intel is betting on recompiled apps with the P4. If/When AMD goes their own way [hammer], they'll need to hire some compiler people.)

  22. This also reeks of Apple Photoshop benchmark stuff by Anonymous Coward · · Score: 0

    It's been shown to be slow(er) on all the other useful stuff except for this one particular task.

    Yawn. Wake me when they've sold off the IP.

  23. Gcc, performance by Bert64 · · Score: 1, Insightful

    GCC has never been an especially performant compiler, on sparc/mips/alpha atleast, the vendor compilers are CONSIDERABLY faster than gcc, it really sickens me to see programs which use nonstandard features of C that refuse to compile on anything other than gcc. Perhaps the gcc team should work more on generating more optimised output, and less on adding nonstandard features..

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    1. Re:Gcc, performance by isj · · Score: 1

      > the vendor compilers are CONSIDERABLY faster than gcc

      Not always. Last time I checked Sun's Workshop compiler wer about twice as slow as gcc. gcc was far better at allocating registers while Workshop was better at inlining functions.

    2. Re:Gcc, performance by Hast · · Score: 1

      As was mentioned above, a lot of the newer optimizations used in the "big" compilers are patented. So there's not really all that much the GCC team can do.

      And BTW, these non-standard features are well documented and available for all other compiler writers to implement.

  24. probably binary compatible or close by kingdon · · Score: 3, Informative

    There shouldn't be a lot of problems for binary compatibility with C (e.g. glibc, libcurses, X libraries). (Famous last word is "should" so unless someone does some testing and reports the results, take with a grain of salt). For C++, it gets a bit murkier. The Intel page has a section called "Compatibility with the GNU Compilers". They refer to the C++ ABI that was developed for Itanium, which I believe is basically the same ABI as GCC 3.x (it has mangled names which start with _Z). When they say they aren't compatible with g++, I suspect they mean g++ 2.95.x and maybe even 3.0 or 3.0.1, I'm not sure that sentence applies to 3.0.2 or (certain unspecified) future releases of 3.x.

    1. Re:probably binary compatible or close by brer_rabbit · · Score: 2

      I wasn't really expecting C++ compatibility, name mangling is typically compiler specific. C compatibility shouldn't be terribly difficult to maintain. Of course, it either works or it doesn't.

    2. Re:probably binary compatible or close by be-fan · · Score: 3

      From what I've heard, yes it is 'C' compatible. Of course, you can't compile a lot of system libs with it anyway, because glibc, for example, uses GCC extensions. Generic stuff like math libs should be doable, but aren't very widely used in a system. X (since it is good about different compilers) would be the really interesting test case, maybe I'll try this weekend.

      --
      A deep unwavering belief is a sure sign you're missing something...
    3. Re:probably binary compatible or close by Milican · · Score: 2
      Well if the compilers are indeed different that is still ok. C can read fortran objects as well. With a few changes in the way you write code you can link in objects from other compilers as long as you follow a few rules... so here are some refs..



      Enjoy :)

      JOhn
    4. Re:probably binary compatible or close by Isle · · Score: 1

      Compile KDE.. Just remember to compile ALL the C++ (e.i. qt) libraries with same compiler..

      I wont believe the results..
      (On non-x86 using a native compiler usually gives around x2-x10 faster application launch.)

  25. You still don't get it by smileyy · · Score: 2, Flamebait

    Crusoe does cool things because it runtime optimizes the code that it is morphing. If you were to run crusoe code natively, you'd no longer get the optimization benefits, and all you'd be left with is an even slower low-power chip.

    Theoretically, you could write a Crusoe-to-Crusoe code morphing module, but that wouldn't buy you anything more than the X86-to-Crusoe morpher.

    --
    pooptruck
    1. Re:You still don't get it by Anonymous Coward · · Score: 0

      they *claim* they do runtine optimizing. Do you have *any* numbers or data that back that claim up?

      I find it hard to believe an optimizing emulator would run faster than native instructions (and I'm well aware of HP's optimizing run-time work).

    2. Re:You still don't get it by robbyjo · · Score: 2, Informative

      Well, code morphing itself does not worth the performance. For example, let's compare Intel Celeron vs Crusoe with the same speed. I doubt that Crusoe can even beat Celeron, even with the super-optimized morphing that has run for months.

      The problem here is that no matter how good is the morphing, it is still "emulation". You can do morphing or maybe mixed with dynamic recompilation, you cannot beat the real stuff that run natively. There are lots of examples.

      The real power of Crusoe processor is that it is a VLIW processor, which can jam-pack several instructions into one. *This* is the real power. Notice that P4 adopt this solution too (3 instr to 1). Intelligent compiler can arrange the machine code so that the instruction bundles are used very efficiently. Now, let's say that Crusoe has 32-bit instruction wide and it has 128-bit. Theoretically, you can jam-pack 4 instruction at once, thus yielding 4 times the MHz rate. *This* is what I really want to see.

      About the power problem: I really pessimistic about processor power that can prolong battery life n times (with n > 2), as claimed by Transmeta. IIRC, *the* major power drain is at LCD and hard drive. If those bogger are attacked, I wouldn't have been surprised that the battery life would be prolonged. But, let's recall that before Crusoe came, P3 processor only consumes about 2W. How many portions was that to the total laptop consumption? Now, Crusoe reduce that into a mere 1W -- and *that* was claimed as *the* dramatic power saver. I smelled rat.

      I don't want to attack your "belief" as Crusoe adherents, but please understand the underlying problem before you answer.

      --

      --
      Error 500: Internal sig error
    3. Re:You still don't get it by egomaniac · · Score: 2, Informative

      I find it hard to believe an optimizing emulator would run faster than native instructions (and I'm well aware of HP's optimizing run-time work).

      Java's HotSpot compiler beats out traditional C/C++ code on a number of benchmarks.

      --
      ZFS: because love is never having to say fsck
    4. Re:You still don't get it by Ozx · · Score: 1

      The person that moderated you off topic needs to spend time devising a mechanism to add mod points to their IQ...

    5. Re:You still don't get it by rabidcow · · Score: 1

      Crusoe does cool things because it runtime optimizes the code that it is morphing. If you were to run crusoe code natively, you'd no longer get the optimization benefits, and all you'd be left with is an even slower low-power chip.

      Hmm, crusoe basically has a fast x86 to crusoe optimizing compiler built in. If you compiled to native crusoe ahead of time, you could spend more time on the optimization. (as I believe the crusoe does for instructions used more frequently)

      Since a regular compiler compiling to native code has more time available, it is always possible to produce faster code with it. (more time to try/think about different optimization methods) Not to mention the question of whether or not you have to recompile next time you run the program.

      Not that this means existing compiler techniques could necessarily do a better job (tho I would assume that's likely), but since you don't give any time limits, neither will I :)

    6. Re:You still don't get it by Hast · · Score: 1

      Regular compilers have more time, but they have neither the available memory nor the accurate statistics that a run time compiler/optimizer has.

      If the Transmeta Code morphing engine discover that a particular FOR loop is running a lot then it can unroll it to a sequence. This is prohibitive in a normal compiler because it would result in much larger exe files.

    7. Re:You still don't get it by stripes · · Score: 2
      Well, code morphing itself does not worth the performance. For example, let's compare Intel Celeron vs Crusoe with the same speed. I doubt that Crusoe can even beat Celeron, even with the super-optimized morphing that has run for months.

      That doesn't mean code morphing is a bad idea. It means at least one of the following is true:

      • The celeron is had better designers
      • Celeron designers had more resources to work with (time, money, people)
      • Celeron and Crusoe had different design goals
      • Code morphing is a bad idea
      • Code morphing is only a good idea when combined with something we haven't tried yet

      If you look at the history of the RISC CPUs the IBM ROMP was not very fast when it first came out. As I recall that was the first commercial RISC design. It didn't mean RISC was a bad idea (RISC in fact stomped CISCs butt soundly during the first half of the 90s, and I'm not sure the most recent x86 has beaten the cold dead Alpha's corpse...and the Power4 seems a whole lot faster...). The ROMP was slow because it wasn't the best design. I think the big problem was it's MMU. They did manage to fix it up, but I don't think it got a whole lot faster then the 68020 for a long time!

      I'm not saying code morphing is great either, just that a commercial failure is hardly a scientific experiment.

      The real power of Crusoe processor is that it is a VLIW processor, which can jam-pack several instructions into one. *This* is the real power. Notice that P4 adopt this solution too (3 instr to 1).

      And the PIII did 2 instructions, the AMD K7 did three, and RISCs have been doing 4+ for a long time. As far as VLIW goes 4-way is pretty low. The most interesting things that (seem) to be in the real Crusoe are the split load and split store (they can start a load, and later decide to complete it -- taking a fault if need be, or abort it; similar with stores, they can be queued and later canceled).

      I really pessimistic about processor power that can prolong battery life n times (with n > 2), as claimed by Transmeta. IIRC, *the* major power drain is at LCD and hard drive.

      I am too, but on my notebook (an older G3 PowerBook) the batt monitor shows about 4 hours with the LCD on high and minimal CPU use, it shows 4.5 when I put the LCD on max dim (almost unreadable in a room with 60watt bulbs, ok with no light in the room). Leaving the monitor on dim and running a tight loop the batt time drops to around three hours. Leaving it going until the fan (tempature sensitive) kicks in and the batt time drops a bit more.

      So I would say the CPU can use more power then the backlight. No, not quite, the swing from minimal CPU use to max is more taxing then the swing from minimal backlight to max. The no backlight to min may be a bigger swing then no CPU to minimal CPU.

      That's not to say the Crusoe can magically turn a one hour batt to six hours, but it might get one hour to two.

    8. Re:You still don't get it by rabidcow · · Score: 1

      Regular compilers have more time, but they have neither the available memory nor the accurate statistics that a run time compiler/optimizer has.



      Currently existing compilers, and statistics will always be more accurate for run time optimization, but who's to say some of that can't be done ahead of time?



      And since when does anyone worry about larger exe files?

    9. Re:You still don't get it by aanantha · · Score: 1
      Currently existing compilers, and statistics will always be more accurate for run time optimization, but who's to say some of that can't be done ahead of time?

      Compilers make optimizations when code is compiled to machine language. A run time optimization is an optimization that is made dynamically when the code is run. So how can a compiler be more accurate at run time? It's not there at run time!

      And since when does anyone worry about larger exe files?

      Think about a loop that has a hundred iterations. If you unrolled it all the way, you have one hundred times more code. Compilers obviously don't do that. After you unroll a few times, you stop getting any more benefit. Larger executables mean more memory usage and memory accesses take forever. It makes a guess about how many times they should bother unrolling it. They unroll maybe 5 times at most. But a compiler can't make a perfect guess because the time it takes to execute some code are often dependant on runtime conditions. The number of loop iterations might be based on a value a user inputs in. The compiler has no idea what value the user will input. Also, the time to access a piece of data in memory varies depending if it's in cache, memory, or paged to disk. These things will only be known at runtime.

    10. Re:You still don't get it by rabidcow · · Score: 1

      So how can a compiler be more accurate at run time? It's not there at run time!

      No, but it could run/emulate the code to profile it while compiling. Not likely, but possible. (and not quite as good since you wouldn't have actual input values, but simulated values can be used)

      Unrolling a 100-iteration loop will have nearly the same drawbacks either way. When you unroll the loop has no effect on the size of the cache. Sure, you can make more intelligent decisions based on cache size, but I'd think the gain from that would be negligible. (If you've already unrolled 25 iterations, what percentage of the cycles do the loop instructions take?)

      As for increased exe size/memory acess time, you'd probably be better off with a dumb compression algorithm. Something that takes very little time to decompress. (this could make loop unrolling very cheap)

      I'll concede that there are optimizations that can only be done once you know the final system/user input, but a lot of the translation could be done by the compiler, and would result in faster execution time.

    11. Re:You still don't get it by Anonymous Coward · · Score: 0

      There are actually compilers that will compile a program with branch logging in the code. Then you run the program throught a standard workload, saving the branch statistics to a file. Then you recompile the program feeding the statistics file to the compiler for it to improve its optimizations.

      The Microsoft Software Development kit lets you do this. I am sure other compilers also do this.

  26. duh, you're using the wrong gcc flags by Anonymous Coward · · Score: 2, Interesting

    You're benchmarking an intel compiler which will generate optimized intel code, but telling gcc to use "-m386" ?

    You have an 80386 machine here secretly? Why not use the optimized flags like "-mcpu=i686 -march=i686" and give a fair comparison?

    Am I the only one to see this? C'mon people, wake up, read the manual.

  27. Wrong... by Carnage4Life · · Score: 5, Informative

    What if, besides caruso, Intel's compiler is actually a BETTER compiler than gcc on intel hardware? Then were stuck using gcc for compiling the kernel when something better is or might be some day available. . Locking the kernel to a compiler is a BAD THING[tm].

    The Linux kernel is not only available on Intel chips. It is available on ARMs, DEC Alphas, SUN Sparcs, M68000 machines (like Atari and
    & Amiga), MIPS and PowerPC, as well as IBM mainframes.

    Which makes more sense? Targetting a cross plartform compiler like gcc are targetting individiual compilers for each platform Linux runs on?

    1. Re:Wrong... by Nater · · Score: 2

      I believe the gist of his argument is not that the kernel should be tied to some other compiler instead of gcc, but rather to the language spec, so that any standards compliant compiler should be able to compile it.

      --

      I like to play children's songs in minor keys.
      "We're all sons of bitches now." --J. Robert Oppenheimer

    2. Re:Wrong... by mvl · · Score: 1

      So how do you do "atomic add" with just what the C standard offers you? On i386, you write

      static __inline__ void atomic_add(int i, atomic_t *v)
      {
      __asm__ __volatile__(
      LOCK "addl %1,%0"
      :"=m" (v->counter)
      :"ir" (i), "m" (v->counter));
      }

      Just tell me how to write this in plain C.

    3. Re:Wrong... by Nater · · Score: 2

      I didn't say that I agreed with the comment, I was merely pointing out to Carnage4Life the fact that he had probably misinterpretted it... I know that you can't do that in straight C.

      --

      I like to play children's songs in minor keys.
      "We're all sons of bitches now." --J. Robert Oppenheimer

    4. Re:Wrong... by Lars+T. · · Score: 1

      Let's see, the dependance of the kernel on gcc is okay, since gcc is also cross platform - but one big use of gcc extensions in the kernel is for inline assembler? How does that go for portability?

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

    5. Re:Wrong... by Anonymous Coward · · Score: 0

      There are a lot of things you just can't do in C. That requires inline assembly.

      All the architecture-dependent code goes in arch/whatever (ex: arch/i386, arch/alpha ...) You will not find any inline assembler outside of arch/, and the code in arch/i386 for example, will not be compiled for any target other than x86. Make sense?

    6. Re:Wrong... by benedict · · Score: 2

      That's easier said than done. As soon as you want to do something that's not supported in the language spec, you have to pick a compiler.

      --
      Ben "You have your mind on computers, it seems."
    7. Re:Wrong... by benedict · · Score: 2

      The assembler tends to show up in parts of the source that have to be machine-dependent anyway, like boot code, device drivers, and the md part of memory management.

      --
      Ben "You have your mind on computers, it seems."
    8. Re:Wrong... by Anonymous Coward · · Score: 0

      Don't forget interrupt handling.

  28. What?! Are you daft?? by Anonymous Coward · · Score: 0

    Why not?

    Because if Ashcroft and the jackbooted thugs who gave him a lift into Washington make Gnu illegal because it's free for destitute Afghan Evil Doers, Linux is more fucked than ever.

    Get with the totalitarian program, it isnt an electoral option, it's the law.

  29. Re:Uh... Sleep Good. by strangemoose · · Score: 1
    I really should het more sleep before posting... (I previewed it even...)
    the macro should be:
    #define useless_macro(a, b...) ({ printf(a, ##b); })
    --
    Sig? What sig?
  30. What about Fortran! by Anonymous Coward · · Score: 0

    The really big news is the intel
    fortran compiler for linux. Finally
    a fortran compiler that doesnt suck,
    and it's free under non-com license.

    The sad thing is I can't get it
    working under FreeBSD4.0. Just
    added a linux machine to my network
    for the compiler alone. Pretty
    damn excited about it, far better
    than Portland Group F90, and supports
    fortran95 extensions as well!

    It pisses all over g77.

    Anyone out there had success with
    the Intel fortran compiler on FreeBSD?

    Fortran Coder
    NOAA/NCEP/NWS

    1. Re:What about Fortran! by Anonymous Coward · · Score: 0
      It pisses all over g77.

      Um, does this mean that code compiled by the Intel compiler runs significantly faster than code compiled by the g77 compiler? Or do the Intel fortran compiler and g77 have one of those weird scatalogical relationships?

      If it's the former, can we please get a little less excited about this? I sense that you're pissing all over yourself.

    2. Re:What about Fortran! by Anonymous Coward · · Score: 0

      Indeed, the intel fortran compiler
      does piss all over GNU f77.

      Any doubts about this are easily
      resolved by consulting the G77
      manual, specifically:
      http://gcc.gnu.org/onlinedocs/g77_19.html

      Just a few highlights, and by the by, Intel
      fortran does have these features.

      -Not posix compliant
      -no fortran90 support
      -doesnt do byteswapio correctly
      -no openmp support
      -doesnt do pointers
      -no explicit asm code inclusion

      Check the docs, there are many many
      more. And from my own experience:

      -very, very bad optimizations
      -bad support of legacy fortran codes
      -bad compiler diagnostics

      Of course, it takes a real background
      in computational physics to appreciate
      these things, not just `linx dude, windoze
      sux.`

      Now if only there was FreeBSD support.

  31. Can Ximian use this? by glrotate · · Score: 0

    Has anyone tried compiling GNOME / mozilla with this thing? Binaries anyone?

  32. No kernel, so what? by labradore · · Score: 4, Interesting
    It seems that nearly everyone has missed the point of this article. POVRay is a program that makes very heavy use of the FPU. ICC speeds up POVRay's performance by 16% to 28% in the x86 architecture compared to GCC. In other words x86 FPU's are faster executing code from programs built with ICC. The Linux kernel (and almost any kernel for that matter) has very little floating point code. Therefore one cannot assume that ICC would improve kernel performance, even if it could compile it.

    The real story here is that the maintainers of GCC aught to look carefully at their optimization code for x86 FPUs.

    I'm betting that Intel developers have done their best to make use of the P4 cache. Since Transmeta CPUs do work recompiling programs on the fly they have larger caches (128KB L1 + 512KB L2) than the Athlon (128KB L1 + 256KB L2) and the Pentium 4 (20? KB L1 and 256KB L2). ICC is probably also highly agressive in implimenting SSE and SSE2 instructions. Transmetal CPUs also use VLIW instructions in core wich are by their nature highly parallel (compared to native x86). Even if the Transmeta chips can't use SSE and SSE2 they may benefit from the parallel-oriented optimizations that ICC probably makes.

    On a different note: in a program like POVRay that executes basically the same tight loop of instructions mega-gazillions of times during a scene the Transmeta chip's software can have the opportunity to highly optimize the program. I would like to see the stats on the second and third runs of that rendering to see how much the Transmeta "code morphing" improved the performance. It would be very interesting if the GCC and ICC built POVRays perfomed at almost the same speed after a few runs. It would obviously be a great proof of the value of Transmeta's design. I for one have always wondered what the code morphing stuff would be able to do if it were able to interface with the operating system and recompile and save the entire system back to the hard disk as it goes through the optimiztion processes. (I suppose that errors could be highly disasterous.)

    That's just my $0.02 and I'm no expert so I could definately be wrong.

    This is not a signature.

    1. Re:No kernel, so what? by Anonymous Coward · · Score: 0
      The real story here is that the maintainers of GCC aught to look carefully
      at their optimization code for x86 FPUs.

      The GCC maintainers know perfectly well that code could be much better optimized, and even how to do it. They are unable to because of software patents on code optimization algorithms.
  33. Re:screw the kernel, recompile the system librarie by malcy · · Score: 1

    You can not distribute (shared)objects, binaries etc made with ICC. Its plainly for you to play on your own machine, you can not redistribute anything produced by ICC regardless if its free or not. This is ofcourse my understanding of ICC's license (i havent read it in a while though)

  34. Re:The articles on Slashdot by Anonymous Coward · · Score: 0

    It was posted because Linus the Linux Loser works at tankmeta!

  35. Don't forget Fortran by BadBlood · · Score: 2

    As I type this, I'm downloading Intel's Linux Fortran compiler. While this is slightly off-topic, it will be interesting to see if this free (non-supported version) will compile some code I have that previously relied on Compaq/Digital Fortran's fort26.dll on the Win32 platform (not my code, honest :).

    If I can get it to compile on Linux, then I can do a whole host of things my employer previously thought impossible. :)

    --


    Praying for the end of your wide-awake nightmare.
    1. Re:Don't forget Fortran by Anonymous Coward · · Score: 0

      have you not tried gcc's f90 compiler?

    2. Re:Don't forget Fortran by mikefoley · · Score: 1

      Note that the Digital..er.Compaq Fortran group now works for Intel. They were the first to move over when Compaq gave up Alpha over the summer.

      --
      What's my Karma Mr. Burns? "Excellent"
  36. Re:20 gigs of movies!? by Anonymous Coward · · Score: 0

    All I see there is directory after directory named things like "Boys In Bondage" and "Hot Rimming Volume 6"

  37. What about gcc 3.0 ? by Stormie · · Score: 4, Interesting

    Interesting benchmark of Intel's compiler vs. gcc 2.95.4, but what about gcc 3.0? I'd love to see how that compared, given that I've heard such mixed opinions about whether it's optimisation tends to be better, worse, or the same as the 2.95 series..

    1. Re:What about gcc 3.0 ? by the+Atomic+Rabbit · · Score: 4, Informative

      From what I gather reading the mailing lists, GCC 3.0 was a features release, and 3.0.x were bugfix releases. There is generally very little performance benefit over 2.9.x (and the occasional performance regression.)

      GCC 3.1 will focus on optimization, building on the new infrastructure implemented with 3.0. If you're brave enough, you can pull from CVS and try it out for yourself.

  38. Re:KDE performance + some thoughts about compilers by boloni · · Score: 2, Informative

    That thread is from May. In the meanwhile, it seems that almost all the new KDE tree is compilable with the intel compiler (at least based on the cvs logs, I didn't check it myself).

    Now, for the expected performance increases. If I am correct, the intel compiler is the old KAI C++ compiler, which was highly regarded in number crunching circles as the best optimizing, more standard compliant compiler around.

    Still, the spectacular increases occur only in very specific cases which are amenable to optimization. Number crunching (big math computations) are the best example, and this applies probably to mp3 encoding, divx playback and compression, image processing and other stuff like this, too. But for your average, highly heterogenous code which goes into your typical desktop apps, the increase is significatly smaller.

    Lotzi

  39. Re:My hovercraft by Anonymous Coward · · Score: 0
    MY NIPPLES EXPLODE WITH DELIGHT!!!!

    heh heh heh. that skit is elite.

  40. iverilog by heroine · · Score: 2

    gcc has gotten so far behind the specialized instruction set curve that you're better off writing hardware descriptions for an FPGA using iverilog than spending $500 to write useful software for a modern instruction set.

  41. Re:HELP!! by Anonymous Coward · · Score: 0

    Thanks for your help!!! I knew I came to the right place!!!

    I know what you mean about sysadmins too. At my work there is a guy who is the sysadmin. He uses UNIX. He's a really weird old guy with a long scraggly beard. When I asked him about Linex he asked me to come into his office. He didn't talk about Linex though, he just looked at my bum and rubbed his private parts. What a freak!!

  42. Licensing loophole ($$$) by digitalEric · · Score: 2, Interesting

    Actually, having read the license, I found the following loophole:

    . . . if you buy the compiler, you are allowed to distribute code that you compile with icc ;) Find someone who has paid for icc, and ask them nicely if they would compile something for you. No, it's not open-source, but you can distribute source code along with an optimized binary if you're so inclined.

    1. Re:Licensing loophole ($$$) by ameoba · · Score: 2

      ...and paying for a compiler licence would be peanuts for Redhat/Suse/Mandrake...

      --
      my sig's at the bottom of the page.
    2. Re:Licensing loophole ($$$) by benedict · · Score: 2

      Wouldn't it be interesting if SourceForge could negotiate license terms for use on its compile farms?

      --
      Ben "You have your mind on computers, it seems."
  43. Results not surprising by jgarzik · · Score: 5, Informative
    These are not surprising results. Even the gcc developers will admit that many general, not-architecture-specific optimizations done by commercial compilers are not performed in gcc. Most new CPUs, not just Intel CPUs, can benefit from a smarter compiler to take advantage of features like data prefetching, instruction bundling and pipelining, profile-based (feedback-based) optimization, data and control speculation, and much more.

    The gcc "open projects" page gives people a good idea of what remains to be done on gcc. The minutes of the IA-64 GCC summit are especially interesting and informative, because it gives a good idea of the current state of GCC and also what GCC needs to be a competitive compiler in the future.

    Bottom line: Do not be surprised when commercial compilers beat gcc performance. It's catching up, but it's still got a long way to go.

    GCC Home Page

    1. Re:Results not surprising by MrHat · · Score: 2, Funny

      The minutes of the IA-64 GCC summit are especially interesting and informative

      Was that a subliminal message?

    2. Re:Results not surprising by ksheff · · Score: 2

      And just think, ten years ago, the first thing one would do with a new Sun was install gcc on it because it was much faster than the compiler that you had to buy from Sun. Especially, if it was a M68K based machine. I don't think gcc was that much slower than the sparc compiler. It was slower than the MIPS compiler by quite a bit though.

      --
      the good ground has been paved over by suicidal maniacs
    3. Re:Results not surprising by Anonymous Coward · · Score: 0

      With that boldface, you should except some modpoints yourself MrHat -- it IS that easy.

  44. Optimized distribution? by Adam+Wiggins · · Score: 1, Redundant

    I wonder, would we see noticable speed increases if a major Linux distribution (say, Mandrake) were to build all of their binary packages using the Intel compiler? The usefulness of this compiler for the average Linux user seems questionable given that all distros come with a perfectly wonderful compiler (gcc), but a use like this seems like a shoe-in.

    Assuming, of course, that you would actually see any speed up. I wonder if any distro maintainers have bought the compiler and are rebuilding their binaries to compare execution speed, load times, and binary size?

    1. Re:Optimized distribution? by grover · · Score: 1

      A thought experiment: Would people use a distro that was 25% bigger and 25% slower?

      Tough call. People like their PCs to be snappy, but computers are so fast these days, does 25% really matter?

      All I know is that the Mozilla developers would *love* a 25% speed boost. Personally, I'd love it if kernel compiles were 25% faster.

  45. SGI's compiler by Anonymous Coward · · Score: 0

    What ever happened to SGI's IA64 compiler for Linux? Now we are left with Intel's and GNU's compilers (Intel's supports IA32 and IA64).

    1. Re:SGI's compiler by Anonymous Coward · · Score: 0

      It is now renamed (and still open source) as the Open64 compiler, and you can find it at sourceforge. The associated mailing list is
      pretty interesting, even just to lurk on.
      Intel are also soon releasing an open source
      research compiler for IA-64 called "ORC" (open research compiler) that should be pretty interesting. Its based on the original pro64 compiler form SGI I believe. Combine that with say the liberty tools (processor simulator tools) and
      you can play with these stuff all you like.

  46. Intel compiler specifically made to slow AMD? by Anonymous Coward · · Score: 0


    I am a novice here, so please be kind.

    What are the possibilities that Intel makes their compilers to compile code well for Intel CPUs, but specifically not for AMD CPUs? I do not just mean that they design the compiler to output what will run best on their own equipment, but was specifically made to run slower on AMD CPUs by design, but they forgot about other CPUs, like the Cyrix/VIA and Transmeta?

    Just a curious thought.

  47. Plagiarism, thy name is Trollificus! by Anonymous Coward · · Score: 0
  48. Can't a Transmeta run VLIW natively? by Bucky+Ball · · Score: 1
    I don't know much about Transmeta chips, but according to their web site:
    "The Code Morphing software is designed to dynamically translate x86 instructions into VLIW (Very Long Instruction Word) instructions for the underlying Crusoe hardware engine."
    Why not compile Linux and its apps directly to VLIW instructions?

    More generally, why not ignore the x86 and treat the Transmeta as its own architecture?
    I expect the Code Morphing hardware can be used for more than x86 compatibility.
    1. Re:Can't a Transmeta run VLIW natively? by Anonymous Coward · · Score: 0

      They tried it and it ran SLOWER. There is only a certain amount of parallelization you can exploit at compile time. This is also the reason with Itanic is n't doing so well at the moment, the compiler techonology is no where good enough at the moment, and may never be.

    2. Re:Can't a Transmeta run VLIW natively? by Bucky+Ball · · Score: 1

      I'll believe that its not as trivial as just compiling to the native VLIW, but there should be something closer to the native instructions that still allows run-time optimizations.

      To put it another way, if x86 didn't exist, and all you had was a Transmeta chip, would you really rediscover x86 as the optimal intermediary between C++ and the native VLIW?

    3. Re:Can't a Transmeta run VLIW natively? by Anonymous Coward · · Score: 0

      As far as I can recall, the VLIW stuff is hidden.
      You have to go thru the x86 layer.

  49. So, what about Apple's gcc and PPC optimization? by melatonin · · Score: 1
    I've always wondered about this. Apple had MrC, their super-optimizing compiler which they used for OS 9 and all of their other code. It's freely downloadable (in binary form), so you can use it yourself- but as I understand it, you have to update your code so that it works (I've never tried it, but I think it's mostly simple compiler incompatibilities). MrC was well known for giving apps a performance boost.

    OS X is built with Apple's version of gcc. That always bugged me. I mean, gcc's great and everything, but going from MrC to gcc doesn't sound like a great idea... I can see a number of reasons why they'd want to use gcc, but I don't think performance is one of them :(

    Does anyone know if Apple's gcc is pushing ahead in PPC optimizations? IIRC, their gcc's code base is pretty far apart from the main trunk.

    --
    Moderators should have to take a reading comprehension test.
  50. Slashdot: The Transmeta Press Releas News Wire by frankgxc · · Score: 1

    Are any of the slashdot "writers" or owners of OSDN investors in Transmeta? Is Transmeta an investor in OSDN? Yes, there is a preference to filter Transmeta stories. But why are there so many PR stories about this company listed on slashdot?

    1. Re:Slashdot: The Transmeta Press Releas News Wire by Anonymous Coward · · Score: 0

      Because of Linus. Duh.

  51. Re:screw the kernel, recompile the system librarie by psamuels · · Score: 1
    I wonder if you could compile the gnu math/C library with icc and produce a shared object?

    glibc requires gcc - and a relatively recent gcc at that.

    So - no, for the same reason you can't compile a Linux kernel with it.

    Yet. (I agree with the poster who said "probably by the next version icc will support at least some gcc extensions".)

    --
    "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
  52. Sound 'N Spell by alienmole · · Score: 2, Funny
    What if, besides caruso, Intel's compiler is actually a BETTER compiler than gcc on intel hardware?

    Another one who learned the pronunciation of "Crusoe" from the Gilligan's Island theme song!

  53. LINUX SUX by cmdrTacosBitch · · Score: 0, Offtopic

    Kelly had just finished the last summer cheerleading practice.She was the first
    girl in ten years to make the squad their freshman year. Several of the other
    cheerleaders were upset. Kelly wasn't concerned about their thoughts. She shyed
    away from others and had very few friends. She didn't believe in the clicks
    people got into. Kelly is one of the prettiest girls in school. Shoulder length
    reddish blonde hair, acute face with a small button nose, and always smiled.
    Breasts the size of small grapefruits with nipples same size as quarters. Flat
    slightly sculptured belly, slender waist, narrow hips, small plump butt and
    perfectly shaped legs. All wrapped into a 5'4" 115pds frame.

    After showering Kelly dried herself, as she went to her locker. She noticed four
    girls across from her locker talking and snickering. Kelly ignored them. After
    slipping her cotton bikini pantys on, she grabbed her bra. Somebody had cut the
    straps. There was no way she'd be able to wear it now. She turned around to
    confront the now, laughing girls. They quickly walked out of the lockeroom.
    Kelly put on her low cut tank top, and shorts. After throwing her stuff into her
    bag, she headed out. Her breasts stood just as if she had a bra on. Her breasts
    firmly jiggled as she walked to the bus stop. Kelly was headed downtown to the
    library first. Then to a movie.

    Kelly had noticed lately that boys as well as men were looking her over as she
    walked by. Today more so than ever. After she got off the bus downtown. She went
    to walking the 4 blocks to the library. When a old black man walked out of a
    alley. Hey there. Where you headed? (shyly and quietly) Oh, hi. I'm going to
    have lunch with my dad. Kelly walked a little faster. She didn't notice that the
    old black man was following her. Kelly went into the library and looked over a
    couple of books untill it was time to go to the movie. She looked up. Over a few
    tables was the old black man. Since she had noticed men looking her way. Kelly
    was starting to become a tease. So, she walked his way to put the books away.
    She knew he wouldn't do anything in public place. When she was in front of him.
    She dropped the books. Bending over to pick them up. (without bending her knees)
    Her tank top layed so the old black man could get a good look at her white
    breasts. The old black man's mouth dropped open. Oh! Excuse me. (acting as it
    was an acident)

    Kelly headed to the movie. Which was a couple of blocks away. She loved the
    reaction she had got from the old man. The movie Kelly wanted to see was sold
    out. She wanted to see a movie. So, she got a ticket to another. Then she saw
    that another was starting and it was rated R and nobody was around. She went on
    in. Hardly anybody was there. Kelly sat towards the back . The movie started.
    When a nude scene started someone came and sat by her. She didn't even pay any
    mind. She in awe of what was on the screen. This was her first R movie. There on
    the screen was a black slave climbing on top of his master's white wife to have
    sex. Kelly liked the sight of the slave's black skin on the white woman's body.
    Kelly didn't even realize the person beside her had placed their hand onto her
    knee.

    But, when he moved his huge hand upto her thigh. Kelly regained her awareness.
    She turned. It was the old black man. She tried to push his hand away. He just
    leaned over and kissed her neck. He kissed his way down to the tops of her white
    breasts. As he moved his hand upto her shorts. He kissed the tops of her breasts
    as he rubbed her crotch. He then unbuttoned and unzipped her shorts. Even though
    she liked the sight of his black face to her white chest area. She knew she had
    to do something before he got any further. She thought to herself (that she
    shouldn't have teased this old man) As the old black man started pulling at the
    young white girl's shorts. Stop. Or I'll scream. At this time an usher was
    making his rounds. Kelly got up to leave. The usher stopped her. your not old
    enough to see this movie. I know. I came into the wrong movie by acident. Kelly
    left and went home.

    It had been several weeks since the incident with the old black man. School had
    started. Pro football season had started the week before, and Kelly's school was
    going to have their first game tomorrow morning. Today they were having a pep
    rally at the end of the school day. Kelly stopped over Stacy's house for awhile.
    It was about 6:00p.m. Kelly hurried home to help set up things for her dad's
    party. Every month her dad and some of his friends would get together and have a
    few drinks and discuss sports. This was her dad's turn to have it at his house.
    When she got home. Her dad told Kelly that her mother had went out with aunt Mae
    and that she'd be out late. Kelly helped her dad set things up. Most of the guys
    were there. Kelly fixed herself something to eat and took it to her room. She
    turned on the stereo as she ate.

    It was about 8:15 now and Kelly decided she'd take swim as it was unseasonabley
    warm tonight. Kelly danced around to the music as she got her bikini out.
    Without thinking she took her top and bra off. She was in front of the window
    and hadn't pulled the blinds down. She looked outside and noticed Mr. Turner
    looking up at her. Mr.Turner was retired runningback from the local pro team. He
    was black very muscular. He stood about 6 feet tall and weighed around 235
    pounds. Kelly was so embarassed. She hurried away from the window and put on her
    bikini. She thought about not swimming. But, after a half hour she went on down
    to swim. As she tried to sneak by the rec room. Mr. Turner walked out and almost
    bumped into her. Oh! Hi. Didn't mean to run you down. Kelly couldn't even speak.
    By the way. I didn't mean to stare earlier. It isn't everyday you see such
    beauty. That's ok. (very quietly) As she went onto swim.

    Kelly swam and relaxed poolside for a couple hours. She went on upto the
    bathroom and took a shower. Dried herself. Then, slipped on a robe. She went
    across the hall to her bedroom. As Kelly entered her room she looked to see who
    was coming up the stairs. It was Mr. Turner. May I use the restroom. Sure. Kelly
    pushed at the door. The door sounded like it closed. But, it came open slightly.
    Kelly saw Mr. Hicks looking through his upstairs window towards her. He must be
    around 73 years old. Kelly turned on the radio and started dancing. Her robe
    came open. Mr. Hicks just stared as she danced. Kelly turned off the overhead
    light after turning a lamp on. She thought to her self. She'd realy give
    Mr.Hicks a surprise. She slipped her robe off. Exposing her totaly naked body to
    him. After all he was in his house and to old to do anything. She danced around
    for a few more seconds. Then she layed down on her bed. Mr.Hicks still had view
    of her. Kelly was turning into a real tease and was liking it. She rolled over
    onto her belly, so that Mr.Hicks would get a good look at her butt.

    She heard the bathroom door open. She glanced at a mirror across the room, and
    noticed her door was open slightly. She thought about getting up and closing it.
    But it was to late. Mr.Turner was in the hallway next to her doorway. Kelly
    acted to be asleep. After a few seconds she heard the door close. Kelly figured
    that he pulled the door closed. But, when she heard some movement. She became
    terrified. She kept her eyes shut as if she was sleeping. She then felt
    Mr.Turner run his hand up the back of her white thigh. Kelly trembled as he
    caressed her young white buns. She instantly felt herself getting wet inside.
    Mr.Turner kissed her white butt. Kelly liked this but knew it was wrong. She
    turned over onto her back. Don't!

    Then she saw him. Totaly naked huge black man. Huge biceps, a very muscular
    chest, ripple tummy. Kelly let out a quiet gasp as she noticed his huge erect
    penis. It must be 11inches long and realy fat. She couldn't get her eyes off of
    his huge black monstercock. Mr.Turner walked upto her face. Suck on it. No! as
    she thought ( that would be gross) He rubbed his black cock across her lips a
    couple times. He then went to the foot of the bed and knelt down. He kissed the
    young white girl's thighs working his way up. Don't! Stop! I'll scream. As
    squeezed her legs together. He kissed her blonde pubic hair, then lower belly.
    Kelly became speachless as he kissed white belly and licked at her bellybutton.
    Mr.Turner wasn't going to take a no for an answer at this point. He kissed his
    way to her teenage white breasts. He kissed and sucked at her nipples at the
    same time ran his hand to her young pussy.

    Kelly let out a moan, as he inserted his finger inside her. She tried to push
    him away. Even though she was enjoying what he was doing. Kelly knew this was
    bad and besides he would most likely rip her in half. Mr.Turner rubbed at her
    teenage pussy for moment to lubricate the outside of her pussylips. Mr.Turner
    climbed onto the bed to mount her little white body. Kelly held her legs
    together. Please don't It will hurt me. It only will hurt for a moment. Ohhh! As
    Mr.Turner rubbed his huge black cock up and down her little pussy. He pushed
    forward. No penetration. He gave big shove forward. Still no penetration of the
    little white girl's pussy. He pushed again and finaly managed to get his
    cockhead inside her. Kelly tightened up. He pushed a little deeper. She felt his
    huge black cock press against her hyman. She knew that one more push would pop
    her cherry. Just as he drew back. A knock at the door. Kelly! Kelly! Are you
    awake. As the door opened. Mr.Turner jumped off the side of the bed.

    Hi dear. Mmmom! Yes. Are you ok? ya. Dad, said you'd be late. The movie was sold
    out. So, I came home early. Are you sure? That you are ok. Yes. Just tired. I've
    told you to pull the blinds down. You are old enough now that guys will love to
    see you dress and undress. You sure seem nervouse. Is there anything wrong? No
    mom! Well, you look flush and sweaty. I'll get the thermetor. No. That's ok. I'm
    alright. Ok. Call for me if you need me. Goodnight. Goodnight mom. Kelly was
    trembleing. Mr.Turner jumped up and dressed and quietly went back downstairs
    where there were still a few men gathered having their last drink. Kelly finaly
    fell asleep a couple hours later. But, within another hour she woke up from a
    bad dream. Her mother rushed in and comforted her. Kelly couldn't tell her
    mother that she dreamed about being raped by twelve black men.

    After this Kelly quit teasing men for a couple weeks. She started slowly once
    more. She would mostly like old black men. She would go without a bra and leave
    a button undone then lean over in front of them. During the holiday vacation.
    When her parents were at work. Kelly even went totaly naked. Except a long
    winter coat. She rode the public bus all the way downtown. She aboat croaked
    when an old black man sat beside her. They talked awhile. He was headed to work.
    He was going to retire in the spring, after 40 years of service. When he looked
    the other way. Kelly undid the top button of her coat. Which exposed just a
    little of the tops of her white breasts. Your a very pretty young lady. You need
    to be careful. Someone may try to have their way with you. I can take care of
    myself. Here's my stop. Take care.

    Kelly felt ashamed. She stopped such things. Untill the last day of school. She
    had worn her white blouse and plaid skirt.(the catholic school girl look) She
    decided to walk home since it was very nice day out and school let out early.
    She was walking through the park. She was nearing the walk bridge across the
    creek. She heard some voices coming from under the car bridge nearby. There were
    three black hobos. There was nobody else in sight. They were washing theirselves
    in the creek. She starred at them. They only had their pants on. But, she liked
    the sight o their black chests. Kelly also knew that they would most likely see
    her cross the walkway. She was realy excited. After a moment she slipped her bra
    then pantys off and put them in her backpack. This excited her. Even though they
    were to far away to notice. She only had two blocks to go to get home from the
    park. When she walked across the walkway. The men whistled and yelled to her.
    They were close enough to see that she was a pretty girl. Kelly liked this but
    ignored them. But, then she noticed they were following her. She picked up her
    pace. A short distance from the street. They caught her. One of the black hobos
    grabbed her. Turned her around. Man! We're goin to have a good time today. As he
    saw her quarter sized pink nipples poking through her blouse. Then a cop drove
    by. Then backed up. The men ran off. Mam! Were they bothering you? As the cop
    walked upto her. No sir. He was a tall black man in his fortys. He took a double
    take when he noticed her pirky breasts through her blouse. You need to watch how
    you dress. Your asking for trouble.

    That night she dreamed of Mr.Turner fucking her. She woke up in a sweat. She was
    showering when her parents yelled in at her. Honey! We're headed to work early.
    Kelly wondered more and more what it would feel like to be fucked by a black
    man. Mr.Turner was very gentle with her. She couldn't believe how close she came
    to being fucked. Kelly thought to herself-(I know it's wrong. But, I'm going to
    find out today) She put on her bikini pantys then bra and her summer sundress.
    After slipping on shoes she went downtown on the bus. Remembering the first
    experience with an old black man. She walked towards the alley where she first
    saw him. It was almost 10:00a.m. Ahead was a tall old black man. It might even
    be the same man. Kelly acted as if she didn't notice him. She walked as if going
    to the library. Hey baby! Don't you say hi to your friends? So, she knew he was
    the same man and he remembered her. Oh. Hi. (acting not to be interested) Hey!
    You want a puppy. (Knowing this was a ploy) (Even though she was scared-she was
    going through with her plan) Sure! Where is it? Down here. In a box. Directing
    her to the alley. Kelly nervousely followed. I sleep here and this puppy came
    upto me and had no tags. A third of the way through the alley. There were stacks
    of large cardboard boxes with blankets on them. There were five other old black
    men laying on their blankets. Untill they seen her. Kelly started to leave. Not
    soon enough. They surrounded her.

    Don't I'll scream! One of the black men pulled out a knife. No you won't.
    Unless! Kelly stood there while the black men fondled her. Two of them fondled
    her breasts and two others played with her firm butt. One watched the street as
    one of the black men unzipped her sundress and slipped the straps off of her
    shoulders. Her dress fell to her ankles. Please! Don't hurt me. The man with the
    knife walked upto her. Not saying a word. Cut the right strap of her bra. With
    the other black men laughing he cut the left strap. Starring into her eyes he
    ran the knife across the tops of her breasts. Then suddenly cut her bra in half.
    Kelly's bra fell to the ground. Exposing her firm white breasts to the old black
    bums. They all got quiet. Starring at the young white girl. The black man put
    the knife up. Then with two hands grabbed her pantys and ripped them from her
    petite teenage body. Kelly felt herself getting wet. Even though she was
    terrified. Here she was a virgin about to be raped by six old black men in an
    alley downtown. She didn't even know if they would kill her or not.

    Kelly just watched as the man in front of her dropped his pants and undershorts.
    He was black as midnight. His cock was hard pointing towards her. It was smaller
    than Mr.Turner's. But, Kelly didn't see how it would fit into her. Kelly shaked
    like a leaf and tears started to run down her face. The black man's cock pressed
    against her belly as he stepped closer. He shoved her down onto a blanket. He
    knelt down and pushed her legs apart. She was to scared to fight back. She
    looked to the side as he mounted her. She noticed that the other men's dicks
    were larger and fatter. He whispered to her I'm the nice one. The others would
    just ram it inside you. He rubbed his black cock up and down her blonde pussy 4
    or 5 times to slicken her up. He then pushed forward. Without sucess. Then
    another, and another. Your one tight chick. One more huge shove forward and
    Kelly felt his cockhead push inside her. Then another push and he was touching
    her hyman. He pulled back. Then with a smile gave a quick shove forward. Kelly
    screamed out in pain as his black dick ripped through her hyman.

    The black man took pleasure at the painful look on her face. Your just a spoiled
    white brat. As he slammed all 8 inches of his cock into her. Blood ran down her
    butt. He squeezed her white tits so hard she thought that they would pop. She
    felt his hairy black balls slamming against her white butt. The other black bums
    were urging him to hurry. They wanted their turn. The pain subsided after a
    couple minutes or so and Kelly was starting to enjoy the fucking she was
    getting. She wrapped her legs across the backs of his. Kelly let out moans of
    delight as the black man pounded his cock into her white pussy. She was about to
    climax when she felt the man cum inside her. With one more lunge forward. He
    pulled out of her. Who's next. She's a fine piece.

    The next black hobo ordered her to her hands and knees. Like a dog you know.
    After penetrating the young white girl from behind another got infront to force
    her to suck him. She learned quick how to suck. Kelly first thought it was gross
    to have a man's dick inside her mouth. After a couple minutes she even started
    enjoying cocksucking. The man behind her fucked her as hard and fast as he
    could. Making her buns and tits bounce around. She felt herself building to a
    climax again. This time she squeeled in delight as she climaxed and felt the
    black man cum inside her pussy. The old black man in front was cumming into her
    mouth as the man behind pulled his black cock out and squirted a couple times
    across her butt. The two black men quickly stepped away from the petite white
    girl. When another layed beside her and directed her on top of him.

    Kelly sat on his 12 inch black snake. She let out a gasp in dispair as the last
    4 inches went inside her. It was uncomfortable as he fucked her. But, after a
    moment it felt good being stretched this far. She figured he must have the
    biggest dick in the world. To her surprise one of remaining black men knelt
    behind her. He pushed her forward. He guided his 10inch black cock to her white
    butt. He gave a hard continued push. Kelly screamed and tears appeared again as
    she felt like she was being ripped in half. Without hesitation the black men
    fucked her hard and unmerciful. One in her white ass and the other in her blonde
    pussy. Even though it hurt after a few minutes of being double fucked. Kelly
    yelled out in another orgasm. As the black man inside her butt squirted streams
    and streams of cum inside her. Then the last black man traded places with the
    man that was buttfucking her.

    As he started buttfucking the teenage white girl. He yelled out. Hey! we're a
    oreo cookie. Kelly was getting exhausted and was going limp. It felt like she
    would pass out. Then she orgasmed again. After she came off of her third orgasm,
    the man pumped her white ass full of his black seed. He quickly withdrew from
    her as the man under her. Rolled over on top of her. He went to fucking his
    black 12 inch pole in and out of her as fast as he could. He sucked on her white
    breast. When he started cumming inside her he bit down. Kelly let out a yelp.
    This didn't stop her from climaxing again, for the fourth time. The man stood
    up. She was exhausted and just layed there. To her amazement they were still
    standing around naked. We want you to meet Bubba.

    Kelly was amazed when she saw Bubba. He was about 50yrs.old 6ft.6in. tall
    220pds. His cock must be around 14 inches long. As he mounted Kelly's little
    white body. He told her that he was going to fuck her brains out. It looked like
    a black monster mounting a little white doll. He entered her slowly. Even though
    she had been reamed out several times. It was slow going for him to get his
    black cock into her. After getting 10 inches inside her white pussy. He started
    fucking her hard. After a few minutes his huge black balls were smacking against
    her white butt cheeks. Kelly orgasmed first. Then she felt him shoot a couple of
    squirts of cum inside her pussy. He pulled his huge black cock out of her and
    finished cumming all over her flat white belly. After he stepped back. She was
    surrounded by the other six black men. They jirked theirselves off all over her.
    She was drenched in cum. Her hair and face was covered with cum. Her white
    breasts, belly, pubic hair, pussy, and butt was also was covered with cum. She
    thought to herself I can't move. She figured that she was about to pass out with
    exhaustion.

    Kelly just layed there naked and covered with cum. The black men were dressed.
    When she saw reflections of flashing lights. The black men had went to the
    entrance of the alley. Kelly heard them talking to what seemed like police
    officers. She slowly got up and peeked around the corner. It was the police. She
    grabbed her sundress. As she walked out the otherside of the alley she slipped
    on the dress. Her shoes had fallen off during all the fucking. Her breasts,
    pussy, and butt ached from the pounding and stretching. She was drenched in cum
    which was starting to dry on her now. No place to clean up. Oops. Excuse me. She
    bumped into a lady. Are you ok. Yeh! Sure. Kelly walked three block as everyone
    starred at her. Since she was such a mess. People kept asking if she was ok. She
    got home on the bus. She threw her sundress in the washer, showered. Redressed
    and fell asleep on the coach.

    --
    --I like to lick the shitty bits off Cmdr Tacos crusty ass
  54. All your compilations are belong to us by brer_rabbit · · Score: 2
    . . . if you buy the compiler, you are allowed to distribute code that you compile with icc ;)

    I realize you've got a smiley there, but I've got to say: Duh! Who would use/buy a compiler that didn't allow you to distribute your binaries? That would be like using a word processor where you didn't own the work you wrote.

    Though it wouldn't surprise me if sooner or later the Microsoft C++ or Word license would claim that any work produced with the tools is property of MS.

  55. Somebody got icc working on Debian by mbanck · · Score: 1
    The Article stated that it wasn't easy to get icc running on Debian. Does anybody have some insight on this, perhaps a small HOWTO?



    thanks,



    Michael

  56. This is a FP-based test by Florian+Weimer · · Score: 3

    Floating point performance doesn't tell much about integer performance and vice versa (remember the Itanium). It is well-known that GCC has got its problems with the stack-based x86 floating point unit (especially pre-3.0 versions; some people claim that 3.x is faster).

    Since the kernel doesn't use floating point instructions, it's not such a big loss that you can't compile it with icc yet. In addition, compiling the kernel (which is not written in ISO C, let alone ISO C++) might uncover a few bugs in the kernel code and the compiler, and it's not very likely that the kernel folks are able or even willing to help you if you use a strange system configuration with a proprietary compiler.

  57. Precisely by Sycraft-fu · · Score: 2
    This is the same case with Intel's Windows compiler. They have a (very expensive) program that plugs into Microsoft's Visual C++ and does the compiling for it. As you'd expece Intel chips, most espically the P4 see marked performance improvements. What supprises some people is so do AMD chips. The compiler is just an all around more efficient compiler and it works better on all x86 chips, even those not made by Intel.

    I think the most dramatic demonstration of this was a test done by Tom's Hardware last year. He ran a test on a bunch of different processors doing MPEG-4 encoding using FlaskMPEG. The Pentium 4 performed abysmal, comming in behind a Pentium III 1ghz. Intel decided then to download the source code to FlaskMPEG and recompile it with their compiler. This moved the P4 up to the top of the heap, but also increased all the other scores. The P4 1.5 got the biggest boots, from 3.83fps to 14.03fps the PIII 1ghz also got a lesser boost from 4.39fps to 8.03fps. However the Intel compiler helped out the Athlon 1.2ghz too, boosting it from 6.43fps to 11.14fps. So it even gave their competitors' hardware a 60% speed boost.

    Intel's compiler division isn't interested in trying to screw their competitiors and make Intel's chips look the best, they are interested in producing the most optimized x86 code possible. Now of course the Intel compiler supports all the special Intel extensions (MMX, SSE, SSE2) and I don't believe it supportins things like 3dnow, but that dones't mean they are going to screw up their code on purpose to make it run poorly on other chips.

  58. KDE by MarkoNo5 · · Score: 1

    Anybody tried to compile kde with icc ? The pre-linking optimization helps a bit, but even the calculator takes about as long to start up as M$ word (and that's not a joke :( ).

  59. Why extensions? by Anonymous Coward · · Score: 0

    "all of gcc's extensions"

    Why does gcc have extensions (beyond ANSI supposedly) at all?! Portability surely suffers from this.

  60. Not sure what the surprise is all about by Eaps · · Score: 1

    This is an x86 optimised compiler and so since transmeta emulates x86, it was obvious that Transmeta would also benefit from it. Then it became a "Intel helped transmeta without knowing it haha" thing but I'm sure even the AMD chip perf improves with this compiler

    --
    The duality weakens
  61. Athlon anyone? by ppetrakis · · Score: 1

    I'm surprised to see the lack of "I recompiled everything using this on my Athlon and my performance increase was XX%". Simply said, It's an optimized x86 compiler and any processor that uses that instruction set should benefit from using it. Intel releasing it for 'free' gives HPTC guys one less hoop to jump through when tweaking their applicatiions. It also adds value to Intel processors in general.

    Peter

    --
    www.alphalinux.org
  62. compiler specific code, not a compiler problem by Dwain_Snyders · · Score: 1

    I'm not a big Intel fan, but I just have to respond to this. The fact that the Intel compiler is unable to compile the Linux kernel is absolutely not the compiler's fault ... if the code is written against a bunch of weird gcc-specific extensions, that's hardly the compiler's fault.

    I am currently working on the firmware-level compiler team at AMD, converting the legacy firmware compiler to a newer firmware base to match the new core. (64-bit, VLIW, etc... The upcoming Unicorn chip, will be released in 2003). I can tell you this much: While I admire the gcc team, the gcc compiler is quite bloated and has a lot of exotic features which do not work well with standard compilers. If the gcc team ever tried to fit gcc into firmware runspace, it would be literally impossible without a complete rewrite.
    --

    2DUP * ;

  63. Info from c't by Lars+T. · · Score: 1
    In the latest issue (23/01) of the german computer magazin c't (article not online - www.heise.de/ct/ ), there is an article about Intel's C compiler for Linux. Testing with SPECInt2000 , they get an average increase of 20% over gcc.

    P4/1.7 +26%, P3/866 +23%, Athlon/1.2 +16%, AthlonXP/1.2 +19% (due to SSE). But the boost is somewhat lower if you exclude the subtest 252.eon, which is more than 3 times as fast with icc.

    Another interesting test compared scores for icc on Linux vs. Windows on the P4. Linux scores a little lower on average, but two test show huge differences: 176.gcc on Linux scores 745 vs. 529 on Windows, while for 252.eon it's 406 (L) vs. 745 (W) - gcc only scored 115. You can see that SPEC sub-scores can differ wildly on the same processor even when using the same compiler.

    Mixed results for C++: 252.eon is C++, so it's obviously fast, but icc doesn't work with gcc compiled libraries (incl. most graphic toolkits).

    One more thing: if you set some switches the wrong way, the resulting code may not work as intended.

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

    1. Re:Info from c't by Lars+T. · · Score: 1
      Replying to my own post, the last sentence in peculiar.

      http://www.heise.de/newsticker/data/hes-11.11.01-0 00/ - Heise Newsticker reports (in german), that the compiler switch -ipo (inter procedural optimization) can seriously mess up the compiled program. An example given (with image) is Povray under both Windows and Linux, which can tint some images.

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  64. About the Intel Compilers... by ChaoticCoyote · · Score: 3, Interesting

    ...I wrote up a short "First Look" regarding the "noncommercial" (i.e., no-cost) versions of Intel's C++ and Fortran 95 compilers for Linux. I look at licensing, too, and have Intel's comments posted as well.

    You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.

  65. Maybe Transmeta is not screwed now. by Raven42rac · · Score: 1

    This development may be that step in the right direction that Transmeta, and for that matter Intel and Linux need at this point. I would really hate to see a great company such as Transmeta go by the wayside, because variety is good. Maybe Intel finally realizes that there is life after Windows.

    --
    I hate sigs.
  66. Intel Performance Libraries for Linux? by smcdow · · Score: 1
    When the hell is Intel goint to release their Performace Libraries for Linux.

    I could stand to use Intel's Signal Processing Library on Linux right now.

    My understanding is that Intel does have these libraries ready to go for Linux (and have for at least a year), but for some reason, refuse to release them.

    Anyone have any clues about this?

    --
    In the course of every project, it will become necessary to shoot the scientists and begin production.
  67. Re:screw the kernel, recompile the system librarie by Anonymous Coward · · Score: 0

    It would be nice to compile glibc with it. While the kernel has been heavily hand optimized in critical spots, glibc decidedly has not. Although maybe it wouldn't be enough. Design decisions like 64-bit UID support on all platforms may be nice for compatibility, but they kill little systems (e.g. how many users could I possibly have on my Atari ST?)

  68. That compiler produces code incompatible with GPL by yerricde · · Score: 2

    You can download it from Intel

    Reminder: This compiler includes no support and cannot be used to produce products for resale or commercial use.

    And thus produces binaries incompatible with the GNU General Public License, which allows no such restrictions on distributed binaries.

    --
    Will I retire or break 10K?
  69. But that's contrary to my experience by Anonymous Coward · · Score: 0

    My code is about 30% slower when generated by GCC on Linux than when it is generated by MSVC6 on W2k. The code is almost pure number crunching. So it's unlikely to be a difference of the OS performance.

  70. VLIW proper subset of RISC by yerricde · · Score: 2

    Transmeta is NOT RISC, it is VLIW with a x86 to VLIW optimizing translator.

    VLIW means "very long instruction word," and EPIC means "explicit parallel instruction computing," both of which in practice mean "architectures that combine several fixed-length instructions into one word." RISC means "reduced instruction set computing," which in practice means "architectures with fixed-length instructions." All important VLIW/EPIC instruction sets have fixed-length instructions (32-bit in a 256-bit word for TMS320C6K, 32-bit in a 128-bit word for Crusoe, or 41-bit in a 128-bit word for IA64), but MIPS, PPC, and Sparc disprove the converse; therefore, VLIW/EPIC RISC.

    --
    Will I retire or break 10K?
  71. It ain't that simple by Krischi · · Score: 1

    Just because the compiler is from Intel, it does not mean that it always generates better x86 code than gcc. Quite the contrary, there is a lot of real-world C++ code, for which g++ 2.95 and g++ 3.02 generate significantly better code on Pentium IIIs and Pentium IVs than the Intel compiler. I am talking about factors anywhere between 1.5 and 4 times slower.

    Surprisingly that includes floating-point heavy applications, even with SSE2 instructions enabled. You'd expect that the Intel compiler should do particularly well at these, but this is not always the case.

    We did some benchmarking and measuring as a consequence of these results. It turned out that Intel's compiler is rather bad at handling typical C++ data and procedural abstractions. g++ is much better at these, and it shows. I don't understand how people can keep harping on how lousy the code that gcc generates is supposed to be. In my experience, it has been quite respectable, especially with gcc 3.02.

    The bottom line is, as so often: Measure the performance of your C++ programs before deciding whether to compile it with g++ or Intel's compiler.

  72. Re:20 gigs of movies!? by Anonymous Coward · · Score: 0

    Boy, you're really maxing out the queues, stop downloading them all at once!

  73. You are right, in that you are wrong. by Proud+Geek · · Score: 2

    ICC doesn't even attempt SSE optimizations at the optimization level tested (-xMi; that's PPRO and MMX instructions; you need to -xMiKW to get SSE and SSE2 as well). The big wins that gcc could get would come from rewriting the scheduler and register allocator. The difference for gcc probably comes from extra loads and stores, and possibly more code in loop bodies. Function inlining may also play a part, as gcc doesn't do that very well.

    You may also be right that gcc doesn't play with the x87 stack very well, but that is likely a minor difference in comparison.

    --

    Even Slashdot wants to hide some things

  74. Re:20 gigs of movies!? by matrix29 · · Score: 1

    All I see there is directory after directory named things like "Boys In Bondage" and "Hot Rimming Volume 6"

    Ah yes, Shakespear's Classical "Gay Boys in Bondage".

    "Hot Rimming Volume 7" is about creative pie crust making.

    What have you been downloading?

    --
    "Face it, a nation that maintains a 72% approval rating on George W. Bush is a nation with a very loose grip on reality.
  75. g++ icc on my own FP-heavy program. by PeterM+from+Berkeley · · Score: 2


    I tried Intel's C++ compiler on my own floating point heavy plasma simulation program. I tried some very high optimization flags, and that produced a binary which crashed.

    Using -O1 produced a binary roughly 1/2 as fast as a -O3 g++-compiled binary.

    Perhaps this compiler is a win on C code, but on C++ it sure looks like a dog to me.

  76. Re:That compiler produces code incompatible with G by be-fan · · Score: 2

    Since when does the GPL not allow restrictions on distributing binaries? It only requires the ability to get the source for free.

    --
    A deep unwavering belief is a sure sign you're missing something...
  77. Commercial dists should recompile the lib&apps by informed · · Score: 1

    I wonder if Intel's compiler is binary compatible with gcc. While it's probably against the licensing to redistribute the compiler's math or C library, I wonder if you could compile the gnu math/C /X library with icc and produce a shared object? An optimized math or other system (X-)library would give some decent improvement in performance.