Page 14 of 21 « First 41213 14 1516 Last »
Reply
Thread Tools
Capt'n Corrupt's Avatar
Capt'n Corrupt is offline Capt'n Corrupt
2011-02-09 , 11:33
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#131
I also believe that the performance gap issue is moot for another:
It seems that culture determines largely what developers use more so than ease, flexibility, portability, or speed.
Last edited by Capt'n Corrupt; 2011-02-09 at 11:50.
 
Capt'n Corrupt's Avatar
Capt'n Corrupt is offline Capt'n Corrupt
2011-02-09 , 19:07
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#132
Off topic:
I got a chance to install and play Jake 2, the Java quake and I am thoroughly impressed. The game runs like a dream! On my system (intel integrated graphics -- I know, I know), it loads quickly, and runs flawlessly.

My kudos to the developer(s)! It seems that they stopped working on this 6 years ago, but it is still a fantastic port.
 
Radu is offline Radu
2011-02-09 , 23:35
Posts: 303 | Thanked: 146 times | Joined on Aug 2009
#133
Originally Posted by Capt'n Corrupt View Post
@Radu,
Here's an Quake 2 Java port example to counter your C# port example:
http://www.bytonic.de/html/benchmarks.html

What does this show? That the Windows JVM version (and only JRE 1.5) is actually faster than the HIGHLY tuned C version (remember, this is Carmack's software we're talking about) with the Windows JVM intepreter. Full-screen and the linux JVM are slower, but not by much.
That's an interesting link, but a bit meaningless because:
1. It does not specify what C compiler was used (and what version), what compile settings were used, etc.

2. There is also the possibility that the porter changed some things here and there to make better use of newer OpenGL things that were not available back in 1997 when Quake 2 was programmed.

3. A lot of the CPU time is spent in external APIs (OpenGL) rather than in the game code itself. I would guess a software only renderer will show more interesting results.

Anyway, the main reason why I don't believe VMs/JIT will ever catch native code in terms of speed is because it's a bit like the telephone game.
In a C program, you more or less tell the CPU what to do, step by step (assuming the compiler is smart enough not to do really stupid things). You can even use custom ASM in C, you can use registers for variables, and so on.

For Java, the compiler will translate stuff to virtual code (one step) then the JIT will translate that code in native code (another step). The more steps you have in a process the least likely it is for the final code to do things the way you want it to be done, and there is more room for errors (errors as in making the code less optimal).
 
slender is offline slender
2011-02-10 , 07:19
Posts: 2,829 | Thanked: 1,459 times | Joined on Dec 2009 @ Finland
#134
Originally Posted by v13 View Post
Also, as a personal opinion, speed is not everything. Better provide more that provide less and make them faster. You can only compare two existing products for speed. Not one that exists and it is slow and one that doesn't exist and it would be faster if it was ever written. Android already has a ton of apps and mobile phone manufacturers can instantly take advantage of them. No manufacturer (or human) currently cares if the apps in android's app store are slow.
I agree but from point of HW manufacturer speed is quite important. If you can put HW that is couple of dollars cheaper /device (slower cpu & gpu but more optimized code&OS) than your rival you can make quite difference in profits. This is one reason why I think that Nokia will never ever use the newest and leanest HW. In addition it could be bad business decisions because of shortage of these newest and leanest components. Big promises and small output of device not good for company size of Nokia. Nokia has probably (after "The lean" Toyota ) worlds most efficient manufacturing and logistics channels. Smaller companies will use newest HW and try to compete with just pure MHz and Gb specs. IMO itīs almost as stupid as M.pixel race of digicams.

But itīs true that people tend to over emphasize speed quite much and we all should remember that our bias (quite probably) here in TMO is quite different from Joe Averages.
__________________
TMO links: [iSpy] - [Power search] - [Most thanked] - [Cordia - Maemo5 UI on top MeeGo Core] - [CommunitySSU]
 
nicolai's Avatar
nicolai is offline nicolai
2011-02-10 , 08:34
Posts: 1,637 | Thanked: 4,424 times | Joined on Apr 2009 @ Germany
#135
Originally Posted by Radu View Post
Anyway, the main reason why I don't believe VMs/JIT will ever catch native code in terms of speed is because it's a bit like the telephone game.
In a C program, you more or less tell the CPU what to do, step by step (assuming the compiler is smart enough not to do really stupid things). You can even use custom ASM in C, you can use registers for variables, and so on.
A JIT can do this too, and better because ...
Originally Posted by Radu View Post
For Java, the compiler will translate stuff to virtual code (one step) then the JIT will translate that code in native code (another step). The more steps you have in a process the least likely it is for the final code to do things the way you want it to be done
... why do you thing "the way you want it to be" is the fastest.

