More than 1/2Gigs support \\ Multicore

[LShome]

1MB 1920x1080 picture
http://img851.imageshack.us/img851/6974 ... nntzuu.jpg

[Chronos]

This has nothing to do with it being 64-bit. Algodoo can only use 2 GB (Or was it only 1?) of RAM, and it currently has a memory leak, which will cause it to crash pretty fast, since it can't use anymore RAM.

[Someone Else]

A memory leak? If what I deduce from your post is correct, then it would work a lot better in Java.

Am I correct in thinking that a memory leak is what happens when the program fails to dispose of memory locations that it never uses again? So the program uses up more and more RAM?

[Chronos]

Am I correct in thinking that a memory leak is what happens when the program fails to dispose of memory locations that it never uses again? So the program uses up more and more RAM?

Indeed, and Algodoo has a pretty big one.

[Someone Else]

I take it Emil doesn't know Java.
Java would certainly fix the problem, but might make Algodoo run a bit slower. Or at least make Algodoo take a bit longer to start up.

I know that Java source code will compile into Java bytecodes- machine code for the Java Virtual Machine- which somebody should build someday.
Anyway, these Java bytecodes are then fed into a program (this is on the client's machine) that transforms them into machine code for that computer.
I'm not sure whether this small program interprets the bytecodes or uses a just-in-time compiler.
If the former is true for modern versions of Java, then the Java interpreter translates the bytecodes into machine code as they are needed. This causes the program to run slower than if it were compiled out of, say, C++.
If Java does indeed now use a JIT compiler, then the JIT compiler translates all the code at once- then immediately tells the program it just compiled to run. This, naturally, would take longer to start up, but then run at a pretty normal speed.

The upside to all this is that if you write a program in Java, you will instantly be able to run it on any computer, anywhere.

Java also forces you to do a few things that might make the program run slower, but smoother- such as exception catching and garbage collecting, which automatically seals all memory leaks.

[electronicboy]

i doubt that they will take a look into rewriting algodoo into a different language.
and is you said, Java is too slow for a CPU intensive application such as algodoo.

Secondly, i've heard that Java is easy to decompile, which is something that Algoryx are highly trying to avoid!

[LShome]

It would not run @ all - just cause Java is soooo sllooooww and Algodoo runs already slow.

As far as I know Algodoo is written in C++ using SDL?
Should not be a problem to use more than 1/2Gigs.

Oh and Algodoo would run WAY more faster if algoryx would just concentrate on their engine and allow multicores..
Cause It sucks to have 6 cores running @ 4GHz but the application supports only 1 core and does not even use its full potential ._.

EDiT: OpenCL would be great.... =]

[Someone Else]

I think that they should bury an option in Algodoo somewhere that allows you to set how many cores you want to use and how much RAM each is allowed to use. The first idea might be pretty difficult, but it may be possible to add a "buffer" program that coordinates multiple cores. The second idea, however, would be fairly easy. Maybe add an obscure Thume command?

I also think that they should optimize Java bytecodes, transferring laggy processes like garbage collection into less laggy processes such as creating/disposing memory slots in the initial compiling. That is, garbage disposal-based laggy source code would compile to less laggy types of bytecodes.

Do I make sense? I think not...