Marco Tech Blog

In today's development landscape, natively compiled code is making a significant comeback. RAD Studio has always been focused on it.

In today's development landscape, natively compiled code is making a significant comeback, even if in a fairly different variety of scenarios. RAD Studio has always been focused on it and developers using Delphi and C++Builder probably experience its advantages without even noticing them.

Natively Compiled Code: A Comeback?

Let me clarify the terms first. I refer to natively compiled code as code that is compiled (at some time of the process) into machine code the target CPU can execute. As you start your application, there i no further conversion to take place. I mean, like the output of a traditional compiler producing a binary executable, but not only.

For several years most of the focus has been on execution environments (.NET, Java, the various JavaScript engines) that would either interpret and execute the source code or most often an intermediate optimized format (ByteCode, IL, etc). Most of these systems benefit from some JIT (just-in-time) compiler so that each method is executed and compiled only once after loading the application.

Now while this model is still extremely popular (and it is going to remain mainstream, I'm not suggesting the opposite), there are many signs of a significant comeback of natively compiled code:

Apple platforms and iOS in particular have been pushing the "native only" mantra, basically disallowing execution environments other than JavaScript. Odd drawback is pushing developers to package two versions of their applications (32-bit and 64-bit) into a IPA package. Their alternative model is allowing for compilation of bitcode into binary on their own backend systems -- so you are submitting BitCode and Apple converts it to binary before the users download the app.

Android has started implementing an "installation-time" compilation (ART), compiling Java ByteCode to binary when the application is downloaded. This "compilation" happens on the user devices, depending on the device CPU and OS version. Beside making it very time consuming to do a system update (as all apps needs to be recompiled), this is making Java apps execution faster.

Also on Android it might come to a surprise but most of the best-selling apps are not written mostly in Java, but in C++ using the NDK. Which is the same model Delphi and C++Builder use. If you don't believe me, read for example Microsoft as they said (one year ago):"Platform defining, cross-platform, new trendy applications such as Facebook Moments, Dropbox, Office, Skype, popular games (e.g. Fruit Ninja, Clash of Clans, EA Sports titles) are all written in cross-platform C++. Talking more numbers if you take a look at the top 50 android applications a vast chunk of them (~75%) of them leverage C++."

On the Windows platform, most applications have always been native, despite Microsoft pushing .NET for a long time even Office and their mainstream applications are natively compiled and likely mostly written in Visual C++, even if there are exceptions in which Delphi is used ;-). But the trend to opening more native apps has become even more significant after Microsoft opened the Windows Desktop Bridge, with many companies previously trying to build native WinRT apps and now back the business as usual to support Windows 10 with traditional applications -- although to be honest some of them are actually .NET-based. A good example is Telegram, written in C++, which seems to have scrapped UWP WinRT plans in favor of a Desktop Bridge approach. We are witnessing a large number of Delphi (and C++Builder) applications landing to the Windows Store via the bridge.

Web services space is also seeing significant migration from scripting (PHP, Ruby) to more efficient solutions in terms of processing. The original idea of "let's throw more hardware at it" doesn't always scale as expected. If you need to 2x machines (like 4 machines instead of 2) no big deal. But when you need 10x machines and the system is huge, 100 servers instead of 10 might push you to rethink the strategy. Including the fact that these servers can be power-hungry and power-consumption has become a significant decision factor. Although limited, some migration to natively compiled server side code has been happening -- or at least, migration from less efficient scripting solutions to more efficient execution environment solutions.

By Why Natively Compiled?

There are many reasons for this push towards natively compiled apps, at very different levels. There are also many reasons this is considered far from ideal, and (as you've seen in the list above) it happens different levels, not always in the development phase and with classic development tools. Anyway, some of the reasons include:

performance, better optimization of compiled code, often combined with non-GC memory management (but not always) -- even if JITers create very fast code, they take a hit often at application start time, giving a bad first impression. In case of true scripting, compiled code also implies syntax checking it and writing more robust applications, but also here technologies vary (for example TypeScript does improve the robustness of JavaScript, even if it remains interpreted). Truly the optimization fo teh JITer for a specific machine can end up being even better than a general purpose more CPU-agnostic compiler. So I know this can be debated at length.

improved security due to the fact there isn't an execution environment that might be exploited, and again because the code is binary. A related issue is better IP protection, given reverse engineering is significantly more complex on natively compiled code (even if there are notable obfuscation solutions, they often fall a bit short and they don't apply to all languages alike -- JavaScript being fairly weak on this respect)

