Slashdot Mirror

In case you're still reading this thread...

For compatibility, I think they had an emulator to run PA-RISC programs on Itanium. One of the incentives for starting an incompatible design was a project called Dynamo, which was like a Java JIT interpreter which analyses a program as it's running, and can optimise the most used parts. One surprise was that they could speed up a program by translating from PA-RISC to PA-RISC - the runtime optimisations in software were better than hardware (at the time).

A similar strategy was followed by Transmeta, interpreting 80x86 programs on custom VLIW CPUs. It failed partly due to Intel manipulation (basically giving a much better price to customers who never use a competing product), but partly from inconsistent performance - that matters less on a server, but more on a laptop, which was Transmeta's focus. Java is used mostly on servers, so the JIT and optimisation works well there.

I think continuing PA-RISC could have matched Itanium performance (if Itanium had not been delayed) eventually, but at the time it wasn't a sure thing. The real question was whether to put the dynamic optimisation in software or hardware, and a number of research projects hinted that software might be capable of far more than hardware (in addition to HP Dynamo, IBM's DAISY project did much the same thing, as well as Java JITs and Transmeta, and the Macintosh which just switched from 680x0 to PowerPC using emulation). Many people thought instruction sets would be irrelevant (Transmeta released several CPUs, all incompatible - no backwards compatibility barriers to newer, faster designs).

The idea is not dead though. Look up the Low Level Virtual Machine, or LLVM, which is used by Apple. One example is in the Macintosh OpenGL stack - rather than including a lot of branches to test for various settings, the LLVM optimiser basically strips out all those out when they don't change (or are handled by hardware), leaving behind simpler code for displaying windows and other graphics. Probably other things too, but that's all that's publicly announced. I suspect Apple is aiming for CPU independence eventually.

http://clang.llvm.org/docs/AutomaticReferenceCounting.html

The simple version is that the compiler knows when you need to release your object, so now it automatically inserts the code for you, instead of you doing it manually. The result is code that looks like garbage collected code, but without the overhead of real garbage collection.

XCode will soon be updated with the baseline of LLVM 3.0/Clang 3.0/LLDB/LibC++ probably around October or November. C99 is 99% compliant in Clang and C++ is humming along with C++ and C++0x support: http://clang.llvm.org/cxx_status.html

By the way, Chrome uses LLVM/Clang to build against.

You might want to look at the assembly your compiler generates. There is absolutely no speedup from doing this replacement if you are using a modern compiler, because the compiler will already be replacing all printf() calls with constant arguments with puts (or even putchar()). If you're interested, then look at LLVM's simplify libcalls pass. Search for printf in that file and you'll see the transforms it does there. It also simplifies a number of other libcalls. This means that it's fine to use [f]printf() everywhere - the compiler will transform it into puts(), putchar(), putc(), or fwrite() in cases where that is appropriate. Pretty much any modern compiler will do this. The behaviour of these functions is specified by the standard, so it's a safe replacement.

The LLVM project and OpenCL look interesting. I've never understood why a virtual machine is, in any way, better than an intermediate language that can be compiled to native code for a particular platform. An interpreted language may make sense for dynamically created code. Even so, why not just compile it first? You can run interpreted code in a sandbox, but any IM compiler could add the same features to native code.

This is a cogent and relevant post. If you are serious about fixing it, start a project.

Already been done, for more than a year (actually the project has been ongoing for more than a year, but the NEON support that the OP mentioned was done about a year ago. Works quite well too).

> LLVM would not preclude anything over any modern
> processor

http://llvm.org/docs/FAQ.html#platformindependent and the references to "not supported by all targets" in http://llvm.org/docs/LangRef.html seem to beg to differ.

> I also think it's the esoteric platforms which stand to
> gain the most from platform neutrality

Yes, but the point is that NaCl and PNaCl are both less platform-neutral than JavaScript. So it seems like time is better invested in JavaScript performance than trying to make PNaCl be more popular if you're actually interested in platform neutrality.

> LLVM would not preclude anything over any modern
> processor

http://llvm.org/docs/FAQ.html#platformindependent and the references to "not supported by all targets" in http://llvm.org/docs/LangRef.html seem to beg to differ.

> I also think it's the esoteric platforms which stand to
> gain the most from platform neutrality

Yes, but the point is that NaCl and PNaCl are both less platform-neutral than JavaScript. So it seems like time is better invested in JavaScript performance than trying to make PNaCl be more popular if you're actually interested in platform neutrality.

