maemo.org - Talk - Droid and Android gaming irony

maemo.org - Talk (https://talk.maemo.org/index.php)

- Off Topic (https://talk.maemo.org/forumdisplay.php?f=19)

- - Droid and Android gaming irony (https://talk.maemo.org/showthread.php?t=34855)

Re: Droid and Android gaming irony

Quote:

Originally Posted by fms (Post 385446)

Well, C/C++ running on ARM is called C/C++. C/C++ running on x86 is still called C/C++. C/C++ running on 6502 is still C/C++. C/C++ without STDIO library is still called C/C++. C/C++ without STRING library is still C/C++. And so forth.

Why exactly is Java any different, aside from the bogus argument that "Sun defines it this way"?

C++ (and C) (in contrast with Java) are very well defined. C++ is exactly the ISO/IEC 14882:2003 and that includes the string library (section 21 of the standard).

Java on the the other hand... well...

So please, don't compare those two (three) languages. Java is just a product that a company defines while C++ is a standard. There is no limitation on what you can do with C++ and even the oldest C++ programs still compile and run. Java OTOH has a great number of limitations and questioned backward compatibility.

Of course C beats' em all on those aspects :D

Re: Droid and Android gaming irony

Quote:

Originally Posted by v13 (Post 385633)

Excellent post. Thanks mate.

Re: Droid and Android gaming irony

Well, when all is said and done:

Since Droid does a great job with emulators but can't play Quake 1 very well due to the overhead, my guess is the N900 will kick Droid's a55 for emulators.

Quake 1 is weak to a stuttery mess on Droid. Quake 3 seems to play smooth with sound on the n900.

Strange about Droid, since my Dell Axim played Quake 1 pretty good with sound.

Re: Droid and Android gaming irony

Quote:

Originally Posted by 406NotAcceptable (Post 385175)

Java really isn't as slow as many would make you believe.

http://kano.net/javabench/
http://www.idiom.com/~zilla/Computer...benchmark.html

Certain operations can be slightly faster, whilst others are upto 10% slower.

Both sites seem like FUD to me.

The first site doesn't compare the languages at all. It just compares different algorithms: The java's algorithm and the author's algorithm for each example.

For god's sake, who allocates a matrix that will hold integers in C++ like this (matrix.cpp):

Code:

int **mkmatrix(int rows, int cols) {

    int i, j, count = 1;

    int **m = (int **) malloc(rows * sizeof(int *));

    for (i=0; i<rows; i++) {

        m[i] = (int *) malloc(cols * sizeof(int));

        for (j=0; j<cols; j++) {

            m[i][j] = count++;

        }

    }

    return(m);

}

Not only he could just have done:

Code:

return malloc(rows*cols*sizeof(int))

and accomplish a N-times faster program, he uses malloc instead of new in a C++ program.

As for the second site, writing something like this:

Quote:

Pointers make optimization hard

makes me stop reading (why mention pointers when talking about C++? where are your references?). But I continued:

Quote:

Garbage collection- is it worse...or better?
....
Consider what happens when you do a new/malloc: a) the allocator looks for an empty slot of the right size, then returns you a pointer. b) This pointer is pointing to some fairly random place.
With GC, a) the allocator doesn't need to look for memory, it knows where it is,
....
The big benefit of GC is memory locality. Because newly allocated memory is adjacent to the memory recently used, it is more likely to already be in the cache.

at this point the author compares the internal memory allocating method of the c library with the C (and C++) language. That's totally wrong and can be proved by looking at glibc and montern operating systems: glibc used not to free memory at all but instead re-use it (what the author wants) but that was changed and now it lets the kernel manage the memory more efficient. In fact, since all memory is virtual (and most of the time it is split in 4KB pages), there is no guarantee that two consecutive memory addresses will in fact be consecutive (or in cache). Of course, all these are operating system dependent and the OS tries to do its best. Java just builds a layer on top of this.

OK, Java's speed is acceptable, but the sites should have more serious claims...

p.s. I could keep commenting on almost all lines of those sites for hours, but you get the point :D

Re: Droid and Android gaming irony

Quote:

Originally Posted by Rushmore (Post 385664)

Since Droid does a great job with emulators but can't play Quake 1 very well due to the overhead, my guess is the N900 will kick Droid's a55 for emulators.

Certainly right now any application that needs to run close to the wire will benefit from being run on the N900.

It's not just a matter of performance but also the availability of hardware services. I remember reading an article a couple of years ago that said researchers loved working with Nokia phones versus other manufacturer's because they provided the best access to things like the DSP.

Re: Droid and Android gaming irony

Quote:

Originally Posted by v13 (Post 385667)

Code:

int **mkmatrix(int rows, int cols) {

    int i, j, count = 1;

    int **m = (int **) malloc(rows * sizeof(int *));

    for (i=0; i<rows; i++) {

        m[i] = (int *) malloc(cols * sizeof(int));

        for (j=0; j<cols; j++) {

            m[i][j] = count++;

        }

    }

    return(m);

}

Not only he could just have done:

Code:

return malloc(rows*cols*sizeof(int))

and accomplish a 1000-times faster program, he uses malloc instead of new in a C++ program.

As for the second site, writing something like this:

makes me stop reading (why mention pointers when talking about C++? where are your references?). But I continued:

at this point the author compares the internal memory allocating method of the c library with the C (and C++) language. That's totally wrong and can be proved by looking at glibc and montern operating systems: glibc used not to free memory at all but instead re-use it (what the author wants) but that was changed and now it lets the kernel manage the memory more efficient. In fact, since all memory is virtual (and most of the time it is split in 4KB pages), there is no guarantee that two consecutive memory addresses will in fact be consecutive (or in cache). Of course, all these are operating system dependent and the OS tries to do its best. Java just builds a layer on top of this.

OK, Java's speed is acceptable, but the sites should have more serious claims...

p.s. I could keep commenting on almost all lines of those sites for hours, but you get the point :D

Hey, you seem to know your stuff- want to make a Turbografx emulator for the n900? ;) Galaga 90 and Blazing Lazers are religious experiences :)

Re: Droid and Android gaming irony

Dalvik isn't Java but it uses the same languages and several java libraries are compatible, for instance popular Apache commons-httpclient. And since Android doesn't claim to be java compatible any library could refuse to work.

Given the resemblances I'd say Android is as much Java as Google Application Engine is. Not everything java will run in it but it's similar enough so developers can use their java development infrastructure, knowledge and work around the discrepancies/limitations.

And android now has a jit.

Re: Droid and Android gaming irony

Quote:

Originally Posted by Bratag (Post 385611)

The syntax and semantics of a language do not denote it "being" that language - the interpreter of that syntax and semantics are what define that.

Not really. There are multiple interpreters of BASIC for example. There are multiple C/C++ compilers. And so forth.

Quote:

It is entirely possible you could write an interpreter for the Java syntax etc that in no way produced the same output as the Java interpreter.

I am not sure what you mean by "interpreter output" here. But if two interpreters execute the same Java program producing different outputs, that would mean that at least one of them violates Java semantics.

Quote:

Finally - To legally call something Java compliant you do have to get sign off from Sun. Anything else is technically not Java compliant and thus not "really" Java.

And here we go invoking Sun lawyers again...

Re: Droid and Android gaming irony