Natively Compiled Code: A Comeback?
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!
Natively Compiled Code: A Comeback?的更多相关文章
- 关于Natively Compiled Stored Procedures的优化
Interpreted Transact-SQL stored procedures are compiled at first execution, in contrast to natively ...
- SQL Server ->> Natively Compiled Stored Procedures(本地编译存储过程)
Comming soon! 参考: Natively Compiled Stored Procedures
- idea反编译失败 /* compiled code */的解决方法
最近在研究源码,但是我的idea有点奇怪,有的文件可以反编译,但有的文件反编译后方法内容是 /* compiled code */,查了下说是反编译失败了,都说是插件的原因. 然后我看了下idea的插 ...
- IDEA无法编译源码,IDEA查看源码出现/* compiled code */
打开Settings -> Plugins 搜索dec,选中,确定,重启,解决
- Java性能提示(全)
http://www.onjava.com/pub/a/onjava/2001/05/30/optimization.htmlComparing the performance of LinkedLi ...
- 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 ...
- 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 ...
- 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 ...
- 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 ...
随机推荐
- Erlang入门
Erlang简史(翻译) Erlang入门(二)—并发编程 Erlang入门(三)——分布式编程 Erlang入门(四)——错误处理和鲁棒性 Erlang入门(五)——补遗
- ag-admin部署使用心得
开源地址:https://github.com/wxiaoqi/Spring-Cloud-AG-Admin(后端)https://gitee.com/geek_qi/AG-Admin-v2.0(后端) ...
- 亲测有效,解决Can 't connect to local MySQL server through socket '/tmp/mysql.sock '(2) ";
版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/hjf161105/article/details/78850658 最近租了一个阿里云云翼服务器,趁 ...
- TensorFlow: couldn’t open CUDA library cupti64_80.dll、InternalError: Blas SGEMM launch failed
1. couldn't open CUDA library cupti64_80.dll Win10 TensorFlow(gpu)安装详解 在资源管理器中查询 cupti64_80.dll 的位置. ...
- vim note (2)
:e edit :edit edit :e. edit current file '.' a dot is means current : w writ ...
- ServletContextListener和ContextLoaderListener的区别
ServletContext 被 Servlet 程序用来与 Web 容器通信.例如写日志,转发请求.每一个 Web 应用程序含有一个Context,被Web应用内的各个程序共享.因为Context可 ...
- [福利] 开发者必备的 Chrome 插件——ChromeSnifferPlus
Chrome Sniffer Plus: Chrome 探测器,可以探测正在使用的开源软件或者 js 类库,开发者必备. 通过本插件,您可以探测: javascript 库: jQuery.ExtJS ...
- sql 连接查询
什么是连接查询呢 概念:根据两个表或多个表的列之间的关系,从这些表中查询数据. 目的:实现多个表查询操作. 分类 首先划分一下,连接分为三种:内连接.外连接.交叉连接 内连接(INNER JOIN): ...
- jquery.uploadify上传图片,点击保存按钮无法使用解决方法
用Chrome浏览器上传商品图片时,保存按钮无法点击,如下图 原因:Flash插件状态为禁止 或 询问(默认) 解决方法:将Flash插件状态改为允许,如下图
- Visual Studio - 为默认模板添加版权信息
转自:http://www.cnblogs.com/easyzikai/archive/2012/10/14/2723328.html 和 http://www.cnblogs.com/eagle19 ...