Monday, March 1, 2010

The Compiler: Better, Stronger, Faster

In the 1970's there was a TV show called the Six Million Dollar Man. It was about a test pilot named Steve Austin who crashed in an experimental aircraft and lost an eye, an arm and both legs in the crash. When he wakes up in the hospital he discovers that he's become an test subject for a government experiment to replace body parts with electronic equivalents. But these replacement parts are better, stronger and faster than the biological parts they have replaced. In fact in the opening of the show, the voice-over says that they have made Steve Austin better, stronger and faster.

Like Steve's legs, the compiler is what makes your apps go. And like Steve, we are working on making the compiler better, strong and faster.

While you don't see REAL Studio's compiler or even interact with it much (except when there are errors in your code), it's at the core of REAL Studio. It's what turns your REALbasic code into code your computer can execute. The compiler has two parts: a front end and a back end. The front end parses your code and transforms it into a sort of meta assembly language. Think of this as processor-independent assembly (even though regular assembly is actually highly processor dependent). For each processor type we support there is a different back end to the compiler. The back ends take the meta assembly language from the front end and translates it to the assembly for the processor for which you are building your app. That means PowerPC or x86 today.

We are working on a big change to the back end of our compiler. We are going to be replacing it with an open-source compiler back end called LLVM. It's becoming increasingly popular. If you really want to geek-out, check out LLVM.org. We are moving to LLVM because there is a team of people working on LLVM and by switching to it, we get the benefit of their work. For example, it supports all the processors we support or would likely want to support including the ARM processor which is used by most smartphones including the iPhone. Unlike the current REAL Studio compiler, LLVM is an optimizing compiler which means it will make code optimizations that will make your code run faster. How much faster depends on what your code is doing but we have seen speed improvements of up to 10 times faster. LLVM does something called "dead-code stripping" which means that it will strip out the portions of the REAL Studio framework that your application is not using. This will result in smaller applications that use less memory. And for those that deploy on Windows and Linux, LLVM will eventually bring about the return of the single-file executable. And of course the more improvements that are made to LLVM in the future, the more we will benefit.

Today, we are working on getting LLVM supported for RBScript. That is nearly complete. Beta testers have been testing it for several weeks now. Once done, we will then move on to supporting LLVM for the main compiler. Considering how important the compiler is to REAL Studio, you may be wondering what sort of transition will be required to move from a version of REAL Studio that uses our current compiler to a future release that uses LLVM. If you were around for the last major compiler transition, you are probably especially curious. The good news is that because we are changing the back end and not the front end, the transition should be extremely smooth. We expect the vast majority of you to recompile and only notice that yours apps are smaller and faster. There won't be anything new you need to do. That's the beauty of the compiler. It does a lot without requiring much attention.

The move to LLVM is going to be an important step forward for us. And even if you don't use RBScript, you will be able to start experimenting with it via RBScript in the coming months. Eventually, your applications will get better, stronger and faster as well as the REAL Studio IDE since it is created with itself.

Now THIS is exciting news. If I have a complaint about REALbasic, it isn't that it doesn't support Cocoa yet, but that the apps it compiles are so huge in comparison with similar apps built with other development tools (particularly when the apps don't do very much).

We will only have to support one platform for the compiler (that platform being LLVM) however, we will still have to support 3 platforms for the framework (Mac OS X, Windows and Linux) which is a much bigger job. And for the compiler, it's really just 2 platforms (PowerPC and x86) though their are 3 different linkers (one for each OS).

The only downside is that it's a lot of work to make this change but once made, there are a lot of benefits.

Great news for 2011!. Cocoa and single executable are very expected. After that will be a seamless controls pallete beyond the native ones. Something that guarantees that a button, a radio button, a scroll bar, a text box, etc, the entire UI design, will look the same as planned on all platforms. I really wish a write once, run everywhere without changes paradigm.

The issue with iPhone is not just the processor support but also all the differences in API and controls used. I find it challenging to even think about a desktop app that would run on iphone as well.

The speed and optimization is very much welcomed by the game developers, combined with the current OpenGL support. I assume LLVM will also make it easier (or possible) to truly utilize GPUs and other DSP chips. If the LLVM works with Cray it should be ok for rest of us as well...

The goal is not to take a desktop app and run it on an iPhone. The goal is to provide developers with a way to build iPhone apps as quickly and as easily as they can build desktop apps today and use the skills they already have to do that.

LLVM will help us to be able to build shared libraries, DLLs and plug-ins but it's not the only piece to that puzzle. But I agree with you that if you could create plug-ins, it would greatly expand the 3rd party market.

As for pre-emptive threads, that's complex. Any part of your code that does anything related to UI will not ever be thread safe. That's an OS issue, not a REAL Studio issue. So the best we can do is work to make the rest of the framework thread safe but then users would have to some how be made aware when they attempted to use something that is not thread safe. Additionally, there are lots of things you must be careful about in your own code when using threads. What people want is to write their code the normal way and just have it work in a pre-emptive thread but that's not how it works in any language. For example, you can't go changing a property value in a pre-emptive thread the way you do in a regular code because some other part of your code could also be running and attempting to do the same thing. So there's a lot more to think about.

Regarding LUA or any other scripting language, LLVM does not help with that at all. The front end of the compiler is what makes the REALbasic language possible so supporting LUA would require writing another front-end to our compiler. The question is, what would you gain from that?

I really appreciate your comment. It's very interesting what you say and it's very interesting to have direct communication with the CEO of RealSoft.

- If shared libraries and DLLs can be done in pure RB, I expect as wonderful success not only to developers, but to you. The fast development and easy of use of RB will make a programmer's dream. IMHO, I will prioritize this as much as possible. We need urgently to have as much 3rd party classes to avoid reinventing the wheel as much as possible. And that means money to 3rd parties. Kudos if it can be done soon.

- I Agree with you about the inherent OS limitations of thread safe code. In my projects, I use Client / Server approach done with console projects that communicates with GUI via IPC, JSON, XML, etc.. Most server software I see is written in Java, Python, and other not native code compiled language. A few in C++ following the same approach (I am writting a MMORPG solution in RB). CriticalSections and Mutex are needed, but surely you can get some clever way to aid the developer in avoiding deadlocks. Your team is smart to make it easier... I guess debugging would need to be improved, but it would be a perfect solution for this kind of applications IMHO.

- RBScript is not what I would define an scripting language, since we can not call objects directly outside it. In my opinion it should be deprecated in favor of an open scripting language that is not so based in RB, if DLLs and Shared Libraries are finally a dream come true. Customers could use their skills on these scripting languages to customize our applications. Apart that RBScript has been something not very clear to me, and quite limited.

I appreciate your comment and willing to contribute with ideas and feedback to RealSoftware. If my MMORPG server can be done in RB and not just prototype it, I will keep some ancient C++ dinosaurs mouths...

The LLVM-enabled version of RBScript should ship in the next release of REAL Studio. We have not yet announced a time frame for moving over the main compiler. However, it will likely be done in stages starting with Mac OS X or Linux. Windows will be last because it will require the most work due the fact that we will have to write a new linker for it.

@ Jason - RBScript is now fully functional using LLVM. Right now the resources that would be working on LLVM are focused on our transition to Cocoa on Mac OS X. However, I believe we will be back to work on LLVM later in the year.