Meego vs Android apps (C or Java?) - Page 18 - maemo.org

Active Topics

The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 20 hrs, 5 mins ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 8 hrs ago
more...

Page 18 of 21

Thread Tools

attila77	2011-02-28 , 22:56
Posts: 3,319 \| Thanked: 5,610 times \| Joined on Aug 2008 @ Finland	#171

Originally Posted by zimon

Why VM wouldn't know about physical memory layout and architecture? There is not reason VM couldn't be clever like that.

Because it has no HW level access and only knows whatever the kernel tells it to. It's been a problem even for native apps, every now and then somebody thinks that the OS is not smart enough to deal with memory on a large scale and tries to implement their own tricks (to outsmart swapping, etc). This invariably either backfires or has very specific use-cases.

In the (in)famous "Java will be faster and C++" tells also that VM can also know how many and what kind of processors (how many registers, what is the size of L2 cache) the platform where it is running has. It can monitor page fault rate especially in multi-core platforms or if a program is interactive and sometimes is not doing anything. On the other hand, fully compiled C++ code cannot be optimized so well because it has to fit to some minimum common architecture or have multiple compilations.

This was the promise 10 years ago when I was heavily involved with Java, however those super-HW-optimized JVMs have never materialized. What has materialized were various JSRs which are mostly hated very passionately as they managed to make Java one of the (if not THE) most fragmented mobile platform.

Of course C++ can be also JITed and interpreted, but then why use C++ after that when there is Java which seem to be more productive than C++, easier to maintain, easier to read, easier to fix and find bugs?

Easier to read ? Maybe some templates or non-Qt stdlib code, but other than that... I for one don't miss Java's verbosity. Plus C++ is most of the time faster even without JIT, exists on far more platforms and hasn't got the problem of a megacorp deciding it's (and its developers) fate.

It is probably true, not yet for example Dalvik has all these fancy optimizations, but if it lives long enough it will, especially now when mobile platforms have started to get multiple CPU cores.

Actually that's one of the shortcomings of Java - people seem to be using threads by the boatload (mostly inertia as AIUI it's not necessary since Java 5), and threads make those optimizations nigh impossible. And we know that, as Alan Cox said, threads are for people for don't know how to program state-machines

But anyway, we're running in circles for some time now. You say it will be better - I say, whatever floats your boat, but reality can be really uncooperative when it comes to these academic explorations. Over and out.

__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc

Quote & Reply |

The Following User Says Thank You to attila77 For This Useful Post:
v13

	lwa	2011-03-01 , 00:09
	Posts: 57 \| Thanked: 26 times \| Joined on Feb 2010 @ Melbourne, Australia	#172

Originally Posted by v13

Let's assume that MeeGo is released and that it's awesome.

First mistake... :P

In all seriousness though, Dalvik in a centralised marketplace to reach androids market share is going to win vs Meego and Ovi, app up, other 3rd party markets... Even if you buy a Meego device there would have been no guarantee your favourite Meego application was even in the vendors app market..

People keep saying that getting multiple versions for multiple architectures inst a big deal... but if you say to a developer:

"all you have do is recompile it for 3 different architectures, then test all 3 versions, then upload those 3 versions to 3 different app markets... its only uploading, getting approved then managing 9 individually hosted distributions of your application, and congratulations, you have now reached 5% of the smartphone market..."

Vs.

"compile it, test it, then upload to android market and you now have ~35% of the smartphone market"

Sure I might have missed a few minor details, but seriously, what would be the benefits to a commercial developer (who have multiple employees to pay) to develop for Meego...

Quote & Reply |

Joorin	2011-03-01 , 06:39
Posts: 726 \| Thanked: 345 times \| Joined on Apr 2010 @ Sweden	#173

Originally Posted by v13

I believe that we're talking about the same thing (but I may be wrong). First, I don't understand how pagefaults are related to memory fragmentation. In fact, I'd think that pagefaults are an inverse function of memory fragmentation since with fragmentation it would be possible to reuse the same memory without needing a pagefault to extend the process's VM.

Typically, a (hard) page fault is triggered when a memory access is done to memory that's not mapped into the running process' memory space (virtual memory) or when a page of memory, that was previously mapped into the running process' memory space, has been swapped out.

