64 bit support

[Banjerboef]

I noticed that Algodoo is a 32 bit program (for x86 processors) a long time ago.
But because Algodoo is a 32 bit program it only supports a maximum amount of calculations.

Could you please add 64 bit support for 64 bit cpu's.
Algodoo will run a lot faster on 64 bit cpu's if it is a 64 bit program.

For example you could make an universal installation that selects the correct version (32 or 64 bit) depending on the detected cpu.
So, the customer downloads a downloader and the downloader downloads the correct version.
This way the customer won't be confused when choosing the correct version on the website!

Banjerboef

[monstertje3]

this would be really nice, but hard to code in a short time :\
a option like "app.64bitmode" would fit better then a downloader

[Banjerboef]

this would be really nice, but hard to code in a short time :\
a option like "app.64bitmode" would fit better then a downloader

I agree with every possibility as long as it enables a 64-bit mode!!!
It doesn't matter for me if it is a downloader or a code in the console, if it works I will be very happy with it.

[electronicboy]

The program would have to be nativly 64bit...

32 bit programs can only use 32-bit....
64 bit programs can only use 64-bit, and wont run on a 32-bit machine....
(this is based on what knowlege i have...)

all dll's and exe's would have to be compiled with 64-bit.

Two seperate installers would be better, as to help keep the download size down...

[Banjerboef]

Two seperate installers would be better, as to help keep the download size down...

That's why I requested a downloader that automatically detects the right version!!!

[electronicboy]

If that was to happen, offline installer MUST be avaliable....

But i really doubt that 64-bit support will be coming soon....

where best waiting for emanuel, jonaton or emil himself for a actual word on this...

there the developers, as you may know

[Banjerboef]

I think personally that there should be three downloads on the Algodoo site:
- 32 bit version, off-line installer
- 64 bit version, off-line installer
- a downloader, for people who don't know what version to choose

This way you can install Algodoo both off-line and on-line.

For example the downloader could download the file to the desktop, and then you or the installer can start the installation. With this method you always have an off-line installation.

It doesn't matter if you download the installation by hand or by downloader, because you have to download the installer anyway. When you have downloaded the installer, you can install Algodoo any time you want off-line.

But the off-line installer will be pointless, because you can only activate Algodoo when you are connected to the internet (the new licence system). So, the only thing you can do with the off-line installer is install a demo.

So, I'll wait for the response of one of the developers.
I really want to hear their opinion about this idea.

I personally think that 64-bit support is something that should have been added a long time ago.
Because did you see a new computer with a 32 bit cpu, I didn't!
Only the older computers have a 32 bit cpu, the newer ones all have a 64 bit cpu.

[monstertje3]

Maybe we should wait for this to happen, until 64-bit systems are more commonly used, and then it may be a perequiste for 64-bit support. At that time it would certainly happen if you ask me, algoryx is now developing features like better textures for newer video-cards. So algodoo is getting modern .

[Banjerboef]

until 64-bit systems are more commonly used

That is not true, 60-70% of all the computers are 64-bit systems and the amount is still growing.
As I said did you see a new computer with a 32-bit cpu, I didn't.
They all have a 64-bit cpu.

The only users with a 32-bit cpu are people in offices and people whom like to own the same computer as long as possible (why replace it if it still works?). So, those people aren't the biggest group of Algodoo users.

Wouldn't it be nice to run a 64-bit Algodoo on a 64-bit system, instead of a 32-bit Algodoo on a 64-bit system.
If Algodoo supports 64-bit, it is going to enable us to make bigger and less laggy scenes.
Because Algodoo can use more cpu power and make many more calculations per second.

Remember that 32-bit applications have a limited amount of calculations.
That means that it doesn't matter if you run Algodoo on a 1,4 ghz quad-core or a 2,2 ghz dual-core, because the maximum performance would be very close to each other in big scenes.
The dual-core will have to work hard, while the quad-core is almost idle.

This can be very frustrating if you have a quad-core!!!
You have the power, but you can't use it because Algodoo doesn't support it.
Does that sound familiar to any of you?

