You are not logged in.
Pages: 1
Hi
Since there is no 64 bit c(++) compiler available for XE3 (yet). I'd lite to move to 64bit, but is there another way to get to a 64bit sqlite3.obj ?
Or maybe there is another way we can use sqlite3 in delphi 64 bit somehow? e.g. using DLL's or something like that?
Hans
Offline
You may compile SQLite3.c with Visual C compiler for 64 bit target.
The .obj files should be compatible with Delphi XE2/XE3 64 bit targets.
But in this case, we will have to modify some low-level asm code included in SynSQLite3.pas.
Another option could be to use an external sqlite3.dll. Also some code refactoring needed in the very same unit. And you'll loose encryption feature.
There is nothing included by now.
Do you need 64 bit support?
IMHO there won't be any benefit on the server side, since SQLite3 will never use more memory than 32 bit provides, and external DB engine could be 64 bit server process, with a 32 bit client. And the 32 bit code generated by Delphi is faster - and less buggy - than the 64 bit version.
For the client, it could make sense, but for the server, in the mORMot implementation design, I do not think it is worth it by now to spend time creating a 64 bit process. Or perhaps you want to host it in ISS 64 bit, perhaps on Azure. Could make sense in this case.
What is your requirements?
Offline
What we are creating is a Simulation Server. The simulation server should be able to address huge amounts of memory since we want to have a "live" model of our objects (50M+) that interact with each other.
By changing properties of our "living objects" and next "harvesting" the results we are interested in we want to make a more or less real time simulation. The # of objects could easily take up more than 3 GB of RAM. Next to that we will require some cache for our NexusDB server and other stuff, so yes, we are really impatient to go 64 bit.
We decided not to create a "fat client" because in the end we might want to browse the harvested data using a tablet, phone or using the internet. Apart from that, the fat client would require sending all the object data over the network. This is definitely a no-no for us.
The fact that it's a little slower due to 64bit will be well compensated by the fact that our objects are all "alive" during a simulation session. Yes it will require somne serious server hardware, but hey, the server does not have to be portable.
(FYI Our previous version of the app processes each object from the DB fetched one-by-one / batched causing a way top much processing time when simulating changing properties. Hence the intention to have a "live" model)
Hans
Offline
You are right, in-memory model is the best for performance.
You may also use some tricks like hashing and using a pool of values, to reuse e.g. string instances.
I've seen much less memory use with such tricks.
So a 64 bit version of the framework could be handy in such cases, you are right.
It is in the road map.
If you have some hints or code to propose, you are welcome!
Offline
I saw this post on stack-overflow about addressing more than 2GB of memory with 32-bit Delphi.
http://stackoverflow.com/questions/1849 … 64-bit-win
Has anyone had success doing this or is it unreliable?
Offline
You can address 4Gb. See this topic http://synopse.info/forum/viewtopic.php?id=702
I use this feature in real project.
Last edited by mpv (2012-10-17 12:38:09)
Offline
Yes, but still for my model 'Limitless' memory (as in 2^64 bytes) defines a far more straightforward model for programing a simulation. I know there are hardware limitations, but we can go disk swapping until such vast amounts of RAM are in budget.
Offline
Pages: 1