a reason for compiling code upfront (compared to BitCode or Android installation JIT) is full control on the application: if the code being executed by your customers is different from what you wrote, even testing it becomes fairly less deterministic

more on the business side, the fact your company might already have existing natively compiled code that you can even move to new platforms without doing a full rewrite (for Windows 10 Store, but even in the mobile space) ca be a significant advantage

single source can be native, despite claims (in the mobile space, mostly) that native code ends up being written with different languages, IDEs, and tool chains, there are technologies that allow a good balance of natively compiled code, native platforms support, and code reuse. Visual C++ is one of those (despite the fact that it has no cross-platform framework) and Microsoft is using it for their mobile apps -- and not Xamarin, it seems, while Qt and RAD Studio (on the C++ or Delphi side) offer also higher-end cross platform libraries, covering platform features and also UIs.

Conclusion

While I know things are way more complex than I've tried to depict in this blog post -- and sorry if I skipped or missed some relevant details -- my point was to underline the fact that "execution environment" are not the only model you should consider, they are not they way to the future, but the present is and the future will continue to be a mix of natively compiled and intermediate compilation or scripting. While a few years back things were more one sided, there are now even more signals that natively compiled code has a place and it is going to stay and receive continuous investment, both by the platforms vendors (Apple, Google) in terms of post-development tuning and by development tools vendors focused on the natively compiled space.

This is a reason Delphi and C++Builder have and will keep having their role, bringing natively compiled applications to Windows 10 (Store included), the mobile space, and soon also the Linux platform -- as we saw optimizing server side code execution is also relevant. Having different options and solutions for different projects remains critical for developers. Don't rule out natively compiled code, if you thing it is just going away, you might want to reconsider.

And if you have been staying on the natively compiled side, keep appreciating its value and virtues. Alternative options do have merit, for sure, but natively compiled code has a place. And not a small one!

17 Comments

RAD Studio and Natively Compiled Code

I for one regard performance to be very important. Whilst the
Delphi compilers have always produced natively compiled code,
they have a poor track record when it comes to the efficiency of the
emitted code.
It's not enough just to compile natively, the compiler has to
produce efficient code. Could you speak to that at all? Will
Embarcadero make any efforts to improve the long standing
deficiencies in its compilers, in terms of efficiency of emitted
code? For my own personal reasons, FWIW, the desktop Windows
compilers are the ones that matter, and in fact these days it is only
the Win64 compiler that matters to me.

Comment by David Heffernan on February 6, 10:48

RAD Studio and Natively Compiled Code

Great analysis

Comment by Flavio on February 6, 11:04

Energy saving...

I would have also mentioned "battery saving" as a reason to choose
native compiled code solutions. Many runtimes add a little overhead
to business code execution. Native code can pair good performance
and low battery usage, especially on mobile devices (when used in
the correct way and having respect for CPU cycles, obviously). :)

RAD Studio and Natively Compiled Code

Awesome article. Especially the IP part. Imagine your app gets after
a year hard work gets ripped, changed backgound/title and sold in
the play store or one of those China Android stores for half the price.
Guess that the C++ people at MS where always right about their
IL/.Net scepticisme.

Comment by Edward on February 6, 15:07

RAD Studio and Natively Compiled Code

And then you wonder about all the time wasted to
chase .NET while the native compiler development stalled.
Heffernan is right, yet as far as we know, there's no
a valuable compiler engineer nor team, working on Delphi.
And what could we expect from the outsourced
development model now used? Compilers need skilled,
dedicated resources. Or this is just a way to say
Delphi will be moved to LLVM soon - so it doesn't need
its own compiler - even if it will cost backward
compatibility?

Comment by KMorwath on February 6, 18:59

RAD Studio and Natively Compiled Code

Also great thoughts about the security of the execution enviroment.
Which is just another security surface to attack. Just look at the
numbers of java or .net security patches.

Comment by Edward on February 6, 20:36

RAD Studio and Natively Compiled Code

Totally agree with David Heffernan comment about emitted code
quality, it is a fundamental aspect that should be treated with total
care. But in my company case, both Win64 and Linux (64) compilers
have the same relevance (although the performance of the emitted
code by the linux compiler is not yet known)

Comment by Dave on February 7, 18:45

RAD Studio and Natively Compiled Code

