Some real FUD

[phil swenson]

This guy claims:

"Unfortunately, Java's designers didn't seem to value CPU time at all.
The language has a nasty reputation for sluggish interfaces, and its
execution speed drags well behind C++'s. Pointer aliasing or not we
are many generations of optimisers away from languages such as Java
overtaking C++ so if you need fast code C/C++ is the obvious choice."

article here:
http://slidetocode.com/2012/04/14/objective-c/

discussion here:
http://news.ycombinator.com/item?id=3840861

[Fabrizio Giudici]

On Sat, 14 Apr 2012 22:13:53 +0200, phil swenson <phil.s...@gmail.com>
wrote:

I posted another comment. For your reference, it's below.

"Unfortunately, Java's designers didn't seem to value CPU time at all. "

Well, it's obvious that people think of (Apple) fanboism when they read
such misinformation; apart from the fact that there's no point in writing
such statements without citing some numbers or real cases.

I can tell you that I've written my last line of C++ exactly ten years
ago. In these ten years I've designed and implemented a good deal of
industrial software in different segments and never experienced
performance problems. Already in 2004, which is ages ago, I designed and
implemented a near real time system for distributing telemetry data in F1
racing - among others, Renault won two championships running that system.
It was Java 1.4 and it worked pretty well. The specs were pretty
demanding. I recall people wondering whether Java was up to the requisites
(at the time it was a reasonable doubt, not today).

I am just lucky as I can mention a publicly known project, but there are
tons of people around who daily experience excellent performance with Java
and don't feel any desire to go back to C/C++. You'd just attend a couple
of Java conferences (or at least read the slides) before publishing
uninformed statements.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Robert Casto]

Ditto.

Stopped writing C++ even longer ago and have no  desire to learn Obj-C. And with Java I'm way more productive than I ever was back then. I know of a number of very large websites that have been ported to Java. You get a lot when you use the language. Good libraries and tools come to mind.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

www.lakotaeastbands.org

[Casper Bang]

Isn't it really quite simple: Managed and non-managed languages make different fundamental trade-offs, opting for either performance or productivity when these are in tension.

Empirical evidence suggests t's easier to develop an Android application, but harder to make it feel fast. While it's harder to develop an iOS application, it's easier to make it feel fast. In other words, it's rare (if ever) you hear of an implementation of an app that feels snappier on Android than on iOS - even if iOS hardware is often inferior.

/Casper

[Fabrizio Giudici]

On Sun, 15 Apr 2012 22:28:06 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> Isn't it really quite simple: Managed and non-managed languages make
> different fundamental trade-offs, opting for either performance or
> productivity when these are in tension.
>
> Empirical evidence suggests t's easier to develop an Android application,
> but harder to make it feel fast. While it's harder to develop an iOS
> application, it's easier to make it feel fast. In other words, it's rare
> (if ever) you hear of an implementation of an app that feels snappier on
> Android than on iOS - even if iOS hardware is often inferior.

Apart from the fact that the success of an application is a mix of
qualities, including stability (a fast crasher is useless), thus I find
normal to eventually trade off a bit of CPU for stability, the fact that
we need a trade off with Android today might be due to the fact that
Dalvik is relatively new and we know that VMs needs years to be optimized.
Probably in a few years Dalvik will be so optimized that we won't tell the
difference.

In any case, I don't own any iOS device, anyway my Asus Transformer (1st
version) is always perfectly snappy.

[Kevin Wright]

On Apr 15, 2012 9:28 PM, "Casper Bang" <caspe...@gmail.com> wrote:
>
> Isn't it really quite simple: Managed and non-managed languages make different fundamental trade-offs, opting for either performance or productivity when these are in tension.
>

Even that isn't strictly true.  There are two notable areas where a managed language will offer better performance:

1. Heavy churn of memory usage.  Bumping a heap pointer is significantly faster than malloc/free.  Yes, you can duplicate this in a non-managed language using e.g. placement new in C++.  You're basically just making your language a little bit more managed to achieve this though, and it's remarkably easy to royally screw it up when you do so.

2. A managed language will optimise jit compilation based on runtime metrics. These will change based on runtime data, and the framework can even make a speculative (but beneficial) optimisation, then revert if it turns out to be inappropriate.  A statically compiled language simply doesn't have this opportunity available.

> Empirical evidence suggests t's easier to develop an Android application, but harder to make it feel fast. While it's harder to develop an iOS application, it's easier to make it feel fast. In other words, it's rare (if ever) you hear of an implementation of an app that feels snappier on Android than on iOS - even if iOS hardware is often inferior.
>
> /Casper
>
> On Saturday, April 14, 2012 10:13:53 PM UTC+2, phil swenson wrote:
>>
>> This guy claims:
>>
>> "Unfortunately, Java's designers didn't seem to value CPU time at all.
>> The language has a nasty reputation for sluggish interfaces, and its
>> execution speed drags well behind C++'s. Pointer aliasing or not we
>> are many generations of optimisers away from languages such as Java
>> overtaking C++ so if you need fast code C/C++ is the obvious choice."
>>
>> article here:
>> http://slidetocode.com/2012/04/14/objective-c/
>>
>> discussion here:
>> http://news.ycombinator.com/item?id=3840861
>

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/KFgl26W0VSAJ.

