RAD Studio and Natively Compiled Code

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

 
http://blog.marcocantu.com/blog/2017-february-natively-compiled-code.html

Natively Compiled Code: A Comeback?的更多相关文章

  1. 关于Natively Compiled Stored Procedures的优化

    Interpreted Transact-SQL stored procedures are compiled at first execution, in contrast to natively ...

  2. SQL Server ->> Natively Compiled Stored Procedures(本地编译存储过程)

    Comming soon! 参考: Natively Compiled Stored Procedures

  3. idea反编译失败 /* compiled code */的解决方法

    最近在研究源码,但是我的idea有点奇怪,有的文件可以反编译,但有的文件反编译后方法内容是 /* compiled code */,查了下说是反编译失败了,都说是插件的原因. 然后我看了下idea的插 ...

  4. IDEA无法编译源码,IDEA查看源码出现/* compiled code */

    打开Settings -> Plugins    搜索dec,选中,确定,重启,解决

  5. Java性能提示(全)

    http://www.onjava.com/pub/a/onjava/2001/05/30/optimization.htmlComparing the performance of LinkedLi ...

  6. Working with Numbers in PL/SQL(在PL/SQL中使用数字)

    This article gives you all the information you need in order to begin working with numbers in your P ...

  7. Database Initialization Parameters for Oracle E-Business Suite Release 12 (文档 ID 396009.1)

    In This Document Section 1: Common Database Initialization Parameters For All Releases Section 2: Re ...

  8. Database Initialization Parameters for Oracle E-Business Suite Release 12

    In This Document Section 1: Common Database Initialization Parameters For All Releases Section 2: Re ...

  9. sql-server-on-linux-how-i-think-they-did-it : Anthony Nocentino's Blog

    http://www.sqlservercentral.com/blogs/anthony-nocentinos-blog/2016/11/21/sql-server-on-linux-how-i-t ...

随机推荐

  1. 电子商务系统的设计与实现(七):前后端系统UI设计的一些思考

    对于大部分开发者来说,写界面是最烦人的事.我想,开发者最初诞生,以及我们在大学学习的时候,更加侧重的是程序设计和逻辑思维,而不是界面.界面更象是艺术,艺术和程序设计是两回事. 我个人还是想成为全栈式开 ...

  2. TensorFlow 学习(六) —— TensorFlow 与 numpy 的交互

    1. 将 numpy 下的多维数组(ndarray)转化为 tensor a = np.zeros((3, 3)) ta = tf.convert_to_tensor(a) with tf.Sessi ...

  3. 【81.37%】【codeforces 734B】Anton and Digits

    time limit per test1 second memory limit per test256 megabytes inputstandard input outputstandard ou ...

  4. 华为云软件开发云:容器DevOps,原来如此简单!

    当开发团队把代码提交到 Git 应用仓库的那一刻,他们心里在想什么? 祈祷没有bug?渴望回家补觉?产品经理Go Die? 对,也不对.因为这只是最终发布万里长征的一小步,接下来要面对测试环境.生产环 ...

  5. 单核、多线程与时间片,以Node.js为例

    去年写了篇文章<线程与进程的理解>,当时认为线程和CPU的单核多核无关,操作系统可以有很多个线程.但今天看<深入浅出Node.js>一书时,多次提到单线程无法利用多核CPU一类 ...

  6. Cross-Domain Security For Data Vault

    Cross-domain security for data vault is described. At least one database is accessible from a plural ...

  7. Clustering Devices In An Internet Of Things

    Clustering devices in an Internet of Things ('IoT'), including: receiving, by a device clustering mo ...

  8. layer的使用笔记

    $('#calendar').fullCalendar({ lang:"zh-cn", buttonText:{ today: '今天' }, eventLimit: true, ...

  9. 学好Java只需要做到这7点,年薪20W起步

    大道至简,所以扎实有用的方法,其实都是很简单的,难在踏踏实实的执行过程.今天为大家介绍的就是Java学习的7个看起来非常简单的方法,快学起来吧. 为什么要学习java? Java是目前最流行的编程语言 ...

  10. 扩展你的javascript数组

    如今做的项目用的正是jquery的框架,Jquery miniui,其功能强大.性能卓越.易于上手.不失灵活,在不断学习和研发的过程中,miniui给了非常多的启示,让我又一次认识了js的本质,意识到 ...