I've never been a fan of jitting. For me, it's either interpreted or
natively compiled.
After years of abstinence, I've been thinking about going back to
Delphi. First thing I did was to check the prices of Delphi
Professional - holy shit, that stuff is expensive.
Almost 2000 Euros for the Professional Version. Thanks, but no
thanks. That's way out of what I'm willing to pay.

Comment by Fritz on February 7, 22:17

RAD Studio and Natively Compiled Code

I like the idea of native, but does EMB have the resources to
maintain all the compilers. Not looking so good at the moment.

Comment by Godfrey on February 8, 13:13

RAD Studio and Natively Compiled Code

I fully agree we need to significantly improve the efficiency of
compiled code, and we are working to address it. To those who claim
Embarcadero has no compiler engineers, I'm not sure about your
source of information, but I work with compiler architects at the
company almost every day.

RAD Studio and Natively Compiled Code

As one of the real oldies (COBOL1973) and Delphi I
in the mid-late 90's thru to Berlin, I have never
understood using anything but natively compiled code.
With the long awaited 64-bit compiler and X-platform
capability, I can continue to benefit from RAD Studio
natively compiled code til the other foot steps in the
grave! Cheers Marco!

Comment by Tim Hayes on February 9, 11:47

RAD Studio and Natively Compiled Code

Some quick comments:
1) you could pre-JIT a .NET app at installation time
(and before shipping to the customer too I think if
you didn't mind shipping multiple executables for
x86 and x64 - suppose you had no installer)
2) Both Mono's AOT technology and .NET Native
can compile to native code that doesn't use .NET as a
runtime. That's how Mono (and Xamarin which is
based on it) apps are allowed to run on iOS (Apple
doesn't allow dynamically loading code).
See
http://stackoverflow.com/questions/29609993/differe
nce-between-net-framework-4-6-net-native-and-net-
core
btw, the beauty of .NET is the OOP-based class
library, similar to how BCL/VCL/FireMonkey is one
of the strong points of Delphi. There is effort to
make .NET Stanard, as a base class library between
all .NET flavors:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/i
ntroducing-net-standard/
https://github.com/dotnet/standard/blob/master/docs/
netstandard-20/README.md

windows store and native code

btw, UWP is not .NET runtime-based, it is native
(COM+ based, extension of WinRT if I remember
correctly).
One can use .NET toolset to write UWP apps, but
those apps are compiled via .NET Native and native
bits are shipped via the store to customer devices
(depending on the device CPU [ARM, Intel x86,
x64])
Only exception is probably the Silverlight for
Windows Phone 8 runtime that is still supported on
Windows 10 Mobile. That probably ships IL
compiled code to customer devices, but I could be
wrong in that, since I've found some differences in
timing of my Amnesia of Who game (which uses
same code and XAML for both Silverlight plugin for
Web and Silverlight for Windows Phone 7.5 and 8)
after upgrading phone from Windows Phone 8 to
Windows 10 Mobile. There is a chance they
recompile that code at the store servers and use some
internal reimplementation of Silverlight API for
UWP

RAD Studio and Natively Compiled Code

I've been a long-time Delphi fan and continue to use it for projects.
I too have been curious about the team behind-the-scenes. Marco,
perhaps you and the other front-facing evangelists can fill us in on
the nature of the support staff busily working on Delphi and C++
Builder behind closed doors? It would help to instill a better idea of
how serious an effort this is and how committed to support and
enhancement EMB is.

RAD Studio and Natively Compiled Code

Native code all the way.
Efficient, and low disk space come second and third,
closely behind.

Comment by Thomas on February 17, 07:55

RAD Studio and Natively Compiled Code

I have done some initial experiments and it turns out the Godzilla
produces less efficient native code than gcc compiler.
You can write a code to count the number of primes from 1 to N
(where N is large).
You can compare Delphi and gcc at same Linux OS to see how it
goes. You can compare the serial version and the Parallel.For
version (or OpenMP in gcc).
My testings reveal that, Delphi Win64 compiler produces
reasonably fast code, but the Linux native compiler is far from 'the
fast'.
If you are targeting Linux 64 server, at least make it fast.
Otherwise, I still prefer gcc.

Post Your Comment

A blog about Delphi programming, Embarcadero, XML, Web 2.0,
JavaScript, and anything else Marco is working on
and has worked on in the past.
Site content is copyright
Marco Cantu' 2005-2016. Powered by Bootstrap and
Delphi.