Lets try this again, logged in:

Ohloh doesn't have full version control history, but it does show a little over 30K commits to the LLVM and Clang compilers:

Time flies when you're having fun!

-Chris

Lets try this again, logged in:

Ohloh doesn't have full version control history, but it does show a little over 30K commits to the LLVM and Clang compilers:

Time flies when you're having fun!

-Chris

Ohloh doesn't have full version control history, but it does show a little over 30K commits to LLVM and Clang compilers:

Time flies when you're having fun!

-Chris

Ohloh doesn't have full version control history, but it does show a little over 30K commits to LLVM and Clang compilers:

Time flies when you're having fun!

-Chris

This is tired old FUD that you Microsoft shills trot out all the time.

Can you name one technology that Microsoft innovated? And by the way, it doesn't count if they bought it from someone else.

Ok, now to your original question:
1. Alchemy
2. Bespin
3. Bitcoin
4. eyeOS
5. KDE Social Desktop
6. Ksplice
7. Unity
8. HTTP, the Web, TCP/IP, and ARPAnet
9. X Windows
10. Perl
11. Slashdot
12. Google keeps playing with open source, but can't make up their minds. Here are some
13. Microsoft plays with open source, here are some. This must just eat you up. Too bad, Open Source is everywhere.
14. Here are some more innovative open source projects.

Now, I expect you to provide at least 5 innovative projects Microsoft created within the last 10 years. (Sorry, you can't count Windows or Office, since those ideas are much older, and are no longer considered innovative.)

Failing that, at least read what I wrote.

http://llvm.org/

are you sure

http://blog.llvm.org/2010/06/tce-project-co-design-of-application.html

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.

Okay, this is a fine idea. Just one problem here, why the heck is this being based on ia32?! If you're going to design a bytecode, design it around a sane VM, such as perhaps Dalvik. Even for the modern AMD and Intel processors the "machine language" is merely a bytecode they translate in real time to the actual processor hardware. Given these factors, you want a bytecode optimized for size and ease in translation to real hardware, things not present in ia32.

Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article on the generals.

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.

You are also significantly underestimating the effort that they have put into this BSD licensed project.

When you optimize to GPUs, you have to optimize to all GPUs. I realize there are common instruction sets but the main selling point of Android is its versatility.

Yes

That's why Apple uses LLVM to compile from 'generic GPU code' to 'GPU code optimized to Blah', that's on Mac OS and maybe on the iPhone as well

http://llvm.org/Users.html

Today is your lucky day, it's available for free at http://clang.llvm.org/ and http://valgrind.org/.
Make sure you read the instructions before you start, though. You can find them at http://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628.
Enjoy!

GCC (...) lacking serious FOSS competition.

http://llvm.org/ and http://clang.llvm.org/

GCC (...) lacking serious FOSS competition.

http://llvm.org/ and http://clang.llvm.org/

clang is BSD-compatible and better (for various definitions of "better") than gcc. The c++ support isn't production quality yet (their words) but I haven't had any problems with it.

clang is BSD-compatible and better (for various definitions of "better") than gcc. The c++ support isn't production quality yet (their words) but I haven't had any problems with it.

See Ken Thompson Reflections on Trusting Trust.

Now that there are multiple independent implementations of a C compiler, such as Clang for LLVM, TCC, and GCC, the trusting trust attack can be defeated with a compile farm.

[...]go at the speed of machine code. Or maybe to LLVM!

You mean like lightspark?

Is to use GCJ and go at the speed of machine code.
Or maybe to LLVM!

Agreed.

But seriously, try coding a week in Qt/C++. You'll learn what a decent library should look like. As for Qt's worst weakness: you'll have to deal with templates and the resulting error messages your compiler generates. (And $DEITY help you if you mess up in something 'moc' will generate code from).

Cocoa's libraries are excellent. The manual garbage collection you talk about is a copy of Cocoa/Obj-c's autorelease. Which dates back to the 1980s and is now on the road to being made obsolete by automatic garbage collection. And the error messages when using LLVM for Cocoa programming are the best in the business. I say error messages, but the IDE actually shows you a picture with arrows demonstrating the entire flow leading to the error.

http://clang-analyzer.llvm.org/xcode.html

ADC online accounts are free. The source for their latest gcc can be found here. You don't have to have an account to download it. For some other things on their open source page, you have to login, though. Assuming you were actually interested in developing for OS X, I'd advise you to use clang instead; gcc sucks bigtime in comparison, and will not be seriously updated by Apple anymore.

For me, it's the immaturity of Clang/LLVM that makes the project so damn impressive, like a three year old playing Bach's cello suites.

LLVM Project Blog: Clang++ Builds Boost!

it doesn't do i386

The LLDB Homepage claims otherwise:

LLDB is known to work on the following platforms, but ports to new platforms are welcome:

• Mac OS X i386 and x86-64

Performance is the slashdot summary key point, but if you look at the LLDB project goals page, better C++ and multithreading support is the main impetus of the project. Conclusion: don't rely on slashdot for anything. If a slashdot story told me the sky were blue, I'd have to go outside and check...

Personally I like my toolchain to have some heritage and age, so at the moment GNU is a safe choice for me.

I need a good static analyzer, which is nonexistent in the GNU toolchain.

Maybe while they're at it, they can add in actually-useful error messages. See http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html for some examples. It's shocking how user-hostile GCC is in comparison.

You jumped right on the LLVM part, but apparently don't know what clang is. You should read about clang. http://clang.llvm.org/

Not for long.

Yet it's getting replaced by Clang, which is superior in practically every single way.

This is true of iPhone SDK. This is not true of Apple in general. Darwin, CUPS, and WebKit are all open source. Apple also distributes for free the other open source code it uses like their version of bash, BIND, etc.

Don't forget LLVM, which is quickly becoming the best damn compiler out there.

Hell, if I wrote something as brilliant as LLVM, I'd want to keep it as close to my chest as possible, and attempt to make a fortune off of it. (Of course, LLVM didn't originate at Apple, but you get my point...)