I have seen this for real recently.
My friend has a 1,4 ghz quad-core and I have a 1,9 ghz dual-core.
We both have a 64-bit cpu, thus we should be able to make a lot of calculations.
When we made a lot of polygons in our scenes, both our computers got laggy.
But when we looked at the "...% real-time" it turned out that his was running at 27% real-time and mine 22% real-time.
That's a difference of 5%, while it should be more than 50% when you look at the specs.

Isn't that strange, he has a good cpu and gpu that are both way better (and 4 year newer) than mine.
He should be able to get at least 50% real-time, but he didn't because of the limited amount of calculations.
So, he has a quad-core but can't use all the power of it.
That can be very frustrating!

[emilk]

...because Algodoo is a 32 bit program it only supports a maximum amount of calculations.
...
Algodoo will run a lot faster on 64 bit cpu's if it is a 64 bit program.

The major difference between 32bit and 64bit applications is that a lot more memory can be indexed; 32-bit is restricted to about 2^32 bytes ~= 4 GB of memory. Algodoo doesn't really need that much memory (not in normal usage anyhow), and so the gain from going from 32bit to 64bit is small when it comes to memory.

There is no "maximum amount of calculations" limit, nor does 32bit vs 64bit have anything to do with multicore support (as been suggested elsewhere on the forum).

Still, there may be a small performance gain to be expected by switching to the 64bit since it simply is the native word size. I expect this gain to be 10% at best, but there is also a risk that this will be offset by the fact that 64-bit applications require more memory, since all pointers and integers double in size.

To know for sure what gains, if any, 64-bit will bring I will have to test it, which will be some work. Algodoo depends on quite a few libraries that need to be recompiled for 64-bit, and I will probably also need to do some touch-ups on the code base to avoid compatibility problems. Still, I may reserve a week or so for this in the near future, once 2.0.1 is out of the door. Though maybe my time could be spent doing something more... creative. What do you guys think?

[Banjerboef]

I think that if you have spare time, you should test it.
64-bit supports more ram and thus more objects in the scene!

Think about it this way:
Why would you install a 32-bit Photoshop on a 64 bit system if you are able to install a 64-bit version?

Okay there is a small gain in performance, but a gain is a gain!!!
For some users it might look small, but for others it will be an improvement.
The goal is to make Algodoo faster, right.
Well, if you make a 64-bit version it will be faster (not much, but still).

I agree you should spend your time being creative, but if you have spare time or no creativity maybe you could spend that time working on 64 bit support.

By the way, that multicore thing was to demonstrate the frustration!!!
I know 32 and 64 bit have nothing to do with multicore.
I was just giving an example of an frustrating situation where a quad-core and dual-core have almost the same performance.

[Chronos]

64-bit supports more ram and thus more objects in the scene!

So that people with 32-bit systems, like me, can't run scenes made by people with 64-bit systems. Yeah, no thanks.

[Banjerboef]

So that people with 32-bit systems, like me, can't run scenes made by people with 64-bit systems. Yeah, no thanks.

No, now you are thinking wrong!!!
There is a upload limit of 15 MB, thus a scene cannot be bigger than that.

