A quick Google search informs, that:
* Microsoft is very quiet on WPF development. I guess they have to be, in order to support the new HTML5 strategy.
* Discussions on blogs about WPF+Silverlight contain a lot of "It will still run on Windows 8" - but not "This is how apps should be built today" or "WPF is still Microsoft's strategy for making Windows 8 apps"I am not surprised. Microsoft keeps renewing itself, by abandoning old development tools. It has been this way ever since... well... forever. Who knows, maybe they will invent a new paradigm for NUMA cpus, that abandons compatibility with programming languages based on Garbage Collection. Or they will adopt Python and a new version of C++ as their new primary development languages. If you're in doubt whether these statements are jokes from my side or not, don't worry. I'm in doubt, too, and Microsoft does not really explain the choices this time. Explanations don't seem necessary any more, other things are more important, things move on, and "developers, developers, developers" is history.
Interestingly, Delphi 1 source code made in 1996 still compiles with Delphi XE today, with the same GUI forms, and it still outperforms .net and Java on speed, while having a similar complexity level and developer productivity. Now, this is impressive technology.
12 comments:
Alas, those days that statement about Delphi still outperforming isn't true IME, even JavaScript (in FireFox & Chrome V8) can outperform Delphi...
Further proving that my decision 10 years ago to stick with native development using Delphi was the correct one.
Native + HTML5 + Javascript is the future.
Does Microsoft's ever-shifting development landscape remind anyone else of Joel Spolsky's classic Fire And Motion article?
That's why Delphi is the best solution :)
Eric, I can show you benchmarks that demonstrate how Delphi and C++ perform equally well, and better than .net and Java. If you can show me benchmarks that demonstrate that JavaScript perform even better, please do.
Lars, see http://delphitools.info/tag/javascript/
or directy try
http://www.atopon.org/mandel/
and compare with a Delphi version of the code for yourself.
Thank you for the links. I can see that this relates to the use of GPUs for acceleration. Most other languages, including Delphi, only uses CPUs - so JavaScript may beat other languages in very computation intensive algorithms.
Alas no, Lars, look again, there are no GPUs involved in the links I provided. This is pure CPU-side computation.
(the source code is provided)
And this is no a benchmark oddity, I've since observed it on a variety of workloads.
1) The actual Delphi compiler is really obsolescent, especially when it comes to floating point computation (AFAIK it doesn't use SSE and the like)
2) Any standard graphical output will involve GDI calls. Since Vista GDI does no longer take advantage of hardware acceleration (in 7 only very partially).
Whatever HTML/Javascript do must be translated into CPU/GPU code as well, everything depends on how well that tranaslation is done. Of course if your compiler choses in 2011 to be still 80386 compatible, its code will be slow...
Eric, looking at it, I still don't see a benchmark that I can relate to... and I don't see any confirmation elsewhere that JavaScript should be faster than non-script languages. Do you have some kind of documentation that is more solid, that you can refer to? I can refer to this or this, that show that JavaScript on V8 is slow.
Benchmarks are interesting, especially when they are not designed to highlight a certain positive aspect of one of the contenders. When I look at the kinds of stuff that we do, health care systems with a lot of data and advanced high-performance algorithms, there is no doubt that we beat almost all alternatives with regard to speed. But we achieve this using a combination of architecture, algorithms and the Delphi compiler, and getting memory management out of algorithms is critical. Fortunately, Delphi makes this very easy and natural.
When my good friend Jesper made his language benchmarks, he picked an algorithm that was very relevant for the kind of stuff we do - and the fastest contributions were Delphi code that was natural, simple and very easy to read - unlike Java, .net and probably JavaScript if somebody had submitted something in that.
For now, I will still consider JavaScript to be significantly slower than compiled languages, and my best guess is, that normal, hand-written JavaScript will continue to be slow, and one reason is untyped variables. An intelligent compiler may sometimes be able to type an untyped variable, but not always.
About just any case where heavy floating point computations are bottleneck can see modern JavaScript engines come ahead of Delphi.
If all you're dealing with are integers, like in your benchmark you refer, the old Delphi compiler can still be competitive, but that's a restrictive area.
Current JS engines have advanced beyond untyped containers, FireFox has a tracing compiler, V8 uses hidden classes, that's what allow both of them to beat Delphi in numerical benchmarks, as they'll compile to straight SSE2 floating point instructions.
Note that in the links you provided JavaScript doesn't sit alongside PHP or Ruby, but with the JITted languages, and in the floating point matrix multiplication benchmark, see for yourself how Delphi would fare.
Floating point calculations are evil - they introduce rounding mechanisms, that are usually handled as "noise", which basically means that code become non-deterministic. This is not a big problem in Mandelbrot, but it is when it comes to applications that involve money, statistics and technical calculations. Also, in order to make algorithms work well, they are usually based on integers for indexing and flow control.
Post a Comment