A while back, I posted of FireFox 4 JavaScript engine running around Delphi when it came to floating point performance on the Mandebrot set, since then, Chrome got updated to version 11, and further raised the bar by beating FireFox by about 20% in that benchmark. That’s no mean feat: current generation JavaScript engines run not just faster than Delphi, but also .Net and a slew of other compilers, native or not, when it comes to floating point. Only state of the art native compiler still resist.
The figures for Delphi 64 are still unknown, but it’ll face a challenge merely matching the floating point performance of JavaScript, and if the VCL’s TCanvas hasn’t been revamped from the ground up, chances are that out of the box, Delphi 64 won’t be able to beat the HTML5 Canvas on performance (not to mention in features, where HTML5 Canvas is also leading by a few miles).
Jon L Aasenden is investigating an Object Pascal For JavaScript (OP4JS), with mobile devices in sight (if you don’t already know about it, you may also want to check PhoneGap). My experiments with the mobile WebKit that powers iPhone & Android browsers have been very positive, though some library are still a bit bloated for current hardware, using CSS3, HTML5 & libraries like XUI, it’s possible to design some excellent interactive UIs, in reasonably little time. Given the rate of improvements, in 1-2 years, libraries like jQuery Mobile should run smoothly on all the hardware being sold.
And add to that upcoming goodies, like WebGL, and JavaScript + HTML5 is step by step, with little fuss, despite all its shortcomings, becoming a universal platform with high performance potential. One could only wish JavaScript weren’t a dynamic language, but hey, after all, the x86 instruction set became prevalent despite its shortcoming too, and will still be serving in the 64bit era for the foreseeable future.
Even on the Windows desktop, it is IMHO becoming increasingly questionable to base your UIs on anything else than HTML5 & CSS, the alternatives are not only more proprietary, but either looking responsive but dated (like unskinned VCL, WinAPI controls), or outright messy and sluggish (WPF).
Right now, ChromiumEmbedded allows you to embark Webkit + Chrome V8 engine, which will work across the board with no update or dependency issues (unlike IE9), using Henri Gourvest’s Delphi ChromiumEmbedded, you can integrate it into your Delphi applications, and use it as an alternative to VCL-based controls for many aspects of an application’s UI.
Are you really proposing using a web browser to produce a Desktop GUI. That makes no sense to me.
@David Heffernan
it will make sense in a couple of years when you can easily write cross platform AND cross hardware apps. however it’s still debatable.
@David Heffernan
There are less and less things that an out of the box Delphi application can do better than a modern browser, and more and more things where it’s becoming inferior: skinning, animation, internationalization, even computations, the list goes on and on.
For instance, Delphi only support for anti-aliased graphics out of the box is TDirect2DCanvas, which is limited and restricts your application to Win 7… While HTML5 Canvas hardware support is near universal given WebKit’s ubiquity.
Once you allow your browser to break out of its box and read/write files or access hardware, like what PhoneGap does f.i., there are very few things where you’re limited.
@David Heffernan
I agree with you… That makes no senses at all.
But you saw that benchmarks. One of our beloved Delphi greatest features is efficiency. We loved to say we develop fast, deploy fast, compile fast and RUN fast.
If Delphi or any other language begin to slow down, I am one of the ones who will leave it alone… It would be a sad day… 🙁
@Eric
IDK if you tested that on your example. Theres a different performance when I start the soft and when I click in the “Reset” button. Using your pre-compiled example, I’ve got ~164,4 when start, ~254,8 “standard” when click in reset and ~103 SSE version, while got 115 in Firefox4 version on my Pentium E5300 2.6 GHz.
But using my Delphi 2010 compiled version, I’ve got ~164 when start or click, and ~126 SSE version.
@EMB
The difference with the “reset” button is due to another shortcoming of Delphi, on the original post, look down to the comment by Victor for an explanation. It all boils down to Delphi not properly aligning the stack, so when you have alignment-sensitive code (such as when doing maths…) the performance depends on the state of the stack.
@Eric
Ohh, I think I should reread comments when rereading posts…
But what made me comment about it in this topic is that in Delphi 2010 that is not a problem…
As Victor said: “I hope the new Delphi compiler will eliminate this”. That was not in an older compiler (neither in Delphi 7, I’ve tested it)…
@EMB
Alas the stack state is purely circumstancial, a change in any function called before the call to the Mandelbrot functions can result in a different stack, if a VCL function involved has an extra (or less) integer parameter on the stack f.i., it will change the alignment by 4 bytes.
Please have a look at Raudus. http://www.raudus.com. It is a framework to build web applications in Delphi.
@Igor Klopov
I gave Raudus a try a few months ago, was impressed, however the lack of source code is really annoying, not to mention the fact that back then I could install only in Delphi 7, I wanted in Delphi 2010
@Igor Klopov
It looks interesting, if a bit different. The lack of modern Delphi supports is very limiting, let’s hope it’ll make the jump into the Unicode world!
@Eric
yeah… you right… don’t you hate when random circumstances rules the behavior of your code?
@Eric That’s exactly what I want to do with DCEF, completely replace the VCL. One of the most interesting point with DCEF that is possible to invoke Delphi objects from javascript using RTTI.
Thanks for sharing this great info. i have never heard of that Delphi can write web applications.
@Igor Klopov