C++ vs Java "new" (no flame war please!)

[mlw]

Do not take anything about this, it is not a flame or troll, while I'm not
new to Java I favor C++. However, I may need to use it in a contract
position, and am concerned that the restrictions it places on application
code.

Take, for instance, this C++ construct:

class foo
{
char *m_name;
....
void * operator new(size_t size, char *string);
}
void *foo::new(size_ t size, char *string)
{
size_t cbstr = strlen(string)+ 1;
size_t cb = cbstr + size;
foo * t = (foo *) malloc(cb);
char * name = (char *) &t[1];
strcpy(name, string);
t->m_name = name;
}

The above example is a methodology that can be used to reduce the CPU and
memory overhead of malloc. You my argue that this is not a valid concern,
but if you have 10 or 100 million objects, the malloc block overhead,
alone, make this worth while. Hint: This is actually a simplification, some
times malloc is not used at all, and a big array is pre-alocated and work
through it with each new.
Is there a way to create 10 to 100 million objects in Java with a reasonable
system configuration?

[mlw]

Lew wrote:

mlw wrote:

>real 0m1.020s
user 0m0.860s
sys 0m0.092s
test@localhost :~/scat$ time java test
Java heap space
Total object:741838

real 0m19.178s
user 0m16.893s
sys 0m1.728s

You're still not timing memory allocation but JVM startup and other
factors.

Start up is NOT 18 seconds, so what other factors could we possibly be
talking about?

[Mark Rafn]

>>>Is there a way to create 10 to 100 million objects in Java with a

>>>reasonable system configuration?

>Mark Rafn wrote:

>Any VM since 1.4 on modern hardware should not have a problem with this,
unless you're pretty time-sensitive.

mlw <ml*@nospamnowa y.zzwrote:

>To address the "time-sensitive" comment, many times I hear that the machines
are fast enough that you don't need to worry about performance,

I don't think I'd ever say that. I will say that machines are fast and cheap
enough that for a whole lot of uses you can optimize for clarity,
maintainability , and developer time over every last cycle of performance.
It's definitely still a tradeoff, just one that's shifted quite a ways.

>I have to say this is the same argument for the 4 day work week. "Soon,
we'll be productive enough that we'll only have to work 4 days a week."

I'm productive enough to earn far more than 125% of what I did a few years
ago. No myth here.

>If you make a program that takes an hour to do something, and someone comes
along and writes one that takes 5 minutes, you lose, no matter what the
program is written in.

Depends on the program. I have programs that run for an hour each day, that
could probably be cut down to 30 minutes (the difference would be changes in
DB usage and transactional consistency, not just reimplement in a different
language), but I have better things to worry about.

The VAST majority of programs aren't 12:1 difference. If you write a program
that takes 11 seconds to do something, and someone comes along and writes one
that does it in 10.6, but only on some platforms and in a hard-to-maintain
way, I think they lose.
--
Mark Rafn da***@dagon.net <http://www.dagon.net/>

[Lew]

mlw wrote:

Lew wrote:

>mlw wrote:

>>real 0m1.020s
user 0m0.860s
sys 0m0.092s
test@localhos t:~/scat$ time java test
Java heap space
Total object:741838

real 0m19.178s
user 0m16.893s
sys 0m1.728s

You're still not timing memory allocation but JVM startup and other
factors.

Start up is NOT 18 seconds, so what other factors could we possibly be
talking about?

Beats me.

-- Lew

[ITMozart]

mlw wrote:

Is there a way to create 10 to 100 million objects in Java with a reasonable
system configuration?

A question: this routine and the 10/100 million objects refer to a
real-world case or are just speculation?
What exactly the application do, in the overall?

I think that many of the speed/size speculation around are just applied
to micro-benchmarks, and that there is an absolute lack of real-world
benchmarks (entire applications converted from one language to another).

Micro-benchmarks haven't any real scientific value. But they are still
diffused because they're easy to develop.
It's very curious to me the fact that nobody would think about comparing
two F1-cars just by benchmarking their tires (!?), but the same approach
with programming languages implementations is commonly conceived as
perfectly reasonable and accurate by the programming community.

Quake 2 has been written in C by a absolute-history programming master
(John Carmack), in C and assembler.
Jake 2, the Java conversion, is 85% faster. This is impressive.

I stress that this is the only real-world benchmark which I've EVER
seen, and I would be EXTREMELY interested in real-world benchmarks, but
I still can't found any of them.

The entire story remembers me of an article written by Tom Miller:

http://msdn.microsoft.com/msdnmag/is...t/default.aspx

Bye!
IM

[ITMozart]

Lew wrote:

mlw wrote:

>Lew wrote:

>>mlw wrote:
real 0m1.020s
user 0m0.860s
sys 0m0.092s
test@localho st:~/scat$ time java test
Java heap space
Total object:741838

real 0m19.178s
user 0m16.893s
sys 0m1.728s
You're still not timing memory allocation but JVM startup and other
factors.

Start up is NOT 18 seconds, so what other factors could we possibly be
talking about?

Beats me.

-- Lew

Actually it doesn't beat you. Instead, it beats people which have enough
inexperience in a matter, to publish microbenchmarks in that specific
matter.

First law of microbenchmarks : microbenchmarks are flawed and misleading
by definition.
Corollary: Heisenbenchmark principle.

The following code demonstrate one flaw of the presented MB, regarding
the speed analysis.
There is [at least] another big flaw in the comparison, guess which.

Also, if we want to play the "speed freaks" game, it is possible, via
some simple and clean optimizations, to obtain about 5x speed and 1.5x
objects total at the same time.

/* --- */

class foo {
private String m_test;
foo(String value) { m_test = value; }
void print() { System.out.prin tln(m_test); }
};

public class LargeAllocation {
private static final int TOT_OBJS =
2000 * 1000; /* takes 8 secs for 914733 objects,
after which the JVM explodes */
// 900 * 1000; // FLAW: should take few less than 8 secs, right?

private static long start, end;

public static void main(String[] args) {
start = System.currentT imeMillis();

allocate(TOT_OB JS);

end = System.currentT imeMillis();
System.out.prin tln("Time: " + (end - start));
}

private static void allocate(int numObjs) {
int i = 0;
try {
foo arr[] = new foo[numObjs];
for (i = 0; i < numObjs; i++)
arr[i] = new foo(Integer.toH exString(i));
}
catch (OutOfMemoryErr or e) {
System.out.prin tln("Error: " + e.getMessage()) ;
System.out.prin tln("Total objects: " + i);
}
}
};

Bye!
IM