Page 9 of 21 « First 78 9 101119 Last »
Reply
Thread Tools
attila77 is offline attila77
2011-01-29 , 13:34
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#81
Originally Posted by Joorin View Post
The endless speed debate. Java, on the other hand, offers great ways to optimize your running binary by inspecting it which isn't possible in C++.
This is where all these discussions get derailed. You start comparing the Java platform with the C++ language.
__________________
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:
Capt'n Corrupt's Avatar
Capt'n Corrupt is offline Capt'n Corrupt
2011-01-29 , 13:45
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#82
Originally Posted by attila77 View Post
For tl;dr people: the holy grail of run-anywhere binaries have (nearly) nothing to do with the language, it's about platform/OS abstraction.
*snip*
That is simply not true. The write-once app has very much to do with the language. I know it *has* been done before, and you *can* compile C to Java VM but it is generally not used this way in the majority of cases for a number of reasons -- in fact it's somewhat rare.

I'm not arguing capability, but reality.

The rest is conversation drift. I stand by my assertions about developers being particular to their environments and that write-once applications have a tendency to be tied to a particular language.
 
Joorin is offline Joorin
2011-01-29 , 13:49
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#83
Originally Posted by attila77 View Post
This is where all these discussions get derailed. You start comparing the Java platform with the C++ language.
A program that is not run will perform equally well no matter what language is used (speed == 0). If any comment is to be made about how "fast" or "slow" it is, the environment it is run in must be included. In the case of Java, this includes the JVM (which differs between devices, I know). If the JVM is simplistic, Java will not do very well compared to applications running on "bare metal". But I didn't interpret the comment as that kind of comparison.

The comment I was commenting on contained a very broad statement about speed that, as far as I could see, said nothing about the actual language other than that the person didn't like Java and preferred C.
 
attila77 is offline attila77
2011-01-29 , 14:16
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#84
Originally Posted by Capt'n Corrupt View Post
I'm not arguing capability, but reality.
The rest is conversation drift. I stand by my assertions about developers being particular to their environments and that write-once applications have a tendency to be tied to a particular language.
The point is that it isn't a causal relation (what people tend to think based on Java-JVM symbiosis), it's simply correlation, see .NET

Originally Posted by Joorin View Post
A program that is not run will perform equally well no matter what language is used (speed == 0). If any comment is to be made about how "fast" or "slow" it is, the environment it is run in must be included
Ah, but that's language hypocrisy then In order to compare apples to apple, either you compare PLATFORMS or you compare LANGUAGES. It's a common misconception that C++ does not have level platform level solutions - admittedly, it's nowhere as dominant/unified as Oracle's (nee Sun's) Java platform, but definitely not unheard-of. I already mentioned .NET above, so, let's see, what does Java give you over a C++/CLI .NET application (I know most people associate C# with .NET in their heads, but C++ *is* part of the CLI language list).

http://en.wikipedia.org/wiki/List_of_CLI_languages

EDIT: And of course, from a compiler geek perspective a weird twist is that nowadays X86 itself is an abstraction (as it covers CPUs that have vastly different innards, the most extreme example of this was the Transmeta approach).
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Last edited by attila77; 2011-01-29 at 15:42.
 

The Following User Says Thank You to attila77 For This Useful Post:
v13 is offline v13
2011-01-29 , 21:06
Posts: 376 | Thanked: 511 times | Joined on Aug 2009 @ Greece
#85
Originally Posted by attila77 View Post
There is nothing saying you couldn't compile C++ to VM bytecode ...
FWIW, it's already possible and it's called LLVM.
 

The Following User Says Thank You to v13 For This Useful Post:
Radu is offline Radu
2011-01-30 , 02:26
Posts: 303 | Thanked: 146 times | Joined on Aug 2009
#86
Originally Posted by Joorin View Post
Ok, so you're ignorant about Java. Fair enough.

But if you're ignorant about it, what do you know that you dislike?
LOL. I am not even going to comment on your trolling attempt.

You can use compiled C libraries from Java. Just Google it and lessen that ignorance.
No, you have no idea about programming. The fact that you can use SOME C libraries in Java doesn't help you that much when the goal of Java is "write once, run everywhere", now does it? If you can use your C code on other platforms, why use Java for portability in the first place?

The endless speed debate. Java, on the other hand, offers great ways to optimize your running binary by inspecting it which isn't possible in C++. There are nice Java3D bindings using available 3D hardware so you're left with (real) speed differences when it comes to number crunching. How does that apply to you as a "desktop developer"?
Yes, in theory Java is as fast or faster than C++, which is in theory faster than ASM (because hey, the compiler can do stuff better than humans do). In reality, this is a silly argument, Java and .NET is noticeably slower than C/C++.

How does the CPU type affect this? How is that relevant?
ARM CPUs are optimized for low power, not for speed. If you use a VM rather than native code your application is going to be even slower. You don't have the horsepower of a X86 CPU.
 
Joorin is offline Joorin
2011-01-30 , 10:02
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#87
Originally Posted by Radu View Post
LOL. I am not even going to comment on your trolling attempt.
No trolling. Really. You say that you don't know Java but that you don't like it. This really makes me wonder what you actually do know to make you dislike it.

No, you have no idea about programming.
I assure you, I do have "an idea" about programming. And more than that. No need for ad hominem nonsense.

The fact that you can use SOME C libraries in Java doesn't help you that much when the goal of Java is "write once, run everywhere", now does it?
How did the "goal of Java" become relevant? How it actually works is more important. To be able to use snippets of C code actually increases the chances that the rest can be "pure Java".

And, being able to use native code for the heavy number crunching and Java for the rest actually lets you write pretty portable Java code for everything but the most CPU intensive parts.

If you can use your C code on other platforms, why use Java for portability in the first place?
If you take a look at Android, to name one, the APIs available out of the box differs between native binaries and Java applications.

On top of that, having as much of the code as possible written in Java makes it easier to move the code to another Java platform. You will still need to port the C parts, but by keeping that bit as small as possible it becomes manageable.

Yes, in theory Java is as fast or faster than C++, which is in theory faster than ASM (because hey, the compiler can do stuff better than humans do).
I don't know of any compiler that can beat the speed of hand coded assembler unless you're talking of larger frame optimizations. But for "ordinary use", I do agree on the compiler being very good at generating fast code.

In reality, this is a silly argument, Java and .NET is noticeably slower than C/C++.
With you being a "desktop developer", how did you come to this realization? A widget taking 74ms to update instead of 61ms?

ARM CPUs are optimized for low power, not for speed. If you use a VM rather than native code your application is going to be even slower. You don't have the horsepower of a X86 CPU.
1Ghz ARM CPUs offer some kick, though. And the benefits of Java/.NET might very well be worth the potential loss of milliseconds in update time.
 

The Following User Says Thank You to Joorin For This Useful Post:
attila77 is offline attila77
2011-01-30 , 15:56
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#88
Originally Posted by Joorin View Post
On top of that, having as much of the code as possible written in <favorite application framework/platfom> makes it easier to move the code to another <favorite application framework/platfom> platform. You will still need to port the <legacy> parts, but by keeping that bit as small as possible it becomes manageable.
Fixed it for 'ya The fact that, say, the Qt SDK spans ~half a dozen target operating systems on almost as many hardware platforms is quite telling that software development has moved on and many of the lessons of platform-building have been incorporated into today's solutions, regardless of language.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
Joorin is offline Joorin
2011-01-30 , 18:16
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#89
@attila77

I do get your point but to call everything that's not part of the target platform "legacy" is a bit on the too simple side.

As an example from reality: I will need to handle some 17000 UDP packets per second in an application I'll soon be working on. The desired language to use is C# but it's hard, if not impossible, to make this work using only C#. So, by writing a buffering packet handler in C++ to avoid garbage collection and stalled reception I can still write the rest in C#.
 

The Following User Says Thank You to Joorin For This Useful Post:
Radu is offline Radu
2011-01-31 , 01:26
Posts: 303 | Thanked: 146 times | Joined on Aug 2009
#90
Originally Posted by Joorin View Post
No trolling. Really. You say that you don't know Java but that you don't like it. This really makes me wonder what you actually do know to make you dislike it.



I assure you, I do have "an idea" about programming. And more than that. No need for ad hominem nonsense.
I used the ad hominem "nonsense" as a reply to you implying that I am ignorant. Yes, I don't know Java, but that doesn't mean I have no idea what Java is, how it works, what is the performance compared to other languages, etc.

How did the "goal of Java" become relevant? How it actually works is more important. To be able to use snippets of C code actually increases the chances that the rest can be "pure Java".
Most languages out there allow you to use libraries written in C. In fact, most of those languages are written in C/C++ anyway, no?

And, being able to use native code for the heavy number crunching and Java for the rest actually lets you write pretty portable Java code for everything but the most CPU intensive parts.
So again, why not write everything in C/C++ then? I mean, if you like Java and like to write code in Java, that's fine, but from a portability point of view it doesn't make much sense.

If you take a look at Android, to name one, the APIs available out of the box differs between native binaries and Java applications.
But there is no technical reason for this to be the case. It was just a design decision.

On top of that, having as much of the code as possible written in Java makes it easier to move the code to another Java platform. You will still need to port the C parts, but by keeping that bit as small as possible it becomes manageable.
If we abstract the APIs, C is much more portable than Java, since pretty much any CPu and microcontroller has a C compiler for it.

I don't know of any compiler that can beat the speed of hand coded assembler unless you're talking of larger frame optimizations. But for "ordinary use", I do agree on the compiler being very good at generating fast code.
That was sarcasm. People always come up with claims that Java is in many cases as fast as C++, Others claim that C++ is as fast as C, and others claim that C is as fast as assembly. So if we listen to all those claims, Java is as fast as assembly. Which is obviously not true.

With you being a "desktop developer", how did you come to this realization? A widget taking 74ms to update instead of 61ms?
I think there is a misunderstanding here. I am mostly a server developer, although in my spare time I develop some desktop applications too. By desktop applications I mean stuff that you run on a desktop, like a file manager. I never developed desktop widgets, nor do I plan to.

1Ghz ARM CPUs offer some kick, though. And the benefits of Java/.NET might very well be worth the potential loss of milliseconds in update time.
Again, this is not about updating a widget, this is about stuff like games, media players, and other things that require very fast, native code.
 
Reply
Page 9 of 21 « First 78 9 101119 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 05:25.

Contact Us - Home - Archive - Top