Apple is a big (the main?) backer of Clang and LLVM http://clang.llvm.org/.

There's been much talk now about them moving away from gcc.

For starters, C, C++ and Obj-C all compile to native code.

Not necessarily. I suspect (though I don't know, and can't be bothered to find out right now) that for iPhone 4.0, they might be compiling to LLVM.

Frankly, optimizing assembly code is a PITA, since there are so much different flavors.
For example, AMD and Intel processors have different types of optimization.

If I were to code in assembly nowadays, I'd prefer to use something like LLVM: http://llvm.org/ which should be able to generate good optimized code for any kind of processors, without the hassle of maintaining one routine per processor.

In some very extreme cases (like coding a RC5 decoder or multiprecision routines), it's still useful to use assembler, but in most other cases, I'm sure that LLVM is able to generate code much better than you could achieve manually in the same amount of time.

A working static analyzer. Clang is almost there but generates way too much cruft to wade through.

More mature fuzzing tools would be handy too.

I'm not sure how it stands today, but a few years back, ICC produced code up to 30% faster than GCC or MSVC.
That was my understanding, but it's 10 years old... What I do know is that now Clang is considered production ready for C and Objective-C code, and it produces *significantly* faster code than gcc at least. I expect ICC probably still beats it, but it's a good improvement.

http://llvm.org/

I'm a little more familiar with the C# .NET environment, but I don't see any reason you couldn't apply the idea to C code as well. LLVM bitcode already exists with both a container and a intermediate format corresponding to .NET's IL or Java's bytecode. LLVM is designed to be suitable for direct compilation down to machine code without the companion virtual machines that .NET and Java expect. If all you want to do is delay the platform-dependent compilation phase, LLVM looks perfect to me.

Hmm, imagine LLVM in a browser..

You are correct except for one detail: today's headline is that libdispatch is now open-source, and is therefore no longer Apple-only technology. The implementation of blocks in LLVM's compiler-rt has been available or a while. This largely removes the objection you mentioned.

While I mostly haven't needed to respond to this debate, I thought I'd point out that GCC *is* being replaced . . . by a package with a BSD license.

(It'll take a bit, of course - something as huge as replacing GCC isn't an overnight thing.)

Nowadays, something like LLVM could be built into the kernel to handle all the JIT code generation. That would make it more portable and easier to debug. Having written a JIT compiler using LLVM myself, I can tell you it's not that difficult. Anyone that understands assembly well can do it, in fact, you don't even need to know all the details. If the OS was going to generate snippets of code to jump to certain points in a program, the bugs would probably get ironed out pretty quickly.