Page 1 of 1

32 bit vs 64 bit

Posted: Wed Apr 24, 2024 11:37 pm
by Mike V
I believe that Mike N focused on a 32 bit executable for TMSA to allow low-end machines to run it. I might be biased, but I have trouble imagining any machines nowadays, even ones a decade old, that can't easily run 64 bit software. Does anyone share the belief that it's important to stick to 32 bit architecture? Am I overestimating the prevalence of 64 bit OSes on peoples' desktops?

Re: 32 bit vs 64 bit

Posted: Thu Apr 25, 2024 6:11 am
by Jim Eshelman
When Mike made that decision, I think it was the right one in fact, he specifically made it because he posted 64-bit Astro 0.1 and somebody here couldn't run it, so he recompile as 32-bit.

Like you, I can't imagine this still being the case AND it might be. Otuers' responses and input would be welcome.

We found thst TMSA had problems on a Win 7 machine, so the practical question is whether anyone has a post-Win 7 computer thst is 32-bit architecture.

Meanwhile, what are the practical advantages of jumping to 64-bit?Thougu the program is calculation heavy, it's not slow at all.

Re: 32 bit vs 64 bit

Posted: Thu Apr 25, 2024 8:11 pm
by Mike V
The practical advantages of using 64-bit are mostly for development/distribution convenience. Everything everywhere assumes you're using 64-bit architecture and you need to opt-in to 32-bit behavior most of the time. The Swiss Ephemeris library which can do both, or rather, it can be compiled for either (and I have both on hand).

I'm running into issues based on trying to use a 64-bit setup without any changes to TMSA (I wanted to see what would happen, honestly), so it looks like I'll be compiling this as a 32-bit executable for now. I'll try to figure out where those differences are, though; I think being able to compile TMSA for either should be straightforward if it isn't yet. I imagine the Mac and Linux ports would pretty much be exclusively 64 bit, for example.

You're right in that the program is quite fast; though Python is not fast compared to many other development toolsets (it's something like 1% the speed of C, the gold standard), it's fast enough that we're hardly going to notice any difference for the things we're doing. Astrological work is calculation-heavy for a human, but this isn't very intensive for software, and calculation times should always be measured in milliseconds. If you notice any slowdown happening anywhere, there's a 99% chance that it's related to graphical rendering/Python runtime stuff and not actual-factual calculation.