Somehow there must be more to ontological observation than just simplified mathematical models and arbitrary mechanical metaphors to primitive approximations of thought.
As Rene Descartes put it:
"But there is I know not what being, who is possessed at once of the highest power and the deepest cunning, who is constantly employing all his ingenuity in deceiving me. Doubtless, then, I exist, since I am deceived; and, let him deceive me as he may, he can never bring it about that I am nothing, so long as I am conscious that I am something."
Cognito, ergo sum. That 'sum', however it exists (your state machines, a soul, whatever), is the essence of being; however it may occur, the sum is more than their parts.
Here's the output from running the following Java code:
byte[] buffer = new byte[1024];// Creating the buffer once
for (long loop = 0L; loop { buffer[loop % 1024] = 42;// some number }
And when running the JDK 1.2.2 VM with -verbose:gc you get a few GC messages at the beginning of the program, and then the GC never comes back.
However, stack-based short-lived objects *are* important for high-performance math. James Gosling is working on that as a possible future enhancement for the VM.
Just my 2-cents
-Chris
Yes, I know the code is contrived. I'm just trying to illustrate the fact that if you think before you allocate, Java is no slower in that regard than a manual "free-and-release" system like the standard C heap.
This isn't very practical for games though. Typically we want full control over the memory. We know the upper limit of what we need, and we don't care much about other applications. So we can allocate a large chunk at start time and then work within that, to avoid the new/delete/malloc/free overhead. If removing "antiquated" things like pointers is the best solution, then we'd all be writing games in Java. OK well that's a stretch but you see my point...
Memory allocation isn't your problem for game programming in Java... to paraphrase James Carville, "It's where the graphics are rendered, stupid" (no insult intended). You can do all of the memory allocation at the beginning of your application (I do it all the time with byte[] buffers for I/O), just like you would in C/C++. If the graphics rendering code is in Java, or uses software OpenGL renderers (like running Java3D in Windows NT), the performance sucks.
I think people have seen Applet-based games in Java and think "this sucks". Those Applets most likely use the AWT or Swing for their graphics rendering, and you see poor performance.
So what happens when one of your wizzy programmers *does* use memset? I understand what you're saying... every single serious C project I worked on had their own memory methods (most of cryptography programming I did used libraries that wouldn't let you touch the keys directly... and they made sure to zero out the memory when they were finished with the algorithm).
The point I'm making is that you can obfuscate with "my engine code APIs", but unless you do serious code reviews, untrained programmers can and will make mistakes.
So, companies using these assembler-with-plastic-surgery languages have two options:
Only hire expensive, brainy employees
Engage in weekly code review sessions where problems like "oops, I used memset" or "wait, I didn't set that to NULL... oops" are removed
-Chris
Of course... you could always #undef memset and redefine it as your Corrinne_Zero_Memory routine. Man, talk about ego... naming your APIs after yourself...:)
The first time I saw you use 'OT', I thought you meant you were working overtime...:)
Yeah, but those allocators won't save you at the point-of-failure:
memset(ptr,NULL,n);
They only kick in when:
Memory is freed
If you hit a guard page (if your OS supports it and you've put that into place with your heap allocator)
Why not just take away the ability to tweak memory like that? Besides performance numbers, what benefits are there for accessing memory directly (unless you're writing device drivers).
The only thing I can think of is taking advantage of OS specific operations (like memory-mapped files and completion ports in NT).
Which would wipe out anything... this is a problem will languages like C/C++, where they are just putting a pretty face on assembler.
Now, try and get around the class verifier in JDK 1.2... that will be a much harder task.
My response is: Why give a monkey a gun? Programmers with lots of experience will know what to do, but junior programmers (I bet you were a junior programmer once... try to think back...:D) are more likely to run amok without a little hand-holding. The fact that in C I can do:
char some_buf[512];
memset(some_buf,NULL,513);
and the execution is "undetermined", meaning that I could have wiped out something important on the stack but I won't know it until something crashes later is a big problem. I don't think you want to waste hours picking through dumps just to find that "Willy the Intern" blew it because C is an unfriendly place.
-Chris
Yes, the C code is contrived, but you get my idea.
> >-- It is thus easier to explicit document and comment linear C (non-base class referencing) code than OO code (which as well as you can describe its current behavior, you must reference back to its base class behavior to gain true understanding).
C'mon... how about "Macro Tricks in 21 days" cowboy coding coming from C programming wanna-bes? _That_ is unreadable code. Yes, you can make your C work in an object-oriented fashion, but if you want OO, then code in an OO language (or spend forever wondering why the build crashes because that junior programmer down the hall is still referencing a member variable you blew out days ago in your struct).
Finding the perfect base class is baloney anyways. What you want are contracts, not implementation, and mix-in base classes work great for that (or interfaces if you code in Java).
Garbage collection probably isn't your problem (unless you are polluting the heap with too many new objects). All of the good VMs use generational garbage collection (where long-living objects don't get bothered very often unless the heap is getting full).
The two toughest performance problems in Java are math (but C doesn't do a great job either, unless you explicitly walk the matricies in the right direction) and graphics (because all of the graphics bitblt crap goes on in user space instead of in the kernel like all of the other Win32 applications). As for good books on VMs in general, collecting dust on my bookshelf is the Ronald Mak book "Writing Compilers and Interpreters". Might be worth a look (but don't quote me-- I bought it on a whim).
In C++, most implementations I've seen generate a single VTBL per class. So, unless you are making lots o' classes in your applications, 4-bytes (the size of the VTBL pointer for a class, no matter what the depth of inheritance) per instance isn't too bad.
Interface inheritance is better, using empty base classes with pure virtual functions. You can mix those in and get those method contracts matched properly.
Or give up C++ and program in Java, where you don't have these nasty compiler problems.;)
Slashdot Mirror
Didn't "The Saint" from Maximum PC magazine talk about this last year?
As Rene Descartes put it:
Cognito, ergo sum. That 'sum', however it exists (your state machines, a soul, whatever), is the essence of being; however it may occur, the sum is more than their parts.-Chris
for (long loop = 0L; loop
Stupid entities... why can't /. support the tag???? :D
-Chris
byte[] buffer = new byte[1024]; // Creating the buffer once
for (long loop = 0L; loop { // some number
buffer[loop % 1024] = 42;
}
And when running the JDK 1.2.2 VM with -verbose:gc you get a few GC messages at the beginning of the program, and then the GC never comes back.
However, stack-based short-lived objects *are* important for high-performance math. James Gosling is working on that as a possible future enhancement for the VM.
Just my 2-cents
-Chris
Yes, I know the code is contrived. I'm just trying to illustrate the fact that if you think before you allocate, Java is no slower in that regard than a manual "free-and-release" system like the standard C heap.
Memory allocation isn't your problem for game programming in Java... to paraphrase James Carville, "It's where the graphics are rendered, stupid" (no insult intended). You can do all of the memory allocation at the beginning of your application (I do it all the time with byte[] buffers for I/O), just like you would in C/C++. If the graphics rendering code is in Java, or uses software OpenGL renderers (like running Java3D in Windows NT), the performance sucks.
I think people have seen Applet-based games in Java and think "this sucks". Those Applets most likely use the AWT or Swing for their graphics rendering, and you see poor performance.
Just my 2-cents.
-Chris
The point I'm making is that you can obfuscate with "my engine code APIs", but unless you do serious code reviews, untrained programmers can and will make mistakes.
So, companies using these assembler-with-plastic-surgery languages have two options:
-Chris
Of course... you could always #undef memset and redefine it as your Corrinne_Zero_Memory routine. Man, talk about ego... naming your APIs after yourself... :)
-Chris
In terms of looks, XiangHua is my favorite, followed by Yoshimitsu
Yeah, but those allocators won't save you at the point-of-failure:
memset(ptr,NULL,n);
They only kick in when:
- Memory is freed
- If you hit a guard page (if your OS supports it and you've put that into place with your heap allocator)
Why not just take away the ability to tweak memory like that? Besides performance numbers, what benefits are there for accessing memory directly (unless you're writing device drivers).The only thing I can think of is taking advantage of OS specific operations (like memory-mapped files and completion ports in NT).
-Chris
SomeClass* some_obj = ...; memset(some_obj,NULL,sizeof(some_obj));
Which would wipe out anything... this is a problem will languages like C/C++, where they are just putting a pretty face on assembler.
Now, try and get around the class verifier in JDK 1.2... that will be a much harder task.
My response is: Why give a monkey a gun? Programmers with lots of experience will know what to do, but junior programmers (I bet you were a junior programmer once... try to think back... :D) are more likely to run amok without a little hand-holding. The fact that in C I can do:
char some_buf[512];
memset(some_buf,NULL,513);
and the execution is "undetermined", meaning that I could have wiped out something important on the stack but I won't know it until something crashes later is a big problem. I don't think you want to waste hours picking through dumps just to find that "Willy the Intern" blew it because C is an unfriendly place.
-Chris
Yes, the C code is contrived, but you get my idea.
C'mon... how about "Macro Tricks in 21 days" cowboy coding coming from C programming wanna-bes? _That_ is unreadable code. Yes, you can make your C work in an object-oriented fashion, but if you want OO, then code in an OO language (or spend forever wondering why the build crashes because that junior programmer down the hall is still referencing a member variable you blew out days ago in your struct).
Finding the perfect base class is baloney anyways. What you want are contracts, not implementation, and mix-in base classes work great for that (or interfaces if you code in Java).
-Chris
The two toughest performance problems in Java are math (but C doesn't do a great job either, unless you explicitly walk the matricies in the right direction) and graphics (because all of the graphics bitblt crap goes on in user space instead of in the kernel like all of the other Win32 applications). As for good books on VMs in general, collecting dust on my bookshelf is the Ronald Mak book "Writing Compilers and Interpreters". Might be worth a look (but don't quote me-- I bought it on a whim).
Interface inheritance is better, using empty base classes with pure virtual functions. You can mix those in and get those method contracts matched properly.
Or give up C++ and program in Java, where you don't have these nasty compiler problems. ;)
-Chris