I had some major issues with Join/split’s on strings. Hard to track down because they happen randomly. I found out later it was mentioned at the bottom of the page here: http://developer.xojo.com/64-bit-guidelines
There are also issues with Define/Convert Encoding.
I’ll play with it but in the meantime, I also wait until Xojo itself ships as 64 bits.
[quote=235753:@Norman Palardy]They do not require 64 bit for the Mac App Store
They require 64 bit builds for the App Store for iOS which Xojo builds by default[/quote]
ok apart from that, what app do need 64 bits to be plenty functionnal ?
(except for linux where it seems to be a global stability issue)
It is not a problem of stability. New 64 bit versions of Linux simply do not support 32 bit executables. That is true of Desktop versions, as well as web servers.
Yes but you could install the 32-bit support libraries on 64-bit. It resulted in the 32-bit apps running but they were slow and some functions were not available (such as scrollbars on the ListBox in Ubuntu and probably other distros, etc. etc.) And some support libraries weren’t available such as webkit. It was very complicated, especially for end-users to get things working… It was a big mess. Now it’s not 
[quote=235766:@Jean-Yves Pochez]ok apart from that, what app do need 64 bits to be plenty functionnal ?
(except for linux where it seems to be a global stability issue)[/quote]
The IDE would be one I’m sure a number of our customers would love to see be 64 bit 
Databases (servers & clients)
Photo manipulation - medical imaging etc. We have a bunch of people writing those kinds of apps
Anything requiring extremely large data sets like genomics, protein analysis
There are a number of areas where huge data sets are quite normal
My hope was to see huge speed optimization… but my desktop database apps do not take profit on 64 bits… 
Well, I don’t think you’ll see any improvements in the database plugins until they move to the new framework for databases. Just look at SQLite on iOS to see where that’s going (for better or worse).
Same here.
I had high hopes that I would notice some speed increase in calculations (like pixel manipulation) or just standard things (like using larger datasets in listboxes). But so far I can’t say I noticed much from the LLVM optimizations. 
Note I didn’t say “speed” - this is mostly to do with the amount of data that can be accessed
Some things wont see a huge speed improvement - database plugins are already compiled with an optimizing compiler as is all the framework - so its unlikely to see big jumps.
Xojo code YOU write should be positively impacted by compiling for 64 bit since the compiler does more optimization than the 32 bit one did.
I have certainly noticed nice speed gains when compiling for 64 bit in my current project (medical imaging, lots of tight loops with pixel manipulation) so I think LLVM is having a positive impact on my code.
Looking forwards to a 64 bit IDE so I can finally try and code with Xojo on Ubuntu.
I’m currently using 64bit webapps in production for some of our tools. After a couple of early hiccups, it’s been better than 32bit for me since I deploy on 64bit ubuntu running ISPConfig. Just upload, change ownership to the particular account it runs under and that’s it. Permissions are already set properly and scp from my Mac to the server maintains those without any trouble.
What would be really cool is if I could figure out a way to script the process and do that straight from the IDE. It’d be a build and deploy button. Maybe I’ll look into that soon.
[quote=235795:@Norman Palardy]Note I didn’t say “speed” - this is mostly to do with the amount of data that can be accessed
Some things wont see a huge speed improvement - database plugins are already compiled with an optimizing compiler as is all the framework - so its unlikely to see big jumps.
Xojo code YOU write should be positively impacted by compiling for 64 bit since the compiler does more optimization than the 32 bit one did.[/quote]
ja database apps with a lot of smaller I/O access do not profit… even if 64Bit could boost them, the bottleneck still would be the network or disk. But today I’ve rechecked the XOJO Comanche Project we’ve once had here in forum. The speed improvement there is huge when using memoryblocks… XOJO Scripts of course are not supported in 64Bit… but there is a speed improvement in 32Bit too I would say… or is this El Capitan?
https://dl.dropboxusercontent.com/u/30535865/xojo/XOJOComancheWithScript.zip (with Collision Detection, HUD, MFDs and Maps, try the huge one!)
https://dl.dropboxusercontent.com/u/30535865/xojo/XOJOComancheMB.zip
32 bit should have no difference since it does not use LLVM as its compiler
Any improvements there must be from something else - possibly El Capitan and some optimizations
Maybe bug fixes in our framework etc
But not LLVM compiler optimizations of your code
The biggest thing most apps will get is access to huge amounts of memory
There may also be optimizations from using LLVM when compiling your code that make it speedier
It would be real nice to be able to create virtual volumes in RAM for ultra fast access. With the largest memory available in 64 bit, it would allow many things limited in 32 bit.
I’d just go with mounting a ramdisk
something like http://www.tekrevue.com/tip/how-to-create-a-4gbs-ram-disk-in-mac-os-x/
and there are ways to do this on other OS’ as well
VV’s I’m not sure of but I know they have some interesting complexities
The issue with Ramdisks is that they are visible to the user, with the risks of manipulation. Also, that is probably the kind of thing a sandboxed MAS app could never do.
Very likely
As I said VV’s have some complexities so dunno if they’ll ever be in memory
BUT you CAN make a Binary Stream backed by a memory block and so you have some ability to make an “in memory file”
And then there are in memory SQLIte databases too
We’re slowly updating to 64-Bit, I have a couple of internal only apps up and running, but the bigger apps will take time.
[quote=235817:@Norman Palardy]BUT you CAN make a Binary Stream backed by a memory block and so you have some ability to make an “in memory file”
And then there are in memory SQLIte databases too[/quote]
It could be entirely possible to create an in-memory disk and then have create some accessors so it looks and feel like a real disk. Heck you could even get it to dump and reload during application restoration.
Interesting concept.
That would probably be a way to speed up dramatically programs that rely on disk access.
I have no idea what would be implied to use in memory SQLIte databases, but that is probably the way to turbo boost programs that rely on database, much, much faster than any LLVM optimization. Of course it also implies the need to backup the database to a physical disk at the end of the program.