Java (or java-like language) is not a better just because it has a VM and
JIT, and C++ is not faster just because you can use asm, or
because it is more "native". But,
a VM and a just in time compiler have information that is just not
there when writing code (the programmer) or generating code (the compiler):
The runtime and execution path information.
This is not a judgment for Java, just a point you shouldn't miss,
you or the c++ compiler may not know what will be the best
code to generate.

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 2 Users Say Thank You to nicolai For This Useful Post:
zimon is offline zimon
2011-02-10 , 11:25
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#136
@Radu:
You should read the links "the idiots" (someone gave this name, vi_?) have written and where they try to explain why JIT-interpreted code can and eventually will probably be faster than fully compiled code (typically in applications which use OOP).

What you are saying is not wrong, but you are not looking the big picture. There is extra information available in running time. Only VM-type of solutions can use this running-time profiling information for optimizations. The efficiency gain in OOP-type of programs can easily be more than the loss which come from the JIT and having a code in a bytecode form in the beginning.

You cannot get all this "extra information" by running test cases and profiling few sessions. In a long running applications the situation is dynamic and depends often on undeterministic inputs the program gets from the outside world. Think www-browser which have easily millions of dynamic objects which have different life spans.

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.

The clever JIT will never throw away the used bytecode which it knows will be run many times, because in latter time some other compilation of the bytecode may become more faster when enough runtime information is gathered.

http://portal.acm.org/citation.cfm?id=345105.352548
Java
performance can exceed that of C++ because
dynamic compilation gives the Java compiler
access to runtime information not available to a
C++ compiler.
Last edited by zimon; 2011-02-10 at 11:37.
 

The Following User Says Thank You to zimon For This Useful Post:
daperl's Avatar
daperl is offline daperl
2011-02-10 , 12:16
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#137
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.
You don't know what you're talking about, and if you think you do, prove it.
__________________
N9: Go white or go home
 
zimon is offline zimon
2011-02-10 , 12:35
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#138
Originally Posted by daperl View Post
You don't know what you're talking about, and if you think you do, prove it.
http://www.google.com/search?q=firef...+fragmentation

I know there has been lots of work to tackle this heap memory fragmentation problem in Firefox, but what it means in fact you have to eventually write some kind of CG with C++. Then for de-fragmentation you either need to use only indirect pointers (references only, not pointers, not direct arrays) OR you need code morphing (VM re-JIT). If one would use Java from the start, you already would have CG and re-JIT with current desktop modern VMs.

I myself can notice once a week the issue, when I better re-start Firefox than continue using the same session. I should buy more RAM, but after Firefox re-start and resuming the same session with all the tabs, the situation is good again some days depending how much I use Firefox and open/close new tabs/pages.

The problem is obvious for me, but I know I should prove it with memory prints comparing the same session and tabs and pages after fresh start and after few days of surfing. Also I could show how cache misses will increase over time with Firefox. I've actually sometimes done these observations but not in a scientific way yet.
Last edited by zimon; 2011-02-10 at 12:37.
 
nicolai's Avatar
nicolai is offline nicolai
2011-02-10 , 12:50
Posts: 1,637 | Thanked: 4,424 times | Joined on Apr 2009 @ Germany
#139
Hm,
Originally Posted by zimon View Post
The problem is obvious for me, but I know I should prove it with memory prints comparing the same session and tabs and pages after fresh start and after few days of surfing
The page you quoted is about memory fregmantation when many
windows (or pages) are opended even right after start. So,
Originally Posted by zimon View Post
but after Firefox re-start and resuming the same session with all the tabs, the situation is good again
if all is good again, even if you restart your session with all tabs,
I don't believe this memory fragmentation was the reason.
__________________
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker

-Donate-
 
attila77 is offline attila77
2011-02-10 , 12:53
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#140
Originally Posted by zimon View Post
What you are saying is not wrong, but you are not looking the big picture. There is extra information available in running time. Only VM-type of solutions can use this running-time profiling information for optimizations. The efficiency gain in OOP-type of programs can easily be more than the loss which come from the JIT and having a code in a bytecode form in the beginning.
And back to square one. Comparing a language to a platform. Why do you say only Java can have a VM type solution or that a Java VM solution is the best VM solution ?

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++
Now that is plain FUD. The memory leaks that are caused by pointer assignments are easily detectable with the proper tools, and if you use things like Qt, handled automatically (say hello to guarded and scoped/reference counting pointers). *Logic* based leaks (i.e. not getting rid of objects you don't really need) is a different matter and no choice of language will help you there.

BTW So now Chrome and Opera are slow and leaky, too ?
__________________
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:
Reply
Page 14 of 21 « First 41213 14 1516 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 06:29.

Contact Us - Home - Archive - Top