attila77 | # 171 | 2011-02-28, 22:56 | Report

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.

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.

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.

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.

lwa | # 172 | 2011-03-01, 00:09 | Report

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...

Joorin | # 173 | 2011-03-01, 06:39 | Report

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.

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.

zimon | # 174 | 2011-03-01, 10:43 | Report

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

zimon | # 175 | 2011-03-01, 22:06 | Report

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)

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.

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.

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.


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.

attila77 | # 176 | 2011-03-03, 13:33 | Report

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.

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.

Kangal | # 177 | 2011-03-04, 04:00 | Report

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!)

nicolai | # 178 | 2011-03-04, 09:49 | Report

I think advantages/disadvantages of java and C++ aren't that important.

This is a funny argument. And so many people think it is one
reason why android is more succesfull than maemo/MeeGo
could ever be.
It is true, there are many java developers,
and it is true android is a "java based" platform.
But, applications for Apple IOS are written in Objective-C!
Do you know how many developers know Objective-C compared
to developers who knows java?

There aren't good programs for the android platform just becaus
andriod is "java based", or because there so many java
developers. All the good android programs are written by
java programmers because it is a java platform.

These points aren't important.

This is important, but not java/C++ dependent.

There are two big advantages for android over maemo.
- More android devices and they are considered as
mass market product. Not like any maemo device.
- Android is one big consistent platform whereas maemo is
a more loosly combination of desktop linux components.

The second point is what Nokia tried to solve with MeeGo.
MeeGo is a more "closed" or "all-in-one" platform than maemo.
The underlaying programming language isn't that important
for a successfull mobile device. It has to be a really good
platform. With good
- application frameworks
- systemintegration,
- development environment,


Nicolai

attila77 | # 179 | 2011-03-04, 18:17 | Report

Depends on the type of your application (though the comparison is somewhat apples to oranges). No silver bullet, some things are easier to in one, some in the other.

Can't really agree - C(++) is the one that can go to (almost any) platform, Qt alone *officially* addresses ~12 platforms. Dalvik is not a full Java VM so while generic code is transferable, APIs aren't. Android code runs only on Android, and even in the 'real' Java world there are only IIRC 4 officially supported Java platforms plus a few more have it through OpenJDK and Harmony. Java was sort of popular in mobiles through J2ME prior to the iPhone world, but compatibility-wise, that was fragmentation hell. I agree there are more Java programmers nowadays, but whether it's easier... maybe, I would say it's fairly subjective in this context - Qt does make a lot of the C++ ugliness go away (personally, I like C++ w Qt more than Java, but I like Java more than stdlib based C++), and the doing the UI in QML usually makes the C++ part reasonably short.

javispedro | # 180 | 2011-03-04, 18:53 | Report

Actually, you were partially confused there. What they found out is that Firefox ran faster when built in a optimize-for-size configuration instead of a optimize-for-speed one.

Why? Because the Mozilla codebase is so large that a optimize-for-speed configuration meant that many useless functions where enlarged senselessly, thus increasing the binary size, thus increasing load times (specially code paging in times), and reducing code cache effectiveness.

A JITted or partially interpreted language would have runtime knowledge and optimize-for-speed only the hottest functions, thereby solving this problem.

However, C/C++ already has a partial solution for that: profile-guided code generation. Obviously, the results are not as accurate as the above solution but are "good enough" for most common needs.