>
> To post to this group, send email to java...@googlegroups.com.

> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Fabrizio Giudici]

On Mon, 16 Apr 2012 00:08:34 +0200, Kevin Wright
<kev.lee...@gmail.com> wrote:

> 2. A managed language will optimise jit compilation based on runtime
> metrics. These will change based on runtime data, and the framework can
> even make a speculative (but beneficial) optimisation, then revert if it
> turns out to be inappropriate. A statically compiled language simply
> doesn't have this opportunity available.

It's precisely this part that, as far as I understand, is still relatively
"young" in Dalvik. Can somebody point to a short existing document about
what kind of JIT optimizations are available for Dalvik in comparison to
OpenJDK?

[Casper Bang]

1. Heavy churn of memory usage.  Bumping a heap pointer is significantly faster than malloc/free.  Yes, you can duplicate this in a non-managed language using e.g. placement new in C++.  You're basically just making your language a little bit more managed to achieve this though, and it's remarkably easy to royally screw it up when you do so.

Right, but with a non-managed language you achieve a more deterministic runtime experience. So yes, one does have to be careful about how often to ask the kernel for memory, but at least it can be handed back to the OS again when no longer needed (unlike how the JVM behaves).

 

2. A managed language will optimise jit compilation based on runtime metrics. These will change based on runtime data, and the framework can even make a speculative (but beneficial) optimisation, then revert if it turns out to be inappropriate.  A statically compiled language simply doesn't have this opportunity available.

We're then stepping into this non-deterministic world where nothing is guaranteed. The problem that JIT compilers face is that of time constraints, they need to optimize but without incurring significant overhead to the *running* application. Android is pretty smart about this and tries to mitigate the overhead by offering pre-compiled applications (ODEX files) as well as serializing the JIT-traced code to the Dalvik cache.

However, none of this really matters to a user who just notices that scrolling around the screen in a browser, PDF or ebook reader feels snappier on an iPad than on an Android tablet.

[Fabrizio Giudici]

On Mon, 16 Apr 2012 09:19:04 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> However, none of this really matters to a user who just notices that
> scrolling around the screen in a browser, PDF or ebook reader feels
> snappier on an iPad than on an Android tablet.

I presume I can go to a store and play a bit with an iPad, but does exist
some comparison online? I'm really having no problems in speed with the
Adobe PDF reader (it's a semi-disaster for quality when rendering photos,
but it's another story).

[vjosullivan]

On Apr 15, 9:28 pm, Casper Bang <casper.b...@gmail.com> wrote:
> Empirical evidence suggests t's easier to develop an Android application,
> but harder to make it feel fast. While it's harder to develop an iOS
> application, it's easier to make it feel fast. In other words, it's rare
> (if ever) you hear of an implementation of an app that feels snappier on
> Android than on iOS - even if iOS hardware is often inferior.

Being lucky enough to own an Android phone and then being issued with
an iPhone for work I find that one issue relating to apps has dwarfed
all others. Despite the fact that it has only a quarter of the number
of apps installed as the iPhone, I cannot install an app without first
deleting another, whilst the iPhone appears to have a limitless
capacity for accepting new apps. I've pretty much reached the point
where I don't want to delete any of the existing apps on the Android ,
so anything new goes on the iPhone.

[Casper Bang]

Being lucky enough to own an Android phone and then being issued with
an iPhone for work I find that one issue relating to apps has dwarfed
all others.  Despite the fact that it has only a quarter of the number
of apps installed as the iPhone, I cannot install an app without first
deleting another, whilst the iPhone appears to have a limitless
capacity for accepting new apps.  I've pretty much reached the point
where I don't want to delete any of the existing apps on the Android ,
so anything new goes on the iPhone.

Older Android devices had a (relatively tight) limitation on space reserved on the device for installations. I believe this is an effect of a (cost saving?) design decision, where little internal embedded memory could get supplemented by a lot of external memory (SD). Later generations of Android (and CyanogenMod) allows you to move applications from in-memory to the SD card. It is however a good example of yet another thing that "should just work" and you are not the first person to complain about this. Having said that, the iPhone suffers from plenty of its own warts, nothing is perfect and it's always about compromises.

[Oscar Hsieh]

Problem with Pre-ICS android performance is that android renders in software.  3.0 supports hardware acceleration and ICS has it turned on by default.

Unfortunately only < 3% of android devices are on ICS. So in general IOS still feels a lot more snappier than Android.

http://www.theverge.com/2011/12/5/2612285/android-graphics-rendering-hardware-acceleration-explained

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.