Page 18 of 21 « First 81617 18 1920 Last »
Reply
Thread Tools
attila77 is offline attila77
2011-02-28 , 22:56
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#171
Originally Posted by zimon View Post
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
 

The Following User Says Thank You to attila77 For This Useful Post:
lwa's Avatar
lwa is offline lwa
2011-03-01 , 00:09
Posts: 57 | Thanked: 26 times | Joined on Feb 2010 @ Melbourne, Australia
#172
Originally Posted by v13 View Post
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...
 
Joorin is offline Joorin
2011-03-01 , 06:39
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#173
Originally Posted by v13 View Post
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.
 

The Following User Says Thank You to Joorin For This Useful Post:
zimon is offline zimon
2011-03-01 , 10:43
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#174
Originally Posted by v13 View Post
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
 
zimon is offline zimon
2011-03-01 , 22:06
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#175
Originally Posted by attila77 View Post
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.
 
attila77 is offline attila77
2011-03-03 , 13:33
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#176
Originally Posted by zimon View Post
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
 

The Following 5 Users Say Thank You to attila77 For This Useful Post:
Kangal's Avatar
Kangal is offline Kangal
2011-03-04 , 04:00
Posts: 1,789 | Thanked: 1,699 times | Joined on Mar 2010
#177
Originally Posted by attila77 View Post
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!)
 
nicolai's Avatar
nicolai is offline nicolai
2011-03-04 , 09:49
Posts: 1,637 | Thanked: 4,424 times | Joined on Apr 2009 @ Germany
#178
Originally Posted by Kangal View Post
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)??
I think advantages/disadvantages of java and C++ aren't that important.

Originally Posted by Kangal View Post
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
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.

Originally Posted by Kangal View Post
With C++/Qt/QML;
-you get very responsive applications (no slow animations)
-less buggy* (easy to correct mistakes; this one's personal)
These points aren't important.

Originally Posted by Kangal View Post
-your work can be recycled and re-used for other systems (eg port to iOS)
-nearly as compatible as java-deployment
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
__________________
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker

-Donate-
 

The Following 3 Users Say Thank You to nicolai For This Useful Post:
attila77 is offline attila77
2011-03-04 , 18:17
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#179
Originally Posted by Kangal View Post
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)??
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.

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
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.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
javispedro's Avatar
javispedro is offline javispedro
2011-03-04 , 18:53
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#180
Originally Posted by zimon View Post
One of the reasons why Firefox slows down and "leaks" memory, which you notice after several days heavy use, is because it has been coded with C++ and it cannot use this extra running time information for optimization. It would be a useful and interesting experiment to port Firefox to use Java. Already Firefox uses XUL and Javascript (interpreted languages), which helps the situation.
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.
 
Reply
Page 18 of 21 « First 81617 18 1920 Last »

Tags
bada rox, dalvik, future, java haters, meego, meego?fail, nokia, sandbox sucks

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 11:41.

Contact Us - Home - Archive - Top