This is the most costly scenario since it, typically, includes loading things from secondary storage (a hard drive). In most mobile devices this would be some kind of flash, but it is still order of magnitudes slower to read from compared to primary storage (RAM).

So, by keeping track of which parts of the allocated memory is accessed the most, and moving these parts together, it is less likely that this page (or pages) will be pushed to swap. This avoids the costly (hard) page fault.

On top of this you have cache misses. Typically a cache miss forces the CPU to empty its pipelines and wait for the cache to be filled. Seen from a computational perspective, this is both costly and wastes CPU time. By minimizing cache misses, you get more time spent doing actual work and less waiting for the cache to fill.

By moving the most active memory segments together, you increase the chance that the cache will contain the needed memory after it has been filled.

So the question stands: Do you have any (comparable with java) example of memory fragmentation in C under Linux?

I'd say this comes down to allocation patterns. Pointing at a specific application feels a bit odd (even if FireFox, apparently, is a candidate of sorts).

If I were to guess, most GUI applications would be interesting candidates since you have a constant flow of event objects (or structs) being allocated and then deallocated to handle user input mixed with allocation of data actually used to perform what the user wants.

With analysis done to keep track of the lifetime of these objects, the "dinosaurs" can be moved away from the "bacteria", separating long lived (being a relative term here), but perhaps not so often accessed, objects from shorts lived ones. Which is one of the ideas behind the memory management in the JVM.

Quote & Reply |

The Following User Says Thank You to Joorin For This Useful Post:
zimon

zimon	2011-03-01 , 10:43
Posts: 1,341 \| Thanked: 708 times \| Joined on Feb 2010	#174

Originally Posted by v13

I believe that we're talking about the same thing (but I may be wrong). First, I don't understand how pagefaults are related to memory fragmentation.
....
So the question stands: Do you have any (comparable with java) example of memory fragmentation in C under Linux?

Major cache misses will happen if the fragmentation goes too far and OS need to start swapping for process to reach alive objects from the heap memory.

CPU L2-cache misses happen when CPU doesn't have the data it needs in its L2-cache. Fragmentation of heap memory first affects this rate of cache misses, when for example in some inner loop needed data are scattered around heap memory and most probably also around physical memory pages so L2-cache size won't be enough to help locality of the hot objects. It can be huge speed penalty, because reading from RAM is getting all the time more slower proportionally than reading from CPU L2-cache.

Having good locality of objects in code hotspots is coming more and more important. More fragmented the heap memory is, worse the locality of alive new (and old) objects will be. The solution is to use defragmentation for example with moving memory GC, but it cannot be done with C++ (effectively).

I do not currently have any other example but my observations with Firefox when I use it alot and it slows down, until I restart with exact same session (tabs, pages) which were running.
But many of the Java vs C++ speed tests start to show already what advantage adaptive optimizations in VM can make.

Last edited by zimon; 2011-03-03 at 17:00. Reason: fixed

Quote & Reply |

zimon	2011-03-01 , 22:06
Posts: 1,341 \| Thanked: 708 times \| Joined on Feb 2010	#175

Originally Posted by attila77

Because it has no HW level access and only knows whatever the kernel tells it to. It's been a problem even for native apps...

JVM and most (all) of the VMs are native apps. It is a lousy OS if it doesn't let applications know information which benefits the user. Linux for example lets apps know (/proc/cpuinfo)

This was the promise 10 years ago when I was heavily involved with Java, however those super-HW-optimized JVMs have never materialized.

True. Not yet. I think it was waiting for multi core platforms as profiling from one thread other threads executing needs to be smooth and not increase latency.

What has materialized were various JSRs which are mostly hated very passionately as they managed to make Java one of the (if not THE) most fragmented mobile platform.
Easier to read ? Maybe some templates or non-Qt stdlib code, but other than that... I for one don't miss Java's verbosity. Plus C++ is most of the time faster even without JIT, exists on far more platforms and hasn't got the problem of a megacorp deciding it's (and its developers) fate.

The above is somewhat true, and reasons why Google has Dalvik nowadays. It is a shame if Oracle+IBM+Google can't eventually get their stuff together and give Java the improvements it needs especially in those political issues.

All what has been said about JVM goes also for Python VM, if just dynamic types could be somehow guessed or forced to static types somehow (Psyco, Python 3). Dynamic types makes optimizations difficult, but are not so big obstacle as pointers are.

