Jpc - Java Linux & Arm Optimized Dos Emulator

[Kramy]

It's not about performance, it's about ease of use. Java is much more user friendly than C.

C is simpler, it has lots less complexities. People think that java and C++ are better because of their feature-set but they tend to over-complicate things and encourage in-efficient programming.
Java was created for portability, so you don't use it for performance, you use it to create platform specific byte-code, thats what it was invented for and that is what it should be used for.
If your program isn't going to be 100% platform specific then you should be using c++ or c.

I totally agree with you here; however that doesn't mean java has to be slow. It just means most java apps are slow. A skilled programmer will take the time that would've been coding/debugging into optimizing, and will end up with a java app that runs faster than a C app written in the same amount of time. Didn't one of the Quake ports in Java require less CPU power than the actual written-in-C game?

Now, if you have more time on your hands, then C would probably be better.

And if you're doing some low level hardware stuff, then C will be a necessity.

And if there's no JVM/JIT for your platform, then C will again be better.

But on x86, Java code runs basically the same speed as C code; it's just up to the programmer to not fall into "easy to use code" traps. String objects?...pfft, I use byte[] primitives! :lol: ...and once you're at that point(using more of a C flow than a Java flow), it doesn't really matter which language you use. I prefer java because I have trouble with compiler errors. I find it simpler; I code a small chunk, debug/test it, then move on...

Hum, is that CPU bound? It doesn't look so

Yeah I know, I am a bastard

Anyway this Java stuff is like all religious wars, vi vs emacs vs whatever, Windows vs Linux, and so on. It boils down to "my d.ck is bigger than yours, because I spend my day answering spam to enlarge my penis".

So true. :lol: I just don't like people spreading misinformation. The JVM on x86 is an incredible piece of software! The java language is...hmm...okay.

 

[goobers]

I use Java as part of Processing and that is only because Processing is a layer over Java that allows me to quickly prototype audio/visual experiments/projects and embed them in webpages (and run them on any platform as apps), and it works great to that end. I do all of my other programming in C/C++. I think that while it might not be the best choice for some apps, it still has its uses

 

[Svartalf]

Well, I played with it some... It's "okay" on a Core Duo machine. It's NOT so hot on an AthlonXP 2800+

On a Java "processor" it might do as well as the Core Duo, but in it's current version, it's not all it's cracked up to be for anything we might be fielding it on. It's something to keep an eye on (You just never know...) but I'm not holding my hopes up for it right now. I've a feeling QEMU or DOSBox will get there quicker than this will...

 

[Exophase]

Well, I played with it some... It's "okay" on a Core Duo machine. It's NOT so hot on an AthlonXP 2800+

On a Java "processor" it might do as well as the Core Duo, but in it's current version, it's not all it's cracked up to be for anything we might be fielding it on. It's something to keep an eye on (You just never know...) but I'm not holding my hopes up for it right now. I've a feeling QEMU or DOSBox will get there quicker than this will...

What did you test, how did it perform, what does this mean about the 20% claim (or were the things you tested all protected mode)?

 

[Kramy]

http://java.sun.com/developer/technicalArt...6u10/index.html

Interesting article. A bit long though, so I'll summarize/quote the interesting bits.

A tad unfortunate few of these improvements apply to Linux/ARM.
QUOTE
Java Kernel is a new distribution aimed at getting Java software up and running faster. Instead of a full JRE, users download a small installer (the "kernel") which includes the most commonly needed JRE components. Additional components are downloaded as needed, and the JRE will download remaining components in the background and then reassemble itself.

I guess the exciting part is the JRE can start without loading all the modules.
QUOTE
Java 6u10 includes a brand-new implementation of the Java Plug-in, which is used by default as long as you are using Firefox 3 or Internet Explorer. The next-generation plug-in runs applets outside of the browser in one or more separate processes.

Hurray! Full-speed Applets, maybe?
QUOTE
Java Deployment Toolkit

