July 29, 2013
There have been a few recent article around compiled code for mobile devices that you might have seen... but if not are worth checking out.
There have been a few recent article around compiled code for mobile devices that you might have seen... but if not are worth checking out:
-
Wired has a very long article on the LLVM technology, very interesting despite the sensationalist title ("The One Last Thread Holding Apple and Google Together"). It covers the origin of LLVM, how it is used by Apple in Xcode, how Google uses it for server side software, and the open ideas of using it for portable client applications.\
-
JT covers
llvm-an-emerging-industry-standard
in a blog post, commenting on the article above (I echo his comments below)
- A very popular writing a couple of weeks ago (still worth checking) is
Why Mobile Web Apps Are Slow
, in which the author clearly claims mobile apps need to be compiled and explains why with lots of technical details and numbers (I know, hard to have the perfect numbers backing a claim, but some of those in the article are interesting).
- On the same line, I read a paper by Kinvey (not public, sorry) pushing mobile compiled apps (backed by their services, of course) compared to the pure JavaScript solutions some of their competitors are offering. They also go back to the Facebook going native story with some details. Interesting read.
- Jim McKeeth (welcome on board!) has a nice piece echoing the paper above and commenting on it at delphi.org/2013/07/why-mobile-apps-web-are-so-slow/. Needless to say Delphi is fully in the compiled apps camp.
Some comments are needed:
- As you probably know, Delphi uses LLVM for its iOS toolchain. In the future, LLVM is also going to power the Android offering. So even if not fully up to the level of portable client apps, we have the goal of single source mobile applications (and desktop too). C++Builder also uses LLVM for its 64 bit version. Embarcadero has all intentions to increase its leverage LLVM and the related tools in the future. (Side note: we are not so totally closed to open source as some of our detractors claim.)
- While Delphi LLVM compiler uses ARC, as well as Xcode, the potential slow down is linear with use and takes place only at the very time you are allocating or freeing memory, and is very limited with each operation. At the opposite, garbage collected systems stop the running up to do their cleanup, creating non-linear response time to actions.
- We know we have some room to optimize the FireMonkey framework, but the overall architecture (including GPU specific hooks) offers us room for improvement. And, as demonstrated by third parties, you can also go native on iOS controls.
- While on iOS Delphi uses the same tricks of the platform tool (Xcode), the situation will be very different on Android. How many tools offer a native solution, with Google pushing application developers towards the Dalvik VM? The Delphi community will have some interesting times ahead.
PS: Sorry again for being slow with blogging, hoping to get back to a more regular schedule. Seems that when I travel (even if to visit Embarcadero offices like in the last two weeks) I end up with less time for blogging.
posted by
marcocantu @ 1:23PM | 10 Comments
[0 Pending]
10 Comments
LLVM and Mobile App Speed
Small typo - 'we are not so totally close to open
source' should presumably be 'we are not so totally
closed to open source'.
Comment by CR on July 29, 14:28
LLVM and Mobile App Speed
LLVM sounds like the way to go. When is the Delphi
version for Andriod coming? Desperately need to get
started.
Comment by Godfrey on July 29, 14:35
LLVM and Mobile App Speed
CR, thanks, fixed. Fixed also spelling of Xcode, suggested by another
reader.
Godfrey: Delphi for Android is coming this year.
Comment by Marco Cantu
[http://www.marcocantu.com]
on July 29, 14:42
Embarcadero is not Apple nor Google.
It's worrying people at Embarcadero don't understand
it is not Apple nor Google. The former is an hardware
vendor who understood it can also extort a 30% fee on
someone else software running on its mobile devices,
the latter is a data collection and reselling
company. Both have a great interest in reduce
expenses on software development to increase profits
in their core businesses.
But Embarcadero is a development tool company,
thereby the more it relies on software developed
elseswhere, the less appealing it becomes as a dev
tools supplier. It becomes just a VAR, reselling
software it can't control the agenda, especially it
two giants like Apple and Google use them as well.
MS, that still makes money selling software and not
hardware or data, knows very well it has to keep on
developing its own development tools to control them.
It's a real pity Emb is still selling us its lack of
development capabilities as a "clever move" to open
source software while it is not.
Comment by Luigi D. Sandon on July 29, 15:12
LLVM and Mobile App Speed
I hope, the slow LLVM will never touch the Delphi
Win32/64 desktop tool chain! Delphi compile time rocks.
Comment by Peter on July 29, 15:58
LLVM and Mobile App Speed
"we are not so totally closed to open source as some
of our detractors claim". Hmmm...I wonder to whom you
are referring. For the record, while I am critical of
some of EMBT's decisions, I love the product, and
voice my opinions not to slam EMBT, but to encourage
some feedback from them in a public forum, and
hopefully get them to consider some changes.
Unfortunately, EMBT has been pretty silent, except for
labeling people who voice such opinions as detractors
and dismissing anything they might say.
Care to elaborate on EMBT's strategy for open source
or comment on anything I posted?
Comment by Larry Hengen
[http://www.tpersistent.com]
on July 29, 16:55
LLVM and Mobile App Speed
I think the investment in LLVM is one of the smartest
moves Embarcedero has been doing since a long time.
Building an optimizing compiler is hard work, the
competition on this front especially from C++ is very
grim.
Delphi was never strong on floating point performance,
with the use of LLVM, the chances are we will finally
see a compiler that is not focused on just producing
business apps.
Furthermore it gives the potential to integrate many
compiled languages into one product. Think of it as
.NET without a VM.
Only a really open platform makes this really extensible.
If a company like Embarcadero invests and gives back
code to the open source community, I am much more
willing to pay for the product, since I know I am
making a long term investment. Otherwise I feel I
payed for the current state, but am not part of nor
own anything. Building loyalty means trust and giving
people a way to influence course of things. I
acknowledge it's not an easy balance to find.
What I am worried about is that it still seems EMBT
lacks the resources to build a really quality product
and kill the many little bugs that make working on
some projects pretty unproductive: E.g., generics, but
also other code that came from Delphi 7 that sometimes
crashes the XE3 IDE just by browsing code, sometimes
code browsing works, often not, for no apparent reason
(paths are set up correctly) or bugs in code insight,
inconsistent behavior of compiler or some features
that weren't thought through properly.
I acknowledge this is a very big undertaking, and
requires a lot of organization and effort.
Using LLVM was definitely the right choice. Focus on
your strength and stop reinventing the wheel, instead
enrich the landscape using your unique talent.
With the right mix of open and commercial parts in
Delphi I think it could become a really interesting
project again.
Programmers want to be in control, that's why many of
us became programmers. Give us the control, that's why
people like open source.
But even open source will not fix everything. What
truly matters is open communiction and a decision
making process that involves the community, the people
who use the product. And one where the influence is
tangible in a reasonably short time period.
An excited environment that works towards that goal.
That's why LLVM is such a fascinating project, many
people from various domains working on one product and
managing to gradually improve quality and make it more
awesome.
This is what truly matters, the other important part
is safety of investment. I.e., not being left
investing time and money in a dead end.
Opening and giving more people the chance to influence
the product strengthens this trust.
Maybe it would make more sense to sell the workforce
you put in the product, instead of the product itself.
Classical example would be again, employees working on
open source code. Maybe you can come up with better
business models with similar advantages for the customer.
Comment by Maël Hörz
[]
on July 29, 17:43
LLVM and Mobile App Speed
It will be interesting to see how Delphi/FireMonkey
compares performance wise to Java/Dalvik, especially on
low end devices with limited memory (512MB) - as this is
where Garbage collection generally does very poorly, and
currently there are a lot of these devices being sold.
Comment by Alister Christie
[http://LearnDelphi.tv]
on July 29, 19:54
And what about Intel Atom x86 support in XE5 for Android part
Hi Marco! Good to hear any news about Android for
Delphi.
Intel finally came to her senses and decided to go to
the mobile market is fully prepared:
http://www.engadget.com/2013/01/08/lenovo-k900-intel-
clover-trail/ - low price, great perfomance and
competitive baterry life, and its not even Bay trail-T!
So, in light of these events, can we expect in the
incoming XE5 Delphi for Android, support not only for
arm native code, but also generation of native code for
the Intel Atom x86 platform?
Comment by Sergionn on July 30, 06:47
LLVM and Mobile App Speed
Disagree on the "detractors" wording, Marco. Most of the
people that criticizes EMB for their decisions are
actually fans and supporters.
It's just tough love. EMB does a lot of weird stuff that
makes them look bad, and open source is one of them
(using FPC code and not contributing back is a major
snafu, IMHO.)
Comment by Leonardo Herrera on August 5, 20:28
Post Your Comment
Click
here for posting
your feedback to this blog.
There are currently 0 pending (unapproved) messages.