Actually that's one of the shortcomings of Java - people seem to be using threads by the boatload (mostly inertia as AIUI it's not necessary since Java 5), and threads make those optimizations nigh impossible. And we know that, as Alan Cox said, threads are for people for don't know how to program state-machines

Threads work and are useful when you have multiple Turing machines running at the same time. Sure, you can simulate them in this one Turing machine but that is not for example how nature does it because it would be too slow.

But anyway, we're running in circles for some time now. You say it will be better - I say, whatever floats your boat, but reality can be really uncooperative when it comes to these academic explorations. Over and out.

Yes it is still abit academic. But I don't think we were running circles because there were these recent issues with Qpointers which as shown are not as effective solution either to the heap memory fragmentation problem.
But I hope many have learned new ways of thinking things and remember fully compiled code is not necessary the fastest in all use cases of programming (OOP).

And I wonder, if Nokia would had got Meego phone ready in the last year already if it would had used Python (+Qt) to develop UX and not C++ (Qt+QML). C++ is known to have poor productivity especially in group work and very especially when using offshore outsourcing.

Quote & Reply |

attila77	2011-03-03 , 13:33
Posts: 3,319 \| Thanked: 5,610 times \| Joined on Aug 2008 @ Finland	#176

Originally Posted by zimon

JVM and most (all) of the VMs are native apps. It is a lousy OS if it doesn't let applications know information which benefits the user. Linux for example lets apps know (/proc/cpuinfo)

cpuinfo is not really what I was getting at - what it comes down is that memory management *cannot* be handled independently by applications/processes because there is not a single winning strategy - in fact, it's a bit like the Prisoner's dilemma. Firefox fails at this, but it is by choice, to obtain as much platform independence as possible.

And I wonder, if Nokia would had got Meego phone ready in the last year already if it would had used Python (+Qt) to develop UX and not C++ (Qt+QML). C++ is known to have poor productivity especially in group work and very especially when using offshore outsourcing.

As someone who works both with PyQt/PySide and QML&C++ on a daily basis, my experience is that QML alone beats off the pants of 'classic' Python+Qt, both in terms of performance, 'productivity', and last but not least end-user appeal. The ideal setup is IMHO Python+QML for extremely quick prototyping and then gradually replacing the Python functions with C++ for better resource usage & performance.

__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc

Quote & Reply |

The Following 5 Users Say Thank You to attila77 For This Useful Post:
Capt'n Corrupt, jstokes, MartinK, mmlado, zimon

	Kangal	2011-03-04 , 04:00
	Posts: 1,789 \| Thanked: 1,699 times \| Joined on Mar 2010	#177

Originally Posted by attila77

it's like Prisoner's dilemma.
The ideal setup is IMHO Python+QML for extremely quick prototyping and then gradually replacing the Python functions with C++ for better resource usage & performance.

Okay ... but how would a mobileOS constructed around Python+QML fare against one such as Dalvik+JIT ?

1) Do the advantages of C++ (or Qt/QML) outweigh the advantages of java (or Dalvik/VM)??

2) Does the disadvantages of java (Dalvik/VM) outweigh those of C++ (or Qt/QML)??

Based on my newbie-view (you can stop reading here if you want)
the way I see it with java;
-you get the advantage that its "easier" to develop
-more people know java coding, perhaps more developers
-works everywhere as long as the VM/engine is there

With C++/Qt/QML;
-you get very responsive applications (no slow animations)
-less buggy* (easy to correct mistakes; this one's personal)
-your work can be recycled and re-used for other systems (eg port to iOS)
-nearly as compatible as java-deployment

I would ultimately prefer a C++/QML based OS over java/Dalvik because it would mean higher quality of applications. Example, the psx emulator would run fullspeed on the MotoDroid (no overclock), everything would be at iPhone smoothness, perhaps faster and safer updates. I mean, its feeling like java's performance is plateu-ing whereas a layer deeper (QML) would mean a better user experience and probably even better battery life if done correctly (see the iPhone battery life, for example). Android is the next best thing for me, but right now it seems to be the better option for the masses (thoses asses!)

Quote & Reply |

	nicolai	2011-03-04 , 09:49
	Posts: 1,637 \| Thanked: 4,424 times \| Joined on Apr 2009 @ Germany	#178