Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (5)
to General by teroyk - 6 days, 3 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (118)
to SailfishOS by nieldk - 6 days, 9 hrs ago - more...
 |
|
2011-02-08
, 01:08
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#102
|
Originally Posted by zimon
What noone says is that there's an attached memory cost on this. Memory might be cheap on desktops (I'd disagree) but not yet on mobile... And, you know, if I were to waste more memory most algorithms have better ways to do it.
When there is an application, which needs lots of "short" living dynamic memory, and needs to run relatively long time, for example www-browser with tab-support; JIT-interpreted code (Java) will be eventually faster than fully compiled code (C, C++).
Most of the already known running-time profiling+optimizing techniques are not yet implemented nor in use in VMs. Just think VM able to reorganize memory objects in heap memory so L2-cache usage is optimized. That trick cannot be made to fully compiled code, but can be made to bytecode based running programs.
The other statement, that it can't be done to fully compiled code, is plain wrong. Previous week I was watching Intel-made slides about how there's various research teams trying to do exactly that (and some more optimizations that you can do when you start getting runtime information).
In fact, Transmeta used to do that (as attila already pointed out).
Last edited by javispedro; 2011-02-08 at 01:10.
| The Following User Says Thank You to javispedro For This Useful Post: | ||
 |
|
2011-02-08
, 02:19
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#103
|
Originally Posted by attila77
Seriously?
Zimon, theory is one thing, reality is another (otherwise we'd be using lisp or prolog). 5-10 years after the papers you mention and a few million (billion?) $ thrown at it by Sun and Google, it's still 'not there yet'. Android giving in to the pressure and being polluted by native code tells the story pretty well. And people wanting to earn their bread and/or geek creds writing code are doing it today - we're talking about *today's* technologies, not the hypothetical performance in some unclear point in the future.
PS. As for time critical - in mobile space 'slow' translates into 'power-hungry' (because it goes against race-to-idle, etc).
Regardless of reality, that argument is invalidated by the most basic logic. Just because something has not been done, does not mean it cannot be done.
|
|
2011-02-08
, 09:43
|
|
Posts: 303 |
Thanked: 146 times |
Joined on Aug 2009
|
#104
|
Originally Posted by Capt'n Corrupt
FFS... When you plan to buy a house, do you look at what is available on the market now, or do you look at futuristic designs that MIGHT come in 30 years?
Seriously?
Regardless of reality, that argument is invalidated by the most basic logic. Just because something has not been done, does not mean it cannot be done.
When you buy a car, do you look at the cars there are now on the market, or the cars that will fly?
The Java/VM/JIT being faster than native code with the right tweaks is the biggest bunch of crap ever. How can someone sane believe that compiled code can't do the same stuff that VM/JIT code does? You never heard of stuff such as:
if(platform)do_platform_optimized_stuff();?
Or: If(have_sse)do_sse(); else do_non_sse();
There is NOTHING faster than native code (preferably well written ASM code). When you have the runtime code doing stupid stuff like garbage collection or enforcing array limits, there is a big speed penalty. Remember, the fastest code is the code that is not executed.
There is absolutely no reason for garbage collection, except to accommodate lazy/newbie programmers. Same with not using pointers because omfg, they are evil.
Last edited by Radu; 2011-02-08 at 09:47.
 |
|
2011-02-08
, 11:14
|
|
Posts: 1,637 |
Thanked: 4,424 times |
Joined on Apr 2009
@ Germany
|
#105
|
There is only one truth:
If you ask a developer, what is the best/perfect/fastes ...
programing language. And he/she answers language XY,
then he/she isn't a well experienced developer.
nicolai
If you ask a developer, what is the best/perfect/fastes ...
programing language. And he/she answers language XY,
then he/she isn't a well experienced developer.
nicolai
__________________
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker
-Donate-
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker
-Donate-
| The Following 5 Users Say Thank You to nicolai For This Useful Post: | ||
|
|
2011-02-08
, 11:23
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#106
|
Originally Posted by Capt'n Corrupt
Two (well, three) problems.
Seriously?
Regardless of reality, that argument is invalidated by the most basic logic. Just because something has not been done, does not mean it cannot be done.
1. The predictions are based on how native compilers worked ten years ago and assume that they won't *qualitatively* be different in the future. From .NET and LLVM implementation we already know this is not true, so your baseline what you need to get better than IS moving upwards.
2. Occam's razor works against you. You know that the Java-ish VM approach has both advantages and disadvantages. There has been a tanker-loads of money sunk into optimizing it by Sun, IBM and Google. Where this turns into occam's razor is that 5-10 years later, it's still objectively slower, so either the perceived benefits are not as huge or as easily implementable as thought 10 years ago, or everybody at Sun/IBM/Google is an idiot. Your pick.
3. This 'compiler/VM/interpreter technology advances will make all current languages obsolete' is a repeating thing. I remember when lisp/prolog were the next big thing. Just imagine, you don't need to define procedures how tasks are done, so in theory a good interpreter can make a better native code path than a human programmer ever could ! The key here is - in theory. Academic papers will be happy to point out corner cases in which alternative approaches beat out the incumbent one, but we're not in the business of academic papers - software development is engineering, and engineers have the tools of today to build the applications of today.
Disclaimer (again): I was a Java guy, but nowadays I do C++ (w Qt) by day and Python by night.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
| The Following 4 Users Say Thank You to attila77 For This Useful Post: | ||
|
|
2011-02-08
, 12:56
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#107
|
we, maemo5 and Meego are saved!
http://www.myriadgroup.com/Media-Cen...id-Phones.aspx
http://www.myriadgroup.com/Media-Cen...id-Phones.aspx
|
|
2011-02-08
, 13:03
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#108
|
Originally Posted by zimon
Or they're doomed (that is something I kept on thinking since releasing preenv and watching how the thread developed).
we, maemo5 and Meego are saved!
http://www.myriadgroup.com/Media-Cen...id-Phones.aspx
On the other side, they require expresal approval and a few modifications* from the original app owners, so I believe this won't cause many "trouble".
* "Dalvik is not Android" I said, remember?
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2011-02-08
, 13:22
|
|
Posts: 376 |
Thanked: 511 times |
Joined on Aug 2009
@ Greece
|
#109
|
Originally Posted by Radu
In theory you're right. In practice you're wrong.
How can someone sane believe that compiled code can't do the same stuff that VM/JIT code does?
What you say is true only under perfect conditions (like looking for a non-rating black hole). In practice much of a program's speed comes from the algorithms and code organization instead of small-things optimization. For example, in theory it would be faster if you used the assembly language but in practice this will result in slower code since you'll not implement common patterns as good as they are already implemented by any other language (or its libraries).
That's why it may be faster to write something in python using Qt bindings (or java) than write it in C++, since you'll take advantage of some very efficient data handling methods that you'll most probably won't implement yourself.
Of course there are many exception to the above (e.g. linux kernel), but when dealing with common program developers like ourselves, the above becomes mostly true.
However, there are other benefits in native code than the speed and that's where you should focus instead.
| The Following 2 Users Say Thank You to v13 For This Useful Post: | ||
|
|
2011-02-08
, 15:08
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#110
|
Originally Posted by javispedro
But what this means, that when Nokia gets the first Meego phone out, it will then already have many applications available via Alien Dalvik. Someone who has had Android-phone, will more likely and willingly switch to Meego device now, because (s)he can get many (if not most) of the Android-apps with him.
Or they're doomed (that is something I kept on thinking since releasing preenv and watching how the thread developed).
On the other side, they require expresal approval and a few modifications* from the original app owners, so I believe this won't cause many "trouble".
* "Dalvik is not Android" I said, remember?
There is always this unknown critical mass of applications so any platform can survive. Having ability to run Android apps in Meego helps to reach this critical mass sooner, or at once now.
It is interesting to see in the video, Adobe Photoshop Android application runs as fast in N900 under Alien Dalvik than in HTC (what model?) under real Dalvik.
 |
| Tags |
| bada rox, dalvik, future, java haters, meego, meego?fail, nokia, sandbox sucks |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 17:40.
PS. As for time critical - in mobile space 'slow' translates into 'power-hungry' (because it goes against race-to-idle, etc).
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc