Re: [sqlite] x64 vs x32 DLL

[Warren Young]

On Nov 4, 2014, at 5:25 PM, Keith Medcalf  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
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[Keith Medcalf]

On Tuesday, 4 November, 2014 12:35, jose isaias cabrera 
 asked:

>I have an application that is written for x32 machines.  However, we now
>have a few machines that are x64 and all is well when we are using the
>precompiled x32 DLLs provided by http://www.sqlite.org/download.html.
>Changing the x32 DLLs to x64 DLLs, will it show any difference in speed
>on the x64 machines?  Thanks.

You did not specify the Operating System.  Very Few Operating Systems support 
intra-process thunking between x86 and x64 code segments.  This means that in 
order to use the x64 load library, your entire application will have to be 
re-compiled as x64.  Since you refer specifically to DLLs, one would assume you 
are speaking of Windows as the Operating System.

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.  Calling into kernel space will be slightly quicker because the x64 
kernel space is a DCSS (like the x86 kernel) which can be called directly, 
versus using the system trampoline and thunk code used to run x86 applications 
under an x64 version of Windows.  The application and operating system (and its 
services) will be 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.

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.  In truth, there 
may be significant reasons why it is preferred to keep an x86 userland, 
especially on Windows.

---
Theory is when you know everything but nothing works.  Practice is when 
everything works but no one knows why.  Sometimes theory and practice are 
combined:  nothing works and no one knows why.




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[James K. Lowden]

On Tue, 04 Nov 2014 22:20:23 +0200
RSmith  wrote:

> The best way to think of the 64 bit upgrade in normal programming is:
> "Able to do larger accuracy calculations at more or less the same
> speed".

Eh, more accurate how?  Every 32-architecture I compiled for supported
64-bit long integers.  Floating point is unchanged.  

The change is bigger address space, and consequently somewhat larger
and slower code.  "Able to address more memory" [virtual or real] is
how I'd put it.  

That makes some problems feasible that formerly were not.  And I'm not
so sure such problems are rare.  I remember when allocation 1 GB of
memory (virtual or not) was pure fantasy.  Nowadays laptops with 8 GB
of RAM are pretty pedestrian.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[David Woodhouse]

>
> On 2014/11/04 21:34, jose isaias cabrera wrote:
>> Greetings!
>>
>> I have an application that is written for x32 machines.  However, we now
>> have a few machines that are x64 and all is well when we are using the
>> precompiled x32 DLLs provided by http://www.sqlite.org/download.html.
>> Changing the x32 DLLs to x64 DLLs, will it show any difference in speed
>> on the x64 machines?  Thanks.
>
> Yeah, might even be slower, but so negligibly that you won't notice.
>
> Important to note (which many people seem to miss) is that the step up
> from 32 to 64 bit computing is an increase in computing
> accuracy and capacity, not in speed, though computations on historic 64
> bit variables (which used to be split up into two or more
> values to work) might be faster, but they generally make up less than 1%
> of the computations in any sane software system (though
> exceptions do exist) and so the speed increase is usually miniscule.  On
> the downside, a 64-bit system uses 64 bit values for all
> registers even where 32-bit values could have sufficed, and so all
> internal looping through bits or register shifts take longer, but
> generally by negligible amounts. (All modern processors are 64 bit anyway
> - 32 bit OSes still exist for legacy reasons only).
>
> It isn't a magic boost - The best way to think of the 64 bit upgrade in
> normal programming is: "Able to do larger accuracy
> calculations at more or less the same speed".


However, the switch from i386 to x86_64 isn't *just* a switch from 32-bit
to 64-bit like ppc32/ppc64 is. It *also* gives you a bunch more registers,
which certainly can make things significantly faster.

If you are looking at precompiled binaries then compatibility issues also
might be relevant. Code built for i386 might literally be compatible with
the 80386, using *no* new instructions added since then. Even if it
doesn't go that far but only supports i586, that still precludes some
important instructions like cmov.

Code built for x86_64, on the other hand, will have a 'lowest common
denominator' CPU feature set which is distinctly more modern. And which
even includes SSE2. So it might be faster for that reason too.

-- 
dwmw2

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[jose isaias cabrera]

"Stephan Beal" wrote...


On Tue, Nov 4, 2014 at 9:20 PM, RSmith  wrote:


miniscule.  On the downside, a 64-bit system uses 64 bit values for all
registers even where 32-bit values could have sufficed, and so all 
internal

looping through bits or register shifts take longer, but generally by
negligible amounts.



To add to that: the doubling of the size of a (void*) in 64-bit costs many
types of applications/libraries notably more memory, up to twice as much
for pointer-only structures.


Thank you both.  As we say in the beautiful Spanish language: muchas 
gracias.


josé 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[Stephan Beal]

On Tue, Nov 4, 2014 at 9:20 PM, RSmith  wrote:

> miniscule.  On the downside, a 64-bit system uses 64 bit values for all
> registers even where 32-bit values could have sufficed, and so all internal
> looping through bits or register shifts take longer, but generally by
> negligible amounts.
>

To add to that: the doubling of the size of a (void*) in 64-bit costs many
types of applications/libraries notably more memory, up to twice as much
for pointer-only structures.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[RSmith]

On 2014/11/04 21:34, jose isaias cabrera wrote:

Greetings!

I have an application that is written for x32 machines.  However, we now have a 
few machines that are x64 and all is well when we are using the precompiled x32 
DLLs provided by http://www.sqlite.org/download.html.  Changing the x32 DLLs to 
x64 DLLs, will it show any difference in speed on the x64 machines?  Thanks.


Yeah, might even be slower, but so negligibly that you won't notice.

Important to note (which many people seem to miss) is that the step up from 32 to 64 bit computing is an increase in computing 
accuracy and capacity, not in speed, though computations on historic 64 bit variables (which used to be split up into two or more 
values to work) might be faster, but they generally make up less than 1% of the computations in any sane software system (though 
exceptions do exist) and so the speed increase is usually miniscule.  On the downside, a 64-bit system uses 64 bit values for all 
registers even where 32-bit values could have sufficed, and so all internal looping through bits or register shifts take longer, but 
generally by negligible amounts. (All modern processors are 64 bit anyway - 32 bit OSes still exist for legacy reasons only).


It isn't a magic boost - The best way to think of the 64 bit upgrade in normal programming is: "Able to do larger accuracy 
calculations at more or less the same speed".



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users