x64 vs x32 DLL

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

x64 vs x32 DLL

jose isaias cabrera

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.

josé
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

R Smith

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

Stephan Beal-3
On Tue, Nov 4, 2014 at 9:20 PM, RSmith <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

jose isaias cabrera

"Stephan Beal" wrote...

> On Tue, Nov 4, 2014 at 9:20 PM, RSmith <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

David Woodhouse
In reply to this post by R Smith

>
> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

James K. Lowden
In reply to this post by R Smith
On Tue, 04 Nov 2014 22:20:23 +0200
RSmith <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

Keith Medcalf
In reply to this post by jose isaias cabrera

On Tuesday, 4 November, 2014 12:35, jose isaias cabrera <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: x64 vs x32 DLL

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