64-bit support only means that Algodoo can use more system ram and that there is a small performance gain.
That is very handy for people with 8 Gb of ram or more.
It is also handy for running the big scenes from Kilinich, because of the performance gain.
Big textured scenes (like Roman's) can be run much better, because Algodoo can use a lot more ram.

By the way, some people (with 32 and 64 bit systems) are already experiencing problems with running bigger scenes.
Like for example Kilinich Dakar Rally!!!
So, adding 64-bit support makes things better for the users of 64-bit systems.
And the file format stays the same, so you can always open the scenes.


And for the people whom think that Algodoo is never taking up so much ram, they are wrong!!!
I have experienced a crash caused by Algodoo taking up too much ram.
I happened because I had a lot of lasers and a lot of cubes and then it got slow.
Seconds after it got slow, I got a warning saying that my ram was full.
I have 3 Gb of ram and my system was taking up 1 Gb, thus Algodoo had taken up 2 Gb.

With this example I wanted to demonstrate that more ram could have prefented this from happening!!!
People whom have 8 Gb of ram don't have this problem, because they have enough ram.
The problem is that they can't use that amount of ram, because Algodoo is an 32-bit application.

And people aren't that evil that they are going to make big scenes that you can't run.
I am sure most of the people on Algobox will keep in mind that there are 32-bit users too.
I think that mostly the great creators (Roman, Kilinich, etc.) will keep this in mind.
And that they don't make their scenes too big.

[mori-d]

Hi emilk, it's time to release Algodoo 64bit version, isn't it?

[jon_joy_1999]

Hi emilk, it's time to release Algodoo 64bit version, isn't it?

it either is, or the performance gain suggested by banjobeef or w/e his name is isn't high enough to justify the time investment to make 64-bit viable

[electronicboy]

No, it isn't the time for a switch to 64 bit.

The issue is, is that as a 64 bit version is more powerful and can handle floats and other variables in larger numbers, it also increases the tolerance of "failure" in the programs.

so, a simulation that runs on x86 bit perfectly, could react completely differently to those with x64 and vice versa.

There is no way of making a program run the exact same in the background mathematics as for both x64 and x86.

I'm sure you all know, x64 bit processers technically don't run x86 software, the x86 support is actually provided by emulation, either hardware emulation or software, which is why algodoo is able to run on x64 machines as close to the same accuracy as the x86 CPU.

Until x86 is DEAD, Algodoo will remain x86. Yes, x86 is STILL used in, mostly in the School environment, which is where Algodoo is targeted at. Until x86 is fully known as dead, and most systems in the targeted region are x64 as well, I think that algodoo is going to stay for a few years.

Sorry if I'm sounding a bit rude or anything, I don't intend to be, I'm just having a bad phase...
/Electronicboy
-Please remember that this post is of my own opinion and knowledge, there may be mistakes, but either way, just remember that I'm not a worker for Algoryx.

[mori-d]

No, it isn't the time for a switch to 64 bit.

Don't switch. Release both version.

64bit application can use over 2GB address space.
And recent PC has 8GB or more physical memory.
You know what this means.

Floating-point accuracy? hah.
Scientists are already using 64bit Multi-core CPU and/or GPGPU (ex. CUDA).
Even though they have low-accuracy floating-point architecture.

Algodoo has no deterministic behavior.
It's more serious problem than floating-point accuracy.
Floating-point architecture is not a problem, I think.

[jon_joy_1999]

No, it isn't the time for a switch to 64 bit.

Don't switch. Release both version.

64bit application can use over 2GB address space.

I don't see a valid application for this; most scenes stay under 500MB, I've tried to make a basic scene that would reach the 2GB address limit, but the closest I could get was 16,000 circles in a grid, and it ran at 5% maximum speed, and consumed 1.3 GB of ram

And recent PC has 8GB or more physical memory.
You know what this means.

Floating-point accuracy? hah.
Scientists are already using 64bit Multi-core CPU and/or GPGPU (ex. CUDA).
Even though they have low-accuracy floating-point architecture.

Multi-core, and GPGPU processing is designed for slow parallel threaded processing, not fast single threaded processing. multi-threaded processing increases the speed for non-selfcolliding objects, like particles and fluids, but can decrease the speed of objects that do self-collide, or even introduce artifacts where two objects are supposed to collide, but don't, because each object is in it's own thread and does not "see" the other object

Algodoo has no deterministic behavior.

Algodoo should not be deterministic. real life physics are non-determinisitc, why should a physics simulator be deterministic?

It's more serious problem than floating-point accuracy.
Floating-point architecture is not a problem, I think.

[electronicboy]

The issue is, is that there will be a difference in the calculations that x64 and x86 executables will output, this is due to many of the changes between the two pieces of hardware.

The thing with physics simulation, is that we always have slight variations as of the FP accuracy, it's shocking how much 0.000001 can make on an overall simulation.


As also stated by jon_joy_1999, there is no real advantage of having two executables, it just makes it more of a pain for the devs to manage.
The only time Algodoo ever manages to come close to 2GB is in a fault condition (e.g. BIG memory leaks).

[mori-d]

My wish is to use Algodoo recompiled for x64. Just recompile. That's all.
Is it so difficult?
(I don't be wishing you to do big-refactoring)

I don't see a valid application for this; most scenes stay under 500MB, I've tried to make a basic scene that would reach the 2GB address limit, but the closest I could get was 16,000 circles in a grid, and it ran at 5% maximum speed, and consumed 1.3 GB of ram

A Japanese Phun user (not me) made a scene (realistic V-engine) recently.
He said that it didn't work because it reached memory limit.
So he reworked his thyme script to avoid memory limit.

Algodoo should not be deterministic. real life physics are non-determinisitc, why should a physics simulator be deterministic?

Is non-deterministic behavior a Algodoo's spec?
As far as I know, I heard it is a bug (very difficult bug), a few years ago at this forum...?
Am I wrong?

[mori-d]

A Japanese Phun user (not me) made a scene (realistic V-engine) recently.
He said that it didn't work because it reached memory limit.
So he reworked his thyme script to avoid memory limit.

It's possibly a big memory leak as electronicboy said.

[jon_joy_1999]

My wish is to use Algodoo recompiled for x64. Just recompile. That's all.
Is it so difficult?
(I don't be wishing you to do big-refactoring)

if you want Algodoo to utilize all of the features of 64-bit, it will need to be ported to the 64-bit environment, not just recompiled

Is non-deterministic behavior a Algodoo's spec?
As far as I know, I heard it is a bug (very difficult bug), a few years ago at this forum...?
Am I wrong?

do you mean viewtopic.php?f=11&t=6727&p=61162&hilit=deterministic#p61713 ?
even so, viewtopic.php?f=11&t=2611&p=31380&hilit=deterministic#p51022 is the reason behind the non-determinism of Algodoo

[mori-d]

Is non-deterministic behavior a Algodoo's spec?
As far as I know, I heard it is a bug (very difficult bug), a few years ago at this forum...?
Am I wrong?

do you mean viewtopic.php?f=11&t=672()7&p=61162&hilit=deterministic#p61713 ?
even so, viewtopic.php?f=11&t=2611&p=31380&hilit=deterministic#p51022 is the reason behind the non-determinism of Algodoo

No.
I couldn't find the topic...
The below topic is similar, but differ.
http://www.algodoo.com/forum/viewtopic.php?f=11&t=6926&start=0

In most scenes which I made before, simulation results differ anytime...
(chaotic results)
Start -> Stop (results A) -> undo
Start -> Stop (results B) -> undo
Start -> Stop (results C) -> undo
...

I'll upload bug-report after.

[mori-d]

if you want Algodoo to utilize all of the features of 64-bit, it will need to be ported to the 64-bit environment, not just recompiled

Usually just recompiling is enough, in case of x86 and x64.
What module should to be ported?

BTW, Are you a member of Algoryx?

[jon_joy_1999]

No.
I couldn't find the topic...
The below topic is similar, but differ.
http://www.algodoo.com/forum/viewtopic.php?f=11&t=6926&start=0

In most scenes which I made before, simulation results differ anytime...
(chaotic results)
Start -> Stop (results A) -> undo
Start -> Stop (results B) -> undo
Start -> Stop (results C) -> undo
...

I'll upload bug-report after.

they're not what I would define as non-deterministic. I would consider them bugs primarily, because they can be considered destructive (undo causing changes when it should not), although
the devil's advocate component to that is: these changes are happening on the micrometer scale, and Algodoo is not recommended below centimeters, thus the changes that are happening are magnitudes of order below specification, and should not be classified as a bug

Usually just recompiling is enough, in case of x86 and x64.
What module should to be ported?

64-bit has a fundamentally different instruction set than 32-bit, if they were to simply recompile then we would just have a 32 bit program that could access a whole ton of memory (not that this would be bad). if they were to port to 64-bit, they would be able to more effectively utilize the 64-bit instruction set, and have much better 64-bit utilization

BTW, Are you a member of Algoryx?

no, and if you have to ask, you'll never find out ~