The Java Deployment Toolkit makes deploying Java applets or Java Web Start programs a snap. The Deployment Toolkit JavaScript file provides:

* Accurate detection of installed JREs
* Seamless JRE installation
* Complete applet launching (JRE detection and, if necessary, upgrading) in a single line of code
* Complete Web Start program launching in a single line of code

Thank you! It's an utter pain getting Applets to work in every browser configuration.

QUOTE
Nimbus

Interesting look and feel. The round scrollbars are a bit odd.

QUOTE
Performance

Sun's JRE has been steadily getting faster over the years, and 6u10 is no exception. Key performance improvements are the introduction of Java Quick Starter, which will substantially improve Java cold start time on most systems, and a new graphics pipeline on Windows.

The new graphics pipeline will use Direct3D to accelerate most common operations, so the powerful 3D graphics card you probably have in your computer will have a use other than playing games. Translucency, gradients, affine transforms, antialiasing, rectangular fills and copies, and various other graphics operations will all be accelerated by 3D graphics cards. And, unlike previous 3D pipelines which were not robust enough to be enabled by default, the new pipeline is rock-solid and used by default in 6u10.

BIG new feature.

 

[A_SN]

It's not about performance, it's about ease of use. Java is much more user friendly than C.

It's actually quite subjective. For someone who thinks on a relatively low level, C is as good and simple as it gets.

 

[Svartalf]

Well, I played with it some... It's "okay" on a Core Duo machine. It's NOT so hot on an AthlonXP 2800+

On a Java "processor" it might do as well as the Core Duo, but in it's current version, it's not all it's cracked up to be for anything we might be fielding it on. It's something to keep an eye on (You just never know...) but I'm not holding my hopes up for it right now. I've a feeling QEMU or DOSBox will get there quicker than this will...

What did you test, how did it perform, what does this mean about the 20% claim (or were the things you tested all protected mode)?



Heh... I tested the titles they had on the default configurations against the machines in question. In one of the test environments, it was Java6 SE on an AthlonXP 2800+. It was unplayable with the titles (Commander Keen, etc.) on this machine- not QUITE slideshow territory on framerates, but fairly close to that. I'd say that they were being a bit optimistic about 20% of CPU, really. We didn't even get into protected mode execution.

I suspect that it'll be going places eventually, but right now, it's not the great thing they make it out to be- I think we're going to have to work at getting DOSBox or QEMU going as our choices at this point in time.

It's actually quite subjective. For someone who thinks on a relatively low level, C is as good and simple as it gets.

That's not what a Forth-er will tell you...

BIG new feature.

Yeah, but what does this do for me, the Linux user or the Pandora owner...

 

[Hitnrun]

How can a Java application be "ARM optimized"? Does Java allows embedded asm?

 

[Squidge]

The problem with OO in Java, C#, and even C++ is that some morons create classes with code like the below and include it in all there projects.

public static double Add(double firstNo, double secondNo)
{
double total=firstNo+secondNo;
return total;
}


public static double Add(double[] valueArray)
{
double total = 0.00;
foreach(double val in valueArray)
{
total+=val;
}
return total;
}

public static double Multiply(double num1, double num2)
{
return num1*num2;
}

( http://thedailywtf.com/Articles/Theyre-Use...In-General.aspx )

and we wonder why some programs are so slow when ported to other architectures...

 

[ldesnogu]

How can a Java application be "ARM optimized"? Does Java allows embedded asm?

Fast Java VM generate machine code. Look for definitions of JIT, just-in-time.

 

[flatmush]

How can a Java application be "ARM optimized"?

It can't be optimized specifically for arm I don't think, but it can be generally optimized so that it runs faster on all machines.

Does Java allows embedded asm?

No, java isn't compiled and it wouldn't be platform specific if it contained inline assembly.

 

[ldesnogu]

The problem with OO in Java, C#, and even C++ is that some morons create classes with code like the below and include it in all there projects.

public static double Add(double firstNo, double secondNo)
{
double total=firstNo+secondNo;
return total;
}

public static double Add(double[] valueArray)
{
double total = 0.00;
foreach(double val in valueArray)
{
total+=val;
}
return total;
}

public static double Multiply(double num1, double num2)
{
return num1*num2;
}

( http://thedailywtf.com/Articles/Theyre-Use...In-General.aspx )

and we wonder why some programs are so slow when ported to other architectures...


Here at least you can find what's going on using grep. Imagine the same with operator overloading :blink:

Does Java allows embedded asm?

No, java isn't compiled and it wouldn't be platform specific if it contained inline assembly.

That's wrong, Java *is* compiled. However it *usually* compiles for a virtual machine named JVM.

 

[Hitnrun]

Does Java allows embedded asm?

No, java isn't compiled and it wouldn't be platform specific if it contained inline assembly.

That's wrong, Java *is* compiled. However it *usually* compiles for a virtual machine named JVM.

Yes, but the topic says "ARM optimized", which to me means "it does things differently on ARM to speedup things", if it is the JIT compiler that does it, that does not seems "optimized" to me.

 

[WhiteFalcon]

public static double Add(double firstNo, double secondNo)
{
double total=firstNo+secondNo;
return total;
}

public static double Add(double[] valueArray)
{
double total = 0.00;
foreach(double val in valueArray)
{
total+=val;
}
return total;
}

public static double Multiply(double num1, double num2)
{
return num1*num2;
}




Is that a joke or am I missing something? I know near to nothing about Java, but afaik it is similar to C(++) so why create functions for elementary operations such as Add or Multiply instead of using + and *? The only good way I have read about is when one uses the macros in C, like defining the function in a #define so that it is inserted into the code before compiling.

 

[Squidge]

Is that a joke or am I missing something? I know near to nothing about Java, but afaik it is similar to C(++) so why create functions for elementary operations such as Add or Multiply instead of using + and *?

Why indeed, but those functions were found in a OO class of a commercial application, with the developer claiming those functions are useful 'in general'.

 

[ldesnogu]

Is that a joke or am I missing something? I know near to nothing about Java, but afaik it is similar to C(++) so why create functions for elementary operations such as Add or Multiply instead of using + and *? The only good way I have read about is when one uses the macros in C, like defining the function in a #define so that it is inserted into the code before compiling.

That's alas no joke. I have seen similar code in production. Beginners in OO programming love to encapsulate *everything*.

Nowadays people who start programming are only taught "high-level" concepts and are never told what's the price is. It was so much better when I was young

 

[Svartalf]

The problem with OO in Java, C#, and even C++ is that some morons create classes with code like the below and include it in all there projects.

<* evil, boneheaded, but very COMMON examples deleted for brevity... *>

and we wonder why some programs are so slow when ported to other architectures...

It's a brain in neutral, head up backside mode of thinking that produces this sort of crap.

An OO purist will tell you that's the "proper" way of doing things. Perhaps if you're using
Smalltalk or Eiffel it is. In at least C++, it's not. The only time you need to declare accessors
or similar is if you're needing to do special overrides from the normal compiler accesses
of public members or if you need to set/get a protected or private variable (which brings us
to the question, "if you're doing those things, why are they protected/private?"- there's a few
good reasons for doing things that way, but if you're not wanting to strictly regulate accesses
for mutex similar reasons, if you're accessing it all the time, you're better off treating it as
a public and accessing it as if it were a member value instead of calling a method against the
class instance. This is because if you do methods and goofy things like in your examples, you're
producing bloated dispatch code to methods, whereas in many cases, if you do it like I describe
the compiler does very, very simple things and makes much tighter, efficient, and reliable code.

It's the difference between operating off of understanding and operating by rote. Many programmers
really don't understand what they're asking the computer to do when they code up whatever they're
doing.

That's alas no joke. I have seen similar code in production. Beginners in OO programming love to encapsulate *everything*.



Not THIS OO programmer...

But then, I've had the opportunity to see what the machine does with over a dozen different OO and non-OO programming languages over the years. Of course, unless upper management mandated that sort of crap (I've been in a few shops where they mistakenly thought this would make things "more typesafe" than the way I would do things... :rolleyes: ) I'd be ripping it out at the first opportunity because it makes it less robust and much more bloated than it needed to be.

QUOTE

Nowadays people who start programming are only taught "high-level" concepts and are never told what's the price is. It was so much better when I was young

Heh... Wasn't it, though?

Why indeed, but those functions were found in a OO class of a commercial application, with the developer claiming those functions are useful 'in general'.

Heh... And, he's lucky I wasn't his boss when he made that claim... >;-)

 

[Exophase]

Heh... I tested the titles they had on the default configurations against the machines in question. In one of the test environments, it was Java6 SE on an AthlonXP 2800+. It was unplayable with the titles (Commander Keen, etc.) on this machine- not QUITE slideshow territory on framerates, but fairly close to that. I'd say that they were being a bit optimistic about 20% of CPU, really. We didn't even get into protected mode execution.

I ran on a 2GHz Athlon64 X2 and Prince of Persia and Duke Nukem seemed to run great in their demo. Granted, without sound it's hard to tell if it's really fullspeed or not, and it has been years and years since I've played these games. I honestly think only 1-2% of the capability of this CPU (20-40MHz Athlon64 X2) would be necessary to run these games, if even that. Maybe something's threaded, but I can't see that making a huge difference, and other than that I don't expect my CPU/setup to be any more than 30% faster than yours.

Is it possible something else was bogging things down?

I've thought about doing a simple real mode PC emulator for ARM before (one of the many things I bounce around my head..) Although I doubt I'd do actually do it, I have a good feeling that it could be done in a way that's significantly more efficient than what's out there. Again, this is just for simple low end PC specs.

 

[ldesnogu]

I ran on a 2GHz Athlon64 X2 and Prince of Persia and Duke Nukem seemed to run great in their demo. Granted, without sound it's hard to tell if it's really fullspeed or not, and it has been years and years since I've played these games. I honestly think only 1-2% of the capability of this CPU (20-40MHz Athlon64 X2) would be necessary to run these games, if even that.
I doubt you could get that low requirements. As I said in some other posts a statically translated 3d game from Atari ST only got me around 4000 fps on my 3500+ (2.2 GHz) and the ST was probably less powerful than what is required for Duke Nukem. Granted I could have done something utterly stupid, but I don't think so

QUOTE
I've thought about doing a simple real mode PC emulator for ARM before (one of the many things I bounce around my head..) Although I doubt I'd do actually do it, I have a good feeling that it could be done in a way that's significantly more efficient than what's out there. Again, this is just for simple low end PC specs.
I have been considering that too. In fact I would like to write my first dynamic translator; after having written CPU interpreters for more than 10 years and after having tried static recompilation, it would be a logical step.
And since I hate x86, that'd be even funnier :lol:

 

[Exophase]

I ran on a 2GHz Athlon64 X2 and Prince of Persia and Duke Nukem seemed to run great in their demo. Granted, without sound it's hard to tell if it's really fullspeed or not, and it has been years and years since I've played these games. I honestly think only 1-2% of the capability of this CPU (20-40MHz Athlon64 X2) would be necessary to run these games, if even that.
I doubt you could get that low requirements. As I said in some other posts a statically translated 3d game from Atari ST only got me around 4000 fps on my 3500+ (2.2 GHz) and the ST was probably less powerful than what is required for Duke Nukem. Granted I could have done something utterly stupid, but I don't think so

Sorry, I didn't mention this but that's not including the flat overhead you'd have to pay for blitting the screen and other OS stuff. That's not a multiplier and doesn't go away, so naturally it'll limit the number of fps. But I'm pretty confident that a 20-40MHz Athlon64 X2 could play Duke Nukem if it were running it in DOS. In fact, given that it was released in 1991 (and thus probably ran fine on 386's), I think even a 10MHz Athlon64 X2 could possibly do it.