On Nov 4, 2014, at 5:25 PM, Keith Medcalf <[email protected]> wrote:
> Assuming that you do rebuild the entire application as 64-bit, it will > consume at least twice the amount of memory as the x86 version and run slower > in user code. [citation needed] On 32-bit Cygwin: $ ls -lh `which sqlite3` -rwxrwxr-x 1 Warren None 66K Nov 4 03:00 /usr/bin/sqlite3 And on 64-bit Cygwin: $ ls -lh `which sqlite3` -rwxrwxr-x 1 Warren None 65K Nov 4 01:16 /usr/bin/sqlite3 I know you said “memory” and not “disk space,” but part of memory use is the size of the code loaded. Run time RAM use also shows no significant difference for the two versions of sqlite3.exe on Cygwin. If I say `sqlite3 nonexistent.db`, Windows Task Manager reports the same RAM usage (0.9 MB) on my machine for both executables. I then loaded up a 284 MB DB instead of the empty one. Initially, both builds of sqlite3.exe consumed about the same amount of RAM. After a few big SELECT calls, the 64-bit one was using 3.4 MB of RAM, while the 32-bit one was a bit slimmer, at 3.2 MB, a difference of only 6-8%, depending on whether you factor out the 0.9 MB constant or not. Note that the on-disk usage difference for the DB is always 0%, since SQLite’s DB format is platform-independent. That means the explanation for the RAM size difference probably comes down entirely to pointer size differences, which is swamped by the size of the actual data being managed. It’s also debatable whether the user space code will run slower. Every benchmark I’ve seen puts the difference down in the single-digit range, with the 64-bit code sometimes being the faster version. (64-bit code is sometimes a bit faster despite the single-digit percentage RAM hit because you don’t have to go through the WOW64 layer, the compiler can use wider data transfer instructions in some cases, etc.) You can wipe these tiny differences away by waiting for a few weeks’ worth of Moore’s Law improvements. > ...open to kernel mode code injection exploits when running x64 applications, > just like x86 applications on x86 kernels are open to such exploits, because > the kernel is mapped into the process address space. Such injection exploits > against x64 kernel code and processes being impossible from an x86 process. If you’re trying to protect against that, you should probably just be running your programs in a restricted VM, rather than depend on the WOW64 compatibility layer to break the exploit code. You’ve also left an implication here, that 32-on-32 and 64-on-64 have the same level risk. The 64-bit Windows kernel is a fair bit more secure than the 32-bit one, if only because Microsoft was finally able to remove some long-deprecated exploit paths. > Unless there is a specific reason for converting the entire application to > x64 (such as a requirement to access more than 3.9 GB of per-process memory) > or to take advantage of other specific architectural differences (which are > almost all entirely dependent on the compiler you choose) there is no > advantage to x64 applications over x86 applications on an x64 Operating > System. This is all true, as far as it goes. Security, speed, and RAM usage just aren’t good justifications. Want a good justification? Opportunity cost. Effort *not* spent converting is effort you can spend on something that gets you a benefit you *will* notice. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
