[sqlite] 64-bit SQLite3.exe (2019)

[RichardR]

Over three years ago I asked if the official CLI tools could be compiled as a
64-bit exe.

http://sqlite.1065341.n5.nabble.com/64-bit-SQLite3-exe-tp90771.html

I thought I would ask again...



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Michael Falconer]

Yes Richard,

in my experience your quoted time benefits are very much on target. I have
rewritten Excel/Access (VBA) which I originally developed (and was quite
proud of). Re-writes using C/C++ and SQLite indeed delivered the
performance gains you experienced and relieved me of the pain associated
with VBA development. A sort of win-win, and if you throw in moving away
from Windoze to something sensible you can get even more benefit. But that
is another tale...and sadly not always under our control.


On 19 August 2016 at 00:12, Rousselot, Richard A <
richard.a.rousse...@centurylink.com> wrote:

> Yes, it is much faster.  The process was done in Excel/Access before and
> took ages.  I have had processes go from 8 hours before to 30 min now using
> SQLite.
>
> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of Michael Gratton
> Sent: Wednesday, August 17, 2016 8:05 PM
> To: SQLite mailing list
> Subject: Re: [sqlite] 64-bit SQLite3.exe
>
>
> Richard,
>
> On Thu, Aug 18, 2016 at 2:23 AM, Rousselot, Richard A <
> richard.a.rousse...@centurylink.com> wrote:
> > I was only interested in doing these calculations quickly; that is my
> > real-world.  The SQL scripts I am using were built with multiple steps
> > with intermediate temp tables that are used to create a final result
> > table.
> >
> > I understand my needs are not generally how others use SQLite.  I am
> > using it as a platform for fast calculations that happens to store
> > results in a way that can be quarried.  Every time, my process begins
> > all prior results are deleted, only the input tables stay the same.
>
>
> Out of curiosity, are you using these in an end-user application, i.e.
> as an interactive response to user actions? I would be curious to know if
> building intermediate temporary tables is fast enough for returning results
> for such uses.
>
> Thanks,
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ <http://mjog.vee.net/>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Regards,
 Michael.j.Falconer.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Yes, it is much faster.  The process was done in Excel/Access before and took 
ages.  I have had processes go from 8 hours before to 30 min now using SQLite.

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Michael Gratton
Sent: Wednesday, August 17, 2016 8:05 PM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe


Richard,

On Thu, Aug 18, 2016 at 2:23 AM, Rousselot, Richard A 
 wrote:
> I was only interested in doing these calculations quickly; that is my
> real-world.  The SQL scripts I am using were built with multiple steps
> with intermediate temp tables that are used to create a final result
> table.
>
> I understand my needs are not generally how others use SQLite.  I am
> using it as a platform for fast calculations that happens to store
> results in a way that can be quarried.  Every time, my process begins
> all prior results are deleted, only the input tables stay the same.


Out of curiosity, are you using these in an end-user application, i.e.
as an interactive response to user actions? I would be curious to know if 
building intermediate temporary tables is fast enough for returning results for 
such uses.

Thanks,
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Michael Gratton]

Richard,

On Thu, Aug 18, 2016 at 2:23 AM, Rousselot, Richard A 
 wrote:
I was only interested in doing these calculations quickly; that is my 
real-world.  The SQL scripts I am using were built with multiple 
steps with intermediate temp tables that are used to create a final 
result table.


I understand my needs are not generally how others use SQLite.  I am 
using it as a platform for fast calculations that happens to store 
results in a way that can be quarried.  Every time, my process begins 
all prior results are deleted, only the input tables stay the same.



Out of curiosity, are you using these in an end-user application, i.e. 
as an interactive response to user actions? I would be curious to know 
if building intermediate temporary tables is fast enough for returning 
results for such uses.


Thanks,
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Simon,

I was only interested in doing these calculations quickly; that is my 
real-world.  The SQL scripts I am using were built with multiple steps with 
intermediate temp tables that are used to create a final result table.

I understand my needs are not generally how others use SQLite.  I am using it 
as a platform for fast calculations that happens to store results in a way that 
can be quarried.  Every time, my process begins all prior results are deleted, 
only the input tables stay the same.

I will pass the baton on to someone else to do more realistic, real world, 
testing of 32-bit vs 64-bit.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Simon Slavin
Sent: Wednesday, August 17, 2016 11:09 AM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe


On 17 Aug 2016, at 4:54pm, Rousselot, Richard A 
 wrote:

>PRAGMA journal_mode = Off;

This configuration is designed for cases where the resulting database will be 
thrown away soon (e.g. when the application quits).  It does increase speed 
greatly, but a consequence is that the benchmark is not useful as an indicator 
of performance in the real world.

Some of your other PRAGMAs also seem to be suitable only to running benchmarks 
quickly.  A fairer test, one more like real world performance, would be not to 
use any PRAGMAs at all apart from turning on FOREIGN KEYS.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Simon Slavin]

On 17 Aug 2016, at 4:54pm, Rousselot, Richard A 
 wrote:

>PRAGMA journal_mode = Off;

This configuration is designed for cases where the resulting database will be 
thrown away soon (e.g. when the application quits).  It does increase speed 
greatly, but a consequence is that the benchmark is not useful as an indicator 
of performance in the real world.

Some of your other PRAGMAs also seem to be suitable only to running benchmarks 
quickly.  A fairer test, one more like real world performance, would be not to 
use any PRAGMAs at all apart from turning on FOREIGN KEYS.

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

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Speed improvements based on 64-bit MinGW.

SQLite 3.14.2, built with MinGW 64-bit. - 
https://sourceforge.net/projects/mingw-w64/?source=typ_redirect
gcc -m64 -O2 -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -o sqlite3.exe
gcc -g -shared extension-functions.c -o extension-function.dll
Built with SQLITE options of default

Module SQL Script (146k records)T1 Sec  T2 Sec  T3 Sec  T4 Sec  Delta   
Delta   Delta
Processing Module 1 of 8: (CTEs)138 110 92  49  
125%150%282%
Processing Module 2 of 8:   26  20  17  14  130%
153%186%
Processing Module 3 of 8:   34  28  23  18  121%
148%189%
Processing Module 4 of 8:   14  7   6   5   200%
233%280%
Processing Module 5 of 8:   9   6   6   4   150%
150%225%
Processing Module 6 of 8:   30  14  12  11  214%
250%273%
Processing Module 7 of 8: (CTEs)290 222 212 86  131%
137%337%
Processing Module 8 of 8:   14  14  10  10  100%
140%140%
Total Processing Time:  557 424 374 200 131%
149%279%

Test 1: 32-Bit 3.13 (sqlite.org), No PRAGMA (Baseline)
Test 2: 32-bit 3.13 (sqlite.org), with PRAGMA but not temp_store = 2;
Test 3: 64 bit 3.14.2 MinGW, with PRAGMA but not temp_store = 2;
Test 4: 64 bit 3.14.2 MinGW, all PRAGMA

PRAGMAs used...
PRAGMA synchronous = 0;
PRAGMA read_uncommitted = 1;
PRAGMA locking_mode = exclusive;
PRAGMA journal_mode = Off;
PRAGMA temp_store = 2;

For reference both sets of tests on same machine; Windows 10, i5-3470 3.20GHz, 
12GB RAM and on internal spinning HDD.  There is a slight improvemnt (~5% 
faster) going to SSD but wanted to stay consistent.

I don't plan on testing Cygwin, I am happy with the MinGW results.

Thanks everyone for your help.

Richard

-Original Message-
From: Rousselot, Richard A
Sent: Monday, August 15, 2016 12:20 PM
To: sqlite-users@mailinglists.sqlite.org
Cc: Rousselot, Richard A
Subject: Re: [sqlite] 64-bit SQLite3.exe

Speed improvements based on 64-bit Visual Studio build.

SQLite 3.14.0, built with MSVC 18.00.30723 for x64.
Built with VS options /O2 /Ot /Ox.
Built with SQLITE options of SQLITE_ENABLE_FTS3 SQLITE_ENABLE_STAT2 
SQLITE_ENABLE_RTREE.

Module SQL Script (146k records)T1 Sec  T2 Sec  T3 Sec  T4 Sec  Sp Inc  
Sp Inc  Sp Inc
Processing Module 1 of 8: (CTEs)138  11096  56  
125%144%246%
Processing Module 2 of 8:   26  20  18  15  130%
144%173%
Processing Module 3 of 8:   34  28  26  21  121%
131%162%
Processing Module 4 of 8:   14  7   7   6   200%
200%233%
Processing Module 5 of 8:   9   6   5   4   150%
180%225%
Processing Module 6 of 8:   30  14  13  11  214%
231%273%
Processing Module 7 of 8: (CTEs)290 222 194 100 131%
149%290%
Processing Module 8 of 8:   14  14  11  11  100%
127%127%
Total Processing Time:  557 424 372 227 131%
150%245%

Test 1: 32-Bit 3.13 (sqlite.org), No PRAGMA (Baseline)
Test 2: 32-bit 3.13 (sqlite.org), with PRAGMA but not temp_store = 2;
Test 3: 64 bit 3.14.0 Visual Studio 18, with PRAGMA but not temp_store = 2;
Test 4: 64 bit 3.14.0 Visual Studio 18, all PRAGMA

PRAGMAs used...
PRAGMA synchronous = 0;
PRAGMA read_uncommitted = 1;
PRAGMA locking_mode = exclusive;
PRAGMA journal_mode = Off;
PRAGMA temp_store = 2;

I am still trying to figure out how to make a 64-bit build in MinGW.  There is 
a nice installer for 32-bit but not for 64-bit, go figure.

Hopefully I have the PRAGMAs right.  If there is a better configuration for 
speed, let me know.

Richard
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Correction on description:

Test 2: 32-bit 3.13 (sqlite.org), with PRAGMA but not temp_store = 2;

-Original Message-
From: Rousselot, Richard A
Sent: Monday, August 15, 2016 12:20 PM
To: sqlite-users@mailinglists.sqlite.org
Cc: Rousselot, Richard A
Subject: Re: [sqlite] 64-bit SQLite3.exe

Speed improvements based on 64-bit Visual Studio build.

SQLite 3.14.0, built with MSVC 18.00.30723 for x64.
Built with VS options /O2 /Ot /Ox.
Built with SQLITE options of SQLITE_ENABLE_FTS3 SQLITE_ENABLE_STAT2 
SQLITE_ENABLE_RTREE.

Module SQL Script (146k records)T1 Sec  T2 Sec  T3 Sec  T4 Sec  Sp Inc  
Sp Inc  Sp Inc
Processing Module 1 of 8: (CTEs)138  11096  56  
125%144%246%
Processing Module 2 of 8:   26  20  18  15  130%
144%173%
Processing Module 3 of 8:   34  28  26  21  121%
131%162%
Processing Module 4 of 8:   14  7   7   6   200%
200%233%
Processing Module 5 of 8:   9   6   5   4   150%
180%225%
Processing Module 6 of 8:   30  14  13  11  214%
231%273%
Processing Module 7 of 8: (CTEs)290 222 194 100 131%
149%290%
Processing Module 8 of 8:   14  14  11  11  100%
127%127%
Total Processing Time:  557 424 372 227 131%
150%245%

Test 1: 32-Bit 3.13 (sqlite.org), No PRAGMA (Baseline)
Test 2: 64-bit 3.14.0 Visual Studio 18, No PRAGMA
Test 3: 64 bit 3.14.0 Visual Studio 18, with PRAGMA but not temp_store = 2;
Test 4: 64 bit 3.14.0 Visual Studio 18, all PRAGMA

PRAGMAs used...
PRAGMA synchronous = 0;
PRAGMA read_uncommitted = 1;
PRAGMA locking_mode = exclusive;
PRAGMA journal_mode = Off;
PRAGMA temp_store = 2;

I am still trying to figure out how to make a 64-bit build in MinGW.  There is 
a nice installer for 32-bit but not for 64-bit, go figure.

Hopefully I have the PRAGMAs right.  If there is a better configuration for 
speed, let me know.

Richard
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Speed improvements based on 64-bit Visual Studio build.

SQLite 3.14.0, built with MSVC 18.00.30723 for x64.
Built with VS options /O2 /Ot /Ox.
Built with SQLITE options of SQLITE_ENABLE_FTS3 SQLITE_ENABLE_STAT2 
SQLITE_ENABLE_RTREE.

Module SQL Script (146k records)T1 Sec  T2 Sec  T3 Sec  T4 Sec  Sp Inc  
Sp Inc  Sp Inc
Processing Module 1 of 8: (CTEs)138  11096  56  
125%144%246%
Processing Module 2 of 8:   26  20  18  15  130%
144%173%
Processing Module 3 of 8:   34  28  26  21  121%
131%162%
Processing Module 4 of 8:   14  7   7   6   200%
200%233%
Processing Module 5 of 8:   9   6   5   4   150%
180%225%
Processing Module 6 of 8:   30  14  13  11  214%
231%273%
Processing Module 7 of 8: (CTEs)290 222 194 100 131%
149%290%
Processing Module 8 of 8:   14  14  11  11  100%
127%127%
Total Processing Time:  557 424 372 227 131%
150%245%

Test 1: 32-Bit 3.13 (sqlite.org), No PRAGMA (Baseline)
Test 2: 64-bit 3.14.0 Visual Studio 18, No PRAGMA
Test 3: 64 bit 3.14.0 Visual Studio 18, with PRAGMA but not temp_store = 2;
Test 4: 64 bit 3.14.0 Visual Studio 18, all PRAGMA

PRAGMAs used...
PRAGMA synchronous = 0;
PRAGMA read_uncommitted = 1;
PRAGMA locking_mode = exclusive;
PRAGMA journal_mode = Off;
PRAGMA temp_store = 2;

I am still trying to figure out how to make a 64-bit build in MinGW.  There is 
a nice installer for 32-bit but not for 64-bit, go figure.

Hopefully I have the PRAGMAs right.  If there is a better configuration for 
speed, let me know.

Richard
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Random Coder]

Sorry about that, fixed.

On Sat, Aug 13, 2016 at 11:38 AM, Rousselot, Richard A
 wrote:
> Your link says I do not have permission to open.
>
> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
> Behalf Of Random Coder
> Sent: Saturday, August 13, 2016 12:17 PM
> To: SQLite mailing list
> Subject: Re: [sqlite] 64-bit SQLite3.exe
>
> On Sat, Aug 13, 2016 at 8:39 AM, Rousselot, Richard A 
>  wrote:
>> Thanks, this does allow the library to load and process.  The thing is your 
>> build is by far the slowest I have received, slower even than the 32-bit 
>> version.
>
> Sorry about that, it was a debug build.
>
> https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64_release.zip
>
> Might be faster.
>
>> Could you tell me what version of SQLite you compiled, your compiler and the 
>> settings you used on each build?
>
> SQLite 3.14.0, built with MSVC 18.00.30723 for x64.  The debug version was 
> built with /Od, this version is built with /O2 /Ot /Ox.  Both versions are 
> built with the SQLITE options of SQLITE_ENABLE_FTS3
> SQLITE_ENABLE_STAT2 SQLITE_ENABLE_RTREE.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> This communication is the property of CenturyLink and may contain 
> confidential or privileged information. Unauthorized use of this 
> communication is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please immediately notify the sender by 
> reply e-mail and destroy all copies of the communication and any attachments.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[J Decker]

If you use cygwin (which noone ever should) make sure you to specify
-mno-cygwin or any output is significantly slower than any other build.
 (oh, I see that was deprecated several years ago, apparently now you just
get the slow code automatically in static format.)

(for instance one cause of slowness)
http://stackoverflow.com/questions/28410852/startup-is-really-slow-for-all-cygwin-applications

the runtime for file system access had heavy registry access because of
/cygdrive/xxx/  mapping support...



On Sat, Aug 13, 2016 at 10:17 AM, Random Coder 
wrote:

> On Sat, Aug 13, 2016 at 8:39 AM, Rousselot, Richard A
>  wrote:
> > Thanks, this does allow the library to load and process.  The thing is
> your build is by far the slowest I have received, slower even than the
> 32-bit version.
>
> Sorry about that, it was a debug build.
>
> https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64_release.zip
>
> Might be faster.
>
> > Could you tell me what version of SQLite you compiled, your compiler and
> the settings you used on each build?
>
> SQLite 3.14.0, built with MSVC 18.00.30723 for x64.  The debug version
> was built with /Od, this version is built with /O2 /Ot /Ox.  Both
> versions are built with the SQLITE options of SQLITE_ENABLE_FTS3
> SQLITE_ENABLE_STAT2 SQLITE_ENABLE_RTREE.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Your link says I do not have permission to open.

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Random Coder
Sent: Saturday, August 13, 2016 12:17 PM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe

On Sat, Aug 13, 2016 at 8:39 AM, Rousselot, Richard A 
 wrote:
> Thanks, this does allow the library to load and process.  The thing is your 
> build is by far the slowest I have received, slower even than the 32-bit 
> version.

Sorry about that, it was a debug build.

https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64_release.zip

Might be faster.

> Could you tell me what version of SQLite you compiled, your compiler and the 
> settings you used on each build?

SQLite 3.14.0, built with MSVC 18.00.30723 for x64.  The debug version was 
built with /Od, this version is built with /O2 /Ot /Ox.  Both versions are 
built with the SQLITE options of SQLITE_ENABLE_FTS3
SQLITE_ENABLE_STAT2 SQLITE_ENABLE_RTREE.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Random Coder]

On Sat, Aug 13, 2016 at 8:39 AM, Rousselot, Richard A
 wrote:
> Thanks, this does allow the library to load and process.  The thing is your 
> build is by far the slowest I have received, slower even than the 32-bit 
> version.

Sorry about that, it was a debug build.

https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64_release.zip

Might be faster.

> Could you tell me what version of SQLite you compiled, your compiler and the 
> settings you used on each build?

SQLite 3.14.0, built with MSVC 18.00.30723 for x64.  The debug version
was built with /Od, this version is built with /O2 /Ot /Ox.  Both
versions are built with the SQLITE options of SQLITE_ENABLE_FTS3
SQLITE_ENABLE_STAT2 SQLITE_ENABLE_RTREE.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Edward Lau]

Hi Richard:


I build my in the MinGW environment.   These executable are native windows 
executable. Cygwin, have a thin emulation layer to make POSIX compatible.  
However, the GCC compiler both uses should be fine and should able to figure 
the environment.


If your executable is compiled under Cygwin, you need to have the Cygwin 
environment inplace where your executable will run in.  As far as I can 
tell,you cannot mix the 2 (CygWin/MinGW) environments together ... easily.

I compiled it with the "-O2" , you can try with "-O3" option.  It will make the 
executable size larger.

Do you have any benchmark from the 32bit to compare with the 64bit.  I hunch is 
that there should be much speed different.  64bit may get your larger 
addressable memory.


Regards.


-Original Message-
From: Rousselot, Richard A 
To: SQLite mailing list 
Sent: Sat, Aug 13, 2016 9:30 am
Subject: Re: [sqlite] 64-bit SQLite3.exe

Additionally, I and others have got the Cygwin64 compiler to build 64-bit on 
both SQLite3 and the math extensions. Not optional since, as far as I know I 
need to install Cygwin64 on each machine that I will have running this process. 
 But one thing for Cygwin64 is that one of my colleagues got a 4x speed 
improvement, albeit changing a script from using a Ceil function (requires math 
lib) to a Round function (core function) for testing purposes.  I need to test 
myself to see if it is truly that much an improvement, I am dubious.

Richard

-Original Message-
From: Rousselot, Richard A
Sent: Saturday, August 13, 2016 10:40 AM
To: SQLite mailing list
Cc: Rousselot, Richard A
Subject: RE: [sqlite] 64-bit SQLite3.exe

Thanks, this does allow the library to load and process.  The thing is your 
build is by far the slowest I have received, slower even than the 32-bit 
version.

Could you tell me what version of SQLite you compiled, your compiler and the 
settings you used on each build?

I plan on compiling all the settings and speed tests of the builds I have 
received and tried to build myself.  It should be an interesting matrix.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Random Coder
Sent: Friday, August 12, 2016 4:54 PM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe

On Fri, Aug 12, 2016 at 10:06 AM, Rousselot, Richard A 
 wrote:
> I, and others, have tried to compile this as a 64-bit library but it will not 
> load from the command line (using .load) and gives the "Error: The specified 
> module could not be found."
>
> Anyone have tips on how to resolve this?  Is this library somehow 
> incompatible with 64-bit?

Generally that means the exports haven't been properly setup.  The easiest way 
to do this generally is to setup a .def file to get the proper function 
exported from the DLL with the correct naming convention.

I've done just that for a quick test version at 
https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64.zip , which may or may 
not work for your needs.  Other than verifying acos() was present, I've done no 
testing.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___sqlite-users mailing 
listsqlite-users@mailinglists.sqlite.orghttp://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Additionally, I and others have got the Cygwin64 compiler to build 64-bit on 
both SQLite3 and the math extensions. Not optional since, as far as I know I 
need to install Cygwin64 on each machine that I will have running this process. 
 But one thing for Cygwin64 is that one of my colleagues got a 4x speed 
improvement, albeit changing a script from using a Ceil function (requires math 
lib) to a Round function (core function) for testing purposes.  I need to test 
myself to see if it is truly that much an improvement, I am dubious.

Richard

-Original Message-
From: Rousselot, Richard A
Sent: Saturday, August 13, 2016 10:40 AM
To: SQLite mailing list
Cc: Rousselot, Richard A
Subject: RE: [sqlite] 64-bit SQLite3.exe

Thanks, this does allow the library to load and process.  The thing is your 
build is by far the slowest I have received, slower even than the 32-bit 
version.

Could you tell me what version of SQLite you compiled, your compiler and the 
settings you used on each build?

I plan on compiling all the settings and speed tests of the builds I have 
received and tried to build myself.  It should be an interesting matrix.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Random Coder
Sent: Friday, August 12, 2016 4:54 PM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe

On Fri, Aug 12, 2016 at 10:06 AM, Rousselot, Richard A 
 wrote:
> I, and others, have tried to compile this as a 64-bit library but it will not 
> load from the command line (using .load) and gives the "Error: The specified 
> module could not be found."
>
> Anyone have tips on how to resolve this?  Is this library somehow 
> incompatible with 64-bit?

Generally that means the exports haven't been properly setup.  The easiest way 
to do this generally is to setup a .def file to get the proper function 
exported from the DLL with the correct naming convention.

I've done just that for a quick test version at 
https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64.zip , which may or may 
not work for your needs.  Other than verifying acos() was present, I've done no 
testing.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Thanks, this does allow the library to load and process.  The thing is your 
build is by far the slowest I have received, slower even than the 32-bit 
version.

Could you tell me what version of SQLite you compiled, your compiler and the 
settings you used on each build?

I plan on compiling all the settings and speed tests of the builds I have 
received and tried to build myself.  It should be an interesting matrix.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Random Coder
Sent: Friday, August 12, 2016 4:54 PM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe

On Fri, Aug 12, 2016 at 10:06 AM, Rousselot, Richard A 
 wrote:
> I, and others, have tried to compile this as a 64-bit library but it will not 
> load from the command line (using .load) and gives the "Error: The specified 
> module could not be found."
>
> Anyone have tips on how to resolve this?  Is this library somehow 
> incompatible with 64-bit?

Generally that means the exports haven't been properly setup.  The easiest way 
to do this generally is to setup a .def file to get the proper function 
exported from the DLL with the correct naming convention.

I've done just that for a quick test version at 
https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64.zip , which may or may 
not work for your needs.  Other than verifying acos() was present, I've done no 
testing.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Random Coder]

On Fri, Aug 12, 2016 at 10:06 AM, Rousselot, Richard A
 wrote:
> I, and others, have tried to compile this as a 64-bit library but it will not 
> load from the command line (using .load) and gives the "Error: The specified 
> module could not be found."
>
> Anyone have tips on how to resolve this?  Is this library somehow 
> incompatible with 64-bit?

Generally that means the exports haven't been properly setup.  The
easiest way to do this generally is to setup a .def file to get the
proper function exported from the DLL with the correct naming
convention.

I've done just that for a quick test version at
https://new-bucket-2a9cf983.s3.amazonaws.com/sqlite64.zip , which may
or may not work for your needs.  Other than verifying acos() was
present, I've done no testing.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Scott Robison]

On Fri, Aug 12, 2016 at 12:02 PM, Warren Young  wrote:

> On Aug 11, 2016, at 7:50 PM, Scott Robison 
> wrote:
> >
> >> It’d be a lot of work just to avoid rebuilding for 64-bit, but maybe it
> >> would be an interesting project for someone.  Like a master’s university
> >> project, maybe.
> >>
> >
> > At first I thought to myself that a custom memory allocator for SQLite
> > could do this, but the real problem would be once a pointer is given to
> > SQLite, it is expected that pointer will be valid until disposed of
>
> Yeah, you’d need something like the handle lock/unlock pattern you see on
> some OSes, where the app generally holds only handles long-term, locking
> them down to yield a pointer only for the duration of a single function
> invocation at most.
>
> > Certainly a valuable tool for heavy processes that need to run on 32-bit
> > PAE hardware with > 4 GiB of addressable ram. Anyone want to start work
> on
> > SQLHeavy? ;)
>
> I was thinking more “valuable for the educational experience” than
> valuable in any practical sense, given the easy availability of 64-bit OSes
> and hardware.
>

Well, it certainly was practical at one point in time. I'm sure there are
still apps running on old servers that depend on its existence. As for
writing new code today that utilizes it, the utility is minimal if it even
exists.

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

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 11, 2016, at 7:50 PM, Scott Robison  wrote:
> 
>> It’d be a lot of work just to avoid rebuilding for 64-bit, but maybe it
>> would be an interesting project for someone.  Like a master’s university
>> project, maybe.
>> 
> 
> At first I thought to myself that a custom memory allocator for SQLite
> could do this, but the real problem would be once a pointer is given to
> SQLite, it is expected that pointer will be valid until disposed of

Yeah, you’d need something like the handle lock/unlock pattern you see on some 
OSes, where the app generally holds only handles long-term, locking them down 
to yield a pointer only for the duration of a single function invocation at 
most.

> Certainly a valuable tool for heavy processes that need to run on 32-bit
> PAE hardware with > 4 GiB of addressable ram. Anyone want to start work on
> SQLHeavy? ;)

I was thinking more “valuable for the educational experience” than valuable in 
any practical sense, given the easy availability of 64-bit OSes and hardware.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

Update to my 64-bit saga.

I was able to work with some helpful mailing list members to create a 64-bit 
SQLite3.exe.  Far as I can tell it works fine but unfortunately I also use the 
math extension library (extensions-functions.c) in my CTE queries which is also 
32-bit.

I, and others, have tried to compile this as a 64-bit library but it will not 
load from the command line (using .load) and gives the "Error: The specified 
module could not be found."

Anyone have tips on how to resolve this?  Is this library somehow incompatible 
with 64-bit?

Any insight would be appreciated.

Richard
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Scott Robison]

On Thu, Aug 11, 2016 at 6:37 PM, Warren Young  wrote:

> On Aug 11, 2016, at 3:19 PM, Scott Robison 
> wrote:
> >
> > I think you guys are just talking past each other.
>
> Well, at least one of us isn’t communicating clearly, that’s certain.  I
> just don’t yet know if it’s me, him, or both of us. :)
>

I'm just glad I never have problems expressing myself klearly.


> > Windows versions that
> > support PAE have the Address Windowing Extensions (AWE) which allows a
> > single process to access more than 4 GiB total in a single process
>
> From what I can see, AWE and PAE are orthogonal, but AWE without PAE
> doesn’t let you get beyond 4 GiB in a single process on IA-32.
>

Correct. AWE depends on PAE to enable windowed access into a memory space >
4 GiB. I've never used it so I don't know how much utility it might have
outside PAE. https://en.wikipedia.org/wiki/Address_Windowing_Extensions
probably gives a better summary that I could hope to.


> But — and this may be where Keith was trying to go — a 32-bit app running
> on a 64-bit OS doesn’t need PAE because the host system does support more
> than 4 GiB of virtual memory.  I have yet to see anything that says that
> AWE on 64-bit Windows couldn’t give a 32-bit app access to some of the VM
> beyond 4 GiB, even on consumer versions of Windows.
>

What I assumed was being said was that "sqlite.exe could access more than 2
GiB even on a 32 bit OS thanks to PAE" which is a true statement. I very
well may not have read something carefully enough and missed something
though.


> If so, that’s what I was trying to get at with my request that he give a
> reference to the specific technology he’s talking about, instead of
> describing it in prose.
>
> > That being said, I don't think it is a reasonable or practical thing to
> > expect of cross platform source code like SQLite to use such a platform
> > specific API.
>
> Couldn’t it be abstracted behind a layer that used mmap() + tmpfs to pull
> off a similar trick on other 64-bit OSes?  (I’m not talking about > 4 GiB
> on 32-bit OSes here.)
>

Perhaps, but I was only addressing the > 4 GiB on a 32-bit OS scenario. It
was a great solution for apps that needed to process a lot of data in
memory at one time back before AMD64 was a thing.

http://stackoverflow.com/questions/1709243/how-to-use-more-than-3-gb-in-a-process-on-32-bit-pae-enabled-linux-app
suggests that a 32-bit Linux system could use mmap to do the equivalent bit
of functionality.


> It’d be a lot of work just to avoid rebuilding for 64-bit, but maybe it
> would be an interesting project for someone.  Like a master’s university
> project, maybe.
>

At first I thought to myself that a custom memory allocator for SQLite
could do this, but the real problem would be once a pointer is given to
SQLite, it is expected that pointer will be valid until disposed of in some
way. It would take a lot of effort to make SQLite access pointers
indirectly so that the virtual address window could be set to the proper
physical memory range for every memory access. It would be returning to a
segment:offset scheme that I certainly do not miss.

Certainly a valuable tool for heavy processes that need to run on 32-bit
PAE hardware with > 4 GiB of addressable ram. Anyone want to start work on
SQLHeavy? ;)


> Still, it looks like we’re on the cusp of all the major OSes moving to
> 64-bit-only, so a lot of work made here might be obsolete soon.  OS X and
> RHEL have already made the leap.  Ubuntu and Microsoft both threatened to
> do this recently, but both backed down after user outcry.
>

Right. PAE & AWE (and related interfaces on other OSes) were a great
solution from 1994 until the end of the 32-bit server era. They might still
have some application, but with every passing day their utility diminishes,
I expect.

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

Re: [sqlite] 64-bit SQLite3.exe

[Keith Medcalf]

Well, so if you want to increase the process virtual memory limits of a 32-bit 
process on 64-bit windows you can set the LargeAddressAware flag on the 
executable.  While this will not give you access to a 64-bit address space, it 
will give you access to 4 GB per process less a few megabytes used for the 
trampoline (since the OS is no longer mapped into the process address space).  
Of course, unless you want problems the executable needs to be 32-bit clean.  
That means no "signed" addresses/pointers, and no diddling of the sign (or 
other) bits in the address field to contain some kind of overloaded information 
store.

SQLite is 32-bit clean.

> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of Warren Young
> Sent: Thursday, 11 August, 2016 14:38
> To: SQLite mailing list
> Subject: Re: [sqlite] 64-bit SQLite3.exe
> 
> On Aug 10, 2016, at 6:32 PM, Keith Medcalf  wrote:
> >> You must be talking about PAE, which is an unmitigated hack, in the
> >> dirtiest sense of that word
> >
> > It is not a hack.  It is how things work.  I do not see where you get
> the idea that it is a hack.
> 
> Because I know how PAE works, and I have the technical competence to
> express an informed opinion about it.
> 
> But if you don’t want to believe me, maybe you’ll believe Linus Torvalds:
> 
>   https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
> 
> > non-Windows have supported physical address limits beyond 4 GB as
> standard since a very long time (Linux since 2009).
> 
> Yes, via PAE.
> 
> If you mean something other than PAE, please give a technical reference to
> what you are talking about.  Like, maybe, a page in an Intel architecture
> reference manual.  Even a Wikipedia link would do.
> 
> >> As you hint, some OSes allow individual apps to allocate extra RAM via
> PAE
> >> — UnixWare was one such — but due to the way PAE works, it can never be
> >> more than 8 GiB per process at a given time.
> >
> > I hinted at no such thing.  The original quoted paragraph said "more
> than 4 GB of RAM".  This has nothing to do with the per-process allocation
> which is an artifact of how badly or ill-conceived the Operating System
> architecture and the physical implementation of the V:R handling.  Whether
> the machine and OS can physically address more than 4 GB of physical RAM
> has nothing whatsoever to do with the "bitedness" of the OS or the CPU,
> only the width of the physical address bus and the translation tables and
> hardware.
> 
> You’re describing PAE:
> 
>   https://en.wikipedia.org/wiki/Physical_Address_Extension
> 
> PAE required extending an IA-32 processor’s normal 32-bit address bus to
> 36 bits, giving a maximum virtual address space of 64 GiB.
> 
> PAE does not change the machine code instructions for accessing memory,
> since that would require recompiling everything to allow 36-bit addresses
> at the program level.  This would require another incompatible Intel
> instruction set, as different from IA-32 as IA-64 is.
> 
> If you look at the GCC manuals, you will not find a “PAE mode” flag for
> giving a binary with 36-bit addresses, because an IA-32 processor doesn’t
> offer that addressing mode.  Such a flag would be on this page in the GCC
> manual:
> 
>   https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html
> 
> Notice that there is no PAE flag, and no -m36 flag.  If you give -m64, you
> get IA-64 code, which won’t run on under a 32-bit kernel, even with PAE
> enabled.
> 
> You also won’t find such a compiler flag for Visual C++:
> 
>   https://msdn.microsoft.com/en-us/library/19z1t1wy.aspx
> 
> Though the OS kernel can use PAE to address more than 4 GiB via a 3-level
> TLB scheme — as opposed to the 2-level scheme Intel used before PAE — it
> doesn’t let a single program access more than 4 GiB at any given time.
> 
> Since this whole thread is about giving a single program — sqlite3.exe —
> access to more RAM, PAE doesn’t solve the OP’s problem.
> 
> You can install 32-bit Windows Server 2012 on a PAE-aware box with 16 GiB
> of RAM and run two instances of 32-bit sqlite3.exe on it, but they will
> only be able to chew up half the system’s RAM between themselves, no more.
> 
> >> Linux in particular doesn’t let individual applications use PAE to
> access
> >> more than 3 GiB of VM space, with the standard 3/1 user/kernel split.
> >> Instead, if you have more than 4 GiB of RAM in the machine and are
> running
> >> a PAE kernel, it will let you have multiple programs *collectively*
> using
> >> more than 4 GiB of VM space.  That’s not goin

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 11, 2016, at 3:19 PM, Scott Robison  wrote:
> 
> I think you guys are just talking past each other.

Well, at least one of us isn’t communicating clearly, that’s certain.  I just 
don’t yet know if it’s me, him, or both of us. :)

> Windows versions that
> support PAE have the Address Windowing Extensions (AWE) which allows a
> single process to access more than 4 GiB total in a single process

From what I can see, AWE and PAE are orthogonal, but AWE without PAE doesn’t 
let you get beyond 4 GiB in a single process on IA-32.

But — and this may be where Keith was trying to go — a 32-bit app running on a 
64-bit OS doesn’t need PAE because the host system does support more than 4 GiB 
of virtual memory.  I have yet to see anything that says that AWE on 64-bit 
Windows couldn’t give a 32-bit app access to some of the VM beyond 4 GiB, even 
on consumer versions of Windows.

If so, that’s what I was trying to get at with my request that he give a 
reference to the specific technology he’s talking about, instead of describing 
it in prose.

> That being said, I don't think it is a reasonable or practical thing to
> expect of cross platform source code like SQLite to use such a platform
> specific API.

Couldn’t it be abstracted behind a layer that used mmap() + tmpfs to pull off a 
similar trick on other 64-bit OSes?  (I’m not talking about > 4 GiB on 32-bit 
OSes here.)

It’d be a lot of work just to avoid rebuilding for 64-bit, but maybe it would 
be an interesting project for someone.  Like a master’s university project, 
maybe.

Still, it looks like we’re on the cusp of all the major OSes moving to 
64-bit-only, so a lot of work made here might be obsolete soon.  OS X and RHEL 
have already made the leap.  Ubuntu and Microsoft both threatened to do this 
recently, but both backed down after user outcry.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Scott Robison]

On Thu, Aug 11, 2016 at 2:37 PM, Warren Young  wrote:

> On Aug 10, 2016, at 6:32 PM, Keith Medcalf  wrote:
> >> You must be talking about PAE, which is an unmitigated hack, in the
> >> dirtiest sense of that word
> >
> > It is not a hack.  It is how things work.  I do not see where you get
> the idea that it is a hack.
>
> Because I know how PAE works, and I have the technical competence to
> express an informed opinion about it.
>
> But if you don’t want to believe me, maybe you’ll believe Linus Torvalds:
>
>   https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
>
> > non-Windows have supported physical address limits beyond 4 GB as
> standard since a very long time (Linux since 2009).
>
> Yes, via PAE.
>
> If you mean something other than PAE, please give a technical reference to
> what you are talking about.  Like, maybe, a page in an Intel architecture
> reference manual.  Even a Wikipedia link would do.
>

{a bunch of snipped stuff}

I think you guys are just talking past each other. Windows versions that
support PAE have the Address Windowing Extensions (AWE) which allows a
single process to access more than 4 GiB total in a single process, though
the application is responsible for what address ranges are mapped in or out
at any given point in time.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx

That being said, I don't think it is a reasonable or practical thing to
expect of cross platform source code like SQLite to use such a platform
specific API. A 64 bit build of SQLite should probably be used to address
memory > 4 GiB in the most straightforward / reasonable / compatible way.

So could a 32 bit build of SQLite access more than 4 GiB with appropriate
hardware & OS support? Sure. Should a 32 bit build of SQLite stretch to
support managing the address space itself as might be required? I don't
think so.

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

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 10, 2016, at 6:32 PM, Keith Medcalf  wrote:
>> You must be talking about PAE, which is an unmitigated hack, in the
>> dirtiest sense of that word
> 
> It is not a hack.  It is how things work.  I do not see where you get the 
> idea that it is a hack.

Because I know how PAE works, and I have the technical competence to express an 
informed opinion about it.

But if you don’t want to believe me, maybe you’ll believe Linus Torvalds:

  https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/

> non-Windows have supported physical address limits beyond 4 GB as standard 
> since a very long time (Linux since 2009).

Yes, via PAE.

If you mean something other than PAE, please give a technical reference to what 
you are talking about.  Like, maybe, a page in an Intel architecture reference 
manual.  Even a Wikipedia link would do.

>> As you hint, some OSes allow individual apps to allocate extra RAM via PAE
>> — UnixWare was one such — but due to the way PAE works, it can never be
>> more than 8 GiB per process at a given time.
> 
> I hinted at no such thing.  The original quoted paragraph said "more than 4 
> GB of RAM".  This has nothing to do with the per-process allocation which is 
> an artifact of how badly or ill-conceived the Operating System architecture 
> and the physical implementation of the V:R handling.  Whether the machine and 
> OS can physically address more than 4 GB of physical RAM has nothing 
> whatsoever to do with the "bitedness" of the OS or the CPU, only the width of 
> the physical address bus and the translation tables and hardware.

You’re describing PAE:

  https://en.wikipedia.org/wiki/Physical_Address_Extension

PAE required extending an IA-32 processor’s normal 32-bit address bus to 36 
bits, giving a maximum virtual address space of 64 GiB.

PAE does not change the machine code instructions for accessing memory, since 
that would require recompiling everything to allow 36-bit addresses at the 
program level.  This would require another incompatible Intel instruction set, 
as different from IA-32 as IA-64 is.

If you look at the GCC manuals, you will not find a “PAE mode” flag for giving 
a binary with 36-bit addresses, because an IA-32 processor doesn’t offer that 
addressing mode.  Such a flag would be on this page in the GCC manual:

  https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html

Notice that there is no PAE flag, and no -m36 flag.  If you give -m64, you get 
IA-64 code, which won’t run on under a 32-bit kernel, even with PAE enabled.

You also won’t find such a compiler flag for Visual C++:

  https://msdn.microsoft.com/en-us/library/19z1t1wy.aspx

Though the OS kernel can use PAE to address more than 4 GiB via a 3-level TLB 
scheme — as opposed to the 2-level scheme Intel used before PAE — it doesn’t 
let a single program access more than 4 GiB at any given time.

Since this whole thread is about giving a single program — sqlite3.exe — access 
to more RAM, PAE doesn’t solve the OP’s problem.

You can install 32-bit Windows Server 2012 on a PAE-aware box with 16 GiB of 
RAM and run two instances of 32-bit sqlite3.exe on it, but they will only be 
able to chew up half the system’s RAM between themselves, no more.

>> Linux in particular doesn’t let individual applications use PAE to access
>> more than 3 GiB of VM space, with the standard 3/1 user/kernel split.
>> Instead, if you have more than 4 GiB of RAM in the machine and are running
>> a PAE kernel, it will let you have multiple programs *collectively* using
>> more than 4 GiB of VM space.  That’s not going the help the OP.
> 
> And yet more of the same.  You are much confused between "CPU accessing 
> physical RAM (the :R part)" and "processes accessing virtual RAM (the V: 
> part).

Virtual memory still doesn’t solve the OP’s problem.

You can take a PAE-supporting box with 4 GiB of physical RAM in it, install a 
PAE-aware OS on it, then configure that OS for 60 GiB of swap to give 64 GiB of 
total virtual memory space, but the individual programs running under that OS 
*still* won’t be able to address more than 4 GiB of virtual memory each, 
because the memory addressing instructions will continue to use 32-bit pointers.

All virtual memory does in a situation like this is allow another program to 
come along and grab up to 4 GiB of virtual memory space itself.

That doesn’t help the OP, who is running a single program — sqlite3.exe — and 
needs it to address more than 4 GiB of memory.  It doesn’t matter whether you 
call it RAM, physical memory, or virtual memory, IA-32 simply doesn’t solve the 
OP’s problem, with or without PAE.

>> Quoting Wikipedia, “…regular application software continues to use
>> instructions with 32-bit addresses and (in a flat memory model) is limited
>> to 4 gigabytes of virtual address space…no single regular application can
>> access [all 64 GiB] simultaneously.”
> 
> And your point is what exactly?  We are not discussing per process access to 
> virtua

Re: [sqlite] 64-bit SQLite3.exe

[Michael Falconer]

Thanks Ryan,

and apologies for singling your comment out from the many that suggested a
roll-your-own CLI. That last statement pretty much says it all IMHO but I
would go even further. For many it will not even be choice in future times.
There will always be those who can make their own arrangements and hedge
around the inevitable but for most it will be 64bit or nothing one day. An
above post regarding Android 32 bit platform support is one indication that
the choices will not last for much longer. I should add that it is not
entirely high on my personal wish list (64bit CLI) because I do take the
valid points made earlier that the current CLI works just fine in a 32 bit
environment.

All of that being said, I have ultimate faith in the core SQLite
development team to make the right call about when it would be appropriate
to go the 64 bit path. There would be much to consider and it should be
considered carefully as always, I'm in no rush but apparently some others
have more pressing needs. Just as I am not in a rush, I also have no
problem with the OP's request being implemented. I'm with Ryan on the warm
and cuddly approach, we might as well.


On 11 August 2016 at 10:58, R Smith  wrote:

>
> On 2016/08/10 11:35 PM, Michael Falconer wrote:
>
>> ...// Ryan is very
>> right about the relative ease of such exercises but IMHO wrong that it
>> suits all, or even most cases.
>>
>
> Just to be clear - if my post wasn't, I never advocated against the 64-bit
> CLI or that making it suits all, I very much supported the OP in the
> request (and still do) for some of the reasons Michael mentions here. All I
> said was that right now (until it is supplied), if he needs it as much as
> claimed, rolling his own is not all that hard (and certainly not a useless
> skill).
> I do not agree with the notion that the 64-bit CLI "shouldn't be
> pre-compiled because it's easy to do it yourself" - if that was true, why
> supply the 32-bit even?, or indeed ANYthing pre-compiled?
>
> To reiterate: 64-bit is the new thing - let's embrace it!
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Regards,
 Michael.j.Falconer.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[R Smith]

On 2016/08/10 11:35 PM, Michael Falconer wrote:

...// Ryan is very
right about the relative ease of such exercises but IMHO wrong that it
suits all, or even most cases.


Just to be clear - if my post wasn't, I never advocated against the 
64-bit CLI or that making it suits all, I very much supported the OP in 
the request (and still do) for some of the reasons Michael mentions 
here. All I said was that right now (until it is supplied), if he needs 
it as much as claimed, rolling his own is not all that hard (and 
certainly not a useless skill).
I do not agree with the notion that the 64-bit CLI "shouldn't be 
pre-compiled because it's easy to do it yourself" - if that was true, 
why supply the 32-bit even?, or indeed ANYthing pre-compiled?


To reiterate: 64-bit is the new thing - let's embrace it!


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

Re: [sqlite] 64-bit SQLite3.exe

[Keith Medcalf]

> On Aug 10, 2016, at 6:03 AM, Keith Medcalf  wrote:

> >> Even on a 64-bit processor, there’s usually no reason to run 64-bit
> >> Windows unless you have more than 4 GB of RAM, a threshold we didn’t
> >> pass very long ago.

> > Yes, please remember to keep the "addressable memory limits" linkage to
> "processor bitted-ness" is a Microsoft Only phenomenon.  You do NOT need
> 64-bit processors or 64-bit Operating systems to be able to address more
> than 4 GB of physical RAM.  In fact that there are 32-bit versions of
> Windows (NT 3.5, 4.0, 2000, XP, 2003 etc) which have been compiled without
> this artificially imposed limitation.  You pay more for "properly written
> and compiled" software however because, well, it is easy to do stupid
> things and impose stupid limits for no reason and you need higher wattage
> (therefore more expensive people) if you want software that is not bounded
> by a crapload of inane if not brain-dead) design decisions.
> 
> You must be talking about PAE, which is an unmitigated hack, in the
> dirtiest sense of that word:
> 
>   https://en.wikipedia.org/wiki/Physical_Address_Extension

It is not a hack.  It is how things work.  I do not see where you get the idea 
that it is a hack.  In fact, non-Windows have supported physical address limits 
beyond 4 GB as standard since a very long time (Linux since 2009).

> As you hint, some OSes allow individual apps to allocate extra RAM via PAE
> — UnixWare was one such — but due to the way PAE works, it can never be
> more than 8 GiB per process at a given time.

I hinted at no such thing.  The original quoted paragraph said "more than 4 GB 
of RAM".  This has nothing to do with the per-process allocation which is an 
artifact of how badly or ill-conceived the Operating System architecture and 
the physical implementation of the V:R handling.  Whether the machine and OS 
can physically address more than 4 GB of physical RAM has nothing whatsoever to 
do with the "bitedness" of the OS or the CPU, only the width of the physical 
address bus and the translation tables and hardware.

> The OS *could* page in and out 4 GiB segments to give a single application
> the run of the whole 64 GiB maximum space PAE allows, but I don’t know of
> any OS that does this.


Again you are talking about per-process addressable space which is an entirely 
separate issue from physical addressable RAM size.
 
> Linux in particular doesn’t let individual applications use PAE to access
> more than 3 GiB of VM space, with the standard 3/1 user/kernel split.
> Instead, if you have more than 4 GiB of RAM in the machine and are running
> a PAE kernel, it will let you have multiple programs *collectively* using
> more than 4 GiB of VM space.  That’s not going the help the OP.

And yet more of the same.  You are much confused between "CPU accessing 
physical RAM (the :R part)" and "processes accessing virtual RAM (the V: part).

> Quoting Wikipedia, “…regular application software continues to use
> instructions with 32-bit addresses and (in a flat memory model) is limited
> to 4 gigabytes of virtual address space…no single regular application can
> access [all 64 GiB] simultaneously.”

And your point is what exactly?  We are not discussing per process access to 
virtual memory limitations, but rather artificial physical memory access 
limitations.  You will notice that even Microsoft admits that they limit access 
to physical RAM purely so they can make more money, and for no other reason,. 
and they do so in the very article you linked!

> I believe the situation is essentially the same on PAE-enabled versions of
> Windows as on Linux.

Again, you are confused between per process addressing of Virtual Memory and 
CPU access of Physical Memory.  Even 32-bit Linux has been able to access more 
than 4 GB of physical RAM since at least 2009.
 
> It is also the case that most machines that shipped with 32-bit Intel
> processors either didn’t have enough slots to allow > 4 GiB of RAM or
> didn’t have BIOS/EFI/chipset support for that much RAM if you did have the
> slots for it.  And why should they have done?  It just adds cost with a
> low chance that the user can make use of it, so that capability only
> showed up in high-dollar machines.

Nor did cheap motherboards wire the bus master request pin properly to the 
expansion bus even though the correct wiring was part of the "IBM compatible" 
specification.  Just because someone may choose to purchase low-end product 
does not mean that the capabilities for bus mastering (or in the case of the 
present conversation, accessing more than 4 GB of physical memory) does not 
validate your argument.

> PAE is also not restricted to non-Windows OSes.  Microsoft simply chose
> not to support it on the non-Server versions of Windows, but that is
> essentially a market segmentation issue, not a technical one.

Exactly -- it is an artifice to make more money for nothing.

> PAE’s time is long past.  64-bit is the proper solutio

Re: [sqlite] 64-bit SQLite3.exe

[John McKown]

On Wed, Aug 10, 2016 at 4:35 PM, Michael Falconer <
michael.j.falco...@gmail.com> wrote:

> Great discussion, if somewhat amusing (with a hint of deja vu) for an old
> hack like myself.
>
> I remember discussions like this back in CP/M days when it was a move rom 8
> to 16bit. Oh, and it all happened again when 32bit came along and yes now
> we are into 64bit and it carries on.
>

​A bit OT, but this entire thing is mildly amusing to me. I've worked on
the "obsolete" IBM mainframes for 30+ years. Originally 24 bit addressing;
then 31 bit (yeah, 31 not 32 - weird); now up to 64 bit. An guess what? The
programs that I wrote 30+ years ago in 24 bit still work correctly in
today's 31 ​and 64 bit systems as is without recompiling. Of course, the
programs don't use any of the new, fancy stuff. But they still work
correctly.


> --
> Regards,
>  Michael.j.Falconer.
>


-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Michael Falconer]

Great discussion, if somewhat amusing (with a hint of deja vu) for an old
hack like myself.

I remember discussions like this back in CP/M days when it was a move rom 8
to 16bit. Oh, and it all happened again when 32bit came along and yes now
we are into 64bit and it carries on.

Simple really, the OP is completely correct to be requesting a 64bit CLI as
we are now very much in that world. Of course a legacy 32bit version is
appropriate but surely the mainstream dev must move on to 64bit at  some
stage? Not for me to say when this should occur but surely it is inevitable
or am I just an old dinosaur?

Some excellent side points made (single out DD here) and one o the
standouts is the quite ridiculous stance many developers take regarding
user requests such as the one made in the OP. There is absolutely no
requirement at all for end users to be software developers/engineers, that
would be absurd and I doubt this was ever the intent of sqlite development.
Roll your own compilations in some cases are not an option and quite
possibly for multiple reasons. I'm not going to bore you by expanding the
obvious, but the OP identified one such case as a regulated corporate
environment, a beast I am unfortunately all too familiar with. Ryan is very
right about the relative ease of such exercises but IMHO wrong that it
suits all, or even most cases.

I may be old, but I'm a progressive dinosaur. We have to move on, and in
this biz, quickly if we want to remain in any way current. We can make
choices as developers about whether we embrace such things as OO or R or
whatever new methodology comes along but we don't get that same choice
about base system changes such as 16/32/64 bit processors. They are like
death and taxes, inevitable.

So when the 64bit CLI arrives, as it surely will do, the OP will be
vindicated and all the rest will be historic fluff. Just my opinion, but as
I said great discussion from my very favourite technical list.


On 11 August 2016 at 01:11, Jim Callahan 
wrote:

> The issue is not simply recompiling the CLI for 64-bit; I assume you want
> the tested reliability of SQLite.
>
> "The [SQLite] project has 787 times as much test code and test scripts" as
> it does source code for the executable.
> https://www.sqlite.org/testing.html
>
>
> Running the exact same tests would not be enough, because you (and I) would
> want special tests for larger than 4 GB
> RAM. So, additional tests would have to be developed.
>
> So, I see three alternate solutions:
>
> 1. Find a corporate sponsor to fund development of 64-bit SQLite CLI
>
> 2. Remove some tables from memory (though it sounds like your difficulties
> are caused
> by recursion rather than the size of the raw data)
>
> 3. Use SQLite for persistent storage but move the in memory (tree
> navigation) operations to another (open source)  language
> such as C, Java, Python or R (or the new Julia language that is approaching
> version 1.0)  that has interfaces for SQLite
> and a 64-bit build for Windows.  You will probably need another language to
> display the output anyway why not take
> advantage of Python, R or Julia?
>
> Even if you move to another language, you may find that your problem is
> recursion.
> In my experience, computer science textbooks give elegant examples using
> recursion,
> but then say the solution is not scale-able and give a less elegant
> solution using iterative techniques.
>
> Jim Callahan
> Data Scientist
> Orlando, FL
>
>
> On Tue, Aug 9, 2016 at 10:31 AM, Rousselot, Richard A <
> richard.a.rousse...@centurylink.com> wrote:
>
> > I would like to request a SQLite official 64-bit SQLite3.exe CLI (not
> DLL)
> > be created.
> >
> > I have reviewed the prior discussions regarding 64-bit SQLite3 and the
> > reasoning for which why creating a 64-bit version is denied are "it does
> > not make a real difference", "you can just use ram disks", etc., etc.
> >
> > Here is my plea...  I am using a set of complicated CTEs to crawl through
> > a network (tree) to aggregate and calculate formulas.  I don't have
> > exceptionally large datasets but my CTEs result in a ton of memory usage.
> > The process works well from disk, in Windows, but using a smaller test
> > sample I get about a 30% to 40% increase in processing time if I set the
> > PRAGMA to temp_store = 2.  If I use a normal dataset, not a small test, I
> > hit an approximate 2G limit and get a "out of memory" message, which I
> > understand is due to SQLite3.exe being 32-bit.  I have found some 3rd
> party
> > 64-bit builds for SQLite3 (best found is 3.8.5) but they are out of date
> > and don't allow all functionality that I am using.  So, I do have a use
> > case that requires 64-bit and I would see a significant increase in
> speed.
> >
> > As to RAM disks, I work in a corporate environment that locks down user
> > rights which precludes me from distributing a tool that requires the
> > creation of a tool that needs administrator rights.  I also, would like
> to
> > avoid ha

Re: [sqlite] 64-bit SQLite3.exe

[Jim Callahan]

The issue is not simply recompiling the CLI for 64-bit; I assume you want
the tested reliability of SQLite.

"The [SQLite] project has 787 times as much test code and test scripts" as
it does source code for the executable.
https://www.sqlite.org/testing.html


Running the exact same tests would not be enough, because you (and I) would
want special tests for larger than 4 GB
RAM. So, additional tests would have to be developed.

So, I see three alternate solutions:

1. Find a corporate sponsor to fund development of 64-bit SQLite CLI

2. Remove some tables from memory (though it sounds like your difficulties
are caused
by recursion rather than the size of the raw data)

3. Use SQLite for persistent storage but move the in memory (tree
navigation) operations to another (open source)  language
such as C, Java, Python or R (or the new Julia language that is approaching
version 1.0)  that has interfaces for SQLite
and a 64-bit build for Windows.  You will probably need another language to
display the output anyway why not take
advantage of Python, R or Julia?

Even if you move to another language, you may find that your problem is
recursion.
In my experience, computer science textbooks give elegant examples using
recursion,
but then say the solution is not scale-able and give a less elegant
solution using iterative techniques.

Jim Callahan
Data Scientist
Orlando, FL


On Tue, Aug 9, 2016 at 10:31 AM, Rousselot, Richard A <
richard.a.rousse...@centurylink.com> wrote:

> I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL)
> be created.
>
> I have reviewed the prior discussions regarding 64-bit SQLite3 and the
> reasoning for which why creating a 64-bit version is denied are "it does
> not make a real difference", "you can just use ram disks", etc., etc.
>
> Here is my plea...  I am using a set of complicated CTEs to crawl through
> a network (tree) to aggregate and calculate formulas.  I don't have
> exceptionally large datasets but my CTEs result in a ton of memory usage.
> The process works well from disk, in Windows, but using a smaller test
> sample I get about a 30% to 40% increase in processing time if I set the
> PRAGMA to temp_store = 2.  If I use a normal dataset, not a small test, I
> hit an approximate 2G limit and get a "out of memory" message, which I
> understand is due to SQLite3.exe being 32-bit.  I have found some 3rd party
> 64-bit builds for SQLite3 (best found is 3.8.5) but they are out of date
> and don't allow all functionality that I am using.  So, I do have a use
> case that requires 64-bit and I would see a significant increase in speed.
>
> As to RAM disks, I work in a corporate environment that locks down user
> rights which precludes me from distributing a tool that requires the
> creation of a tool that needs administrator rights.  I also, would like to
> avoid having to compile it myself; I am not a software engineer.
>
> Thanks for your consideration.
>
> Richard
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Andy Ling]

You still seem to have missed the point that several have made.

There are lots of people still using 32bit Windows. They cannot use a 64bit 
SQLite3.exe.
Therefore the 32bit one has to stay. The 32bit one will work on a 64bit OS, 
with restrictions.
The number of people who hit those restrictions is quite small. You are the 
only person
I can remember posting about hitting one. Most that do can build their own 
64bit exe.

So I guess currently the team have decided it isn't worth the effort to provide 
both exes
to support those few people. Maybe this will change if the number increase.

Regards

Andy


-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Rousselot, Richard A
Sent: Wed 10 August 2016 15:43
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe

First of all thanks for the discussion.  Special thanks out to DD. ;)

I will just summarize my main view.
* CTEs can easily exceed memory limits of the 32-bit SQLite3.exe.  So I have a 
valid need and am not on a crusade to kill 32-bits.  Telling me that other 
people don't have my problems is irrelevant, to me. :)

Response to all other banter; in good humor.
* The rest of the arguments about Microsoft currently shipping software that is 
32-bit, is a red herring.  I bet if you tried hard enough, you could find code 
from Windows 3.1 in Windows 10.  That wasn’t a properly thought out design 
decision.  That is laziness and frugality (possibly stupidity) on Microsoft's 
part.  I once read that MS would hire the developer of ReactOS so they could 
explain how their own operating system works.   (I digress)
* If I did figure out how to build the 64-bit executable, I guarantee, that it 
would be a catastrophe.  I can't even figure out how to post on Nabble for 
freaks sake. ;)
* I can still buy a VW bug designed in the 30s; does that mean that all new 
engines developed should have to fit in the back of that thing?
* I acquiesce on all other points, I am weary.

Finally, I just want to say I really appreciate the work that is put in to 
SQLite.  It is one of many tools I use on a day to day basis but it is the only 
one where I actively watch the discussions on a mailing list.  The regulars 
here are thoughtful, intelligent and infinitely patient.  I learn new things 
every day watching you guys and for that I thank you.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Keith Medcalf
Sent: Wednesday, August 10, 2016 7:03 AM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe


> Even on a 64-bit processor, there’s usually no reason to run 64-bit
> Windows unless you have more than 4 GB of RAM, a threshold we didn’t
> pass very long ago.

Yes, please remember to keep the "addressable memory limits" linkage to 
"processor bitted-ness" is a Microsoft Only phenomenon.  You do NOT need 64-bit 
processors or 64-bit Operating systems to be able to address more than 4 GB of 
physical RAM.  In fact that there are 32-bit versions of Windows (NT 3.5, 4.0, 
2000, XP, 2003 etc) which have been compiled without this artificially imposed 
limitation.  You pay more for "properly written and compiled" software however 
because, well, it is easy to do stupid things and impose stupid limits for no 
reason and you need higher wattage (therefore more expensive people) if you 
want software that is not bounded by a crapload of inane if not brain-dead) 
design decisions.  It is also quite profitable to claim that your prior 
incompetencies were to blame on "something else" and if everyone would just 
spend a boatload of money and replace all the defective crap we sold them with 
a new boatload of defective crap (every six months), a very few of the 
deliberately imposed limitations will be removed (plus we make yet another 
boatload of money by ripping off the customer).

> Or maybe you’d like to look to a less legacy-bound company?  Say,
> Google, who ships Chrome still built as 32-bit, originally for
> compatibility with 32-bit NSAPI plugins.  Since they dropped that, I
> can only guess why they’re still building 32-bit binaries, and that
> guess is that with the tab-per-process isolation, no single tab needs more 
> than 4 GB of VM space.

Or they are using defective compilers (primary supplier in that field is 
Microsoft) that cannot switch memory models without re-writing the code.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

First of all thanks for the discussion.  Special thanks out to DD. ;)

I will just summarize my main view.
* CTEs can easily exceed memory limits of the 32-bit SQLite3.exe.  So I have a 
valid need and am not on a crusade to kill 32-bits.  Telling me that other 
people don't have my problems is irrelevant, to me. :)

Response to all other banter; in good humor.
* The rest of the arguments about Microsoft currently shipping software that is 
32-bit, is a red herring.  I bet if you tried hard enough, you could find code 
from Windows 3.1 in Windows 10.  That wasn’t a properly thought out design 
decision.  That is laziness and frugality (possibly stupidity) on Microsoft's 
part.  I once read that MS would hire the developer of ReactOS so they could 
explain how their own operating system works.   (I digress)
* If I did figure out how to build the 64-bit executable, I guarantee, that it 
would be a catastrophe.  I can't even figure out how to post on Nabble for 
freaks sake. ;)
* I can still buy a VW bug designed in the 30s; does that mean that all new 
engines developed should have to fit in the back of that thing?
* I acquiesce on all other points, I am weary.

Finally, I just want to say I really appreciate the work that is put in to 
SQLite.  It is one of many tools I use on a day to day basis but it is the only 
one where I actively watch the discussions on a mailing list.  The regulars 
here are thoughtful, intelligent and infinitely patient.  I learn new things 
every day watching you guys and for that I thank you.

Richard

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Keith Medcalf
Sent: Wednesday, August 10, 2016 7:03 AM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe


> Even on a 64-bit processor, there’s usually no reason to run 64-bit
> Windows unless you have more than 4 GB of RAM, a threshold we didn’t
> pass very long ago.

Yes, please remember to keep the "addressable memory limits" linkage to 
"processor bitted-ness" is a Microsoft Only phenomenon.  You do NOT need 64-bit 
processors or 64-bit Operating systems to be able to address more than 4 GB of 
physical RAM.  In fact that there are 32-bit versions of Windows (NT 3.5, 4.0, 
2000, XP, 2003 etc) which have been compiled without this artificially imposed 
limitation.  You pay more for "properly written and compiled" software however 
because, well, it is easy to do stupid things and impose stupid limits for no 
reason and you need higher wattage (therefore more expensive people) if you 
want software that is not bounded by a crapload of inane if not brain-dead) 
design decisions.  It is also quite profitable to claim that your prior 
incompetencies were to blame on "something else" and if everyone would just 
spend a boatload of money and replace all the defective crap we sold them with 
a new boatload of defective crap (every six months), a very few of the 
deliberately imposed limitations will be removed (plus we make yet another 
boatload of money by ripping off the customer).

> Or maybe you’d like to look to a less legacy-bound company?  Say,
> Google, who ships Chrome still built as 32-bit, originally for
> compatibility with 32-bit NSAPI plugins.  Since they dropped that, I
> can only guess why they’re still building 32-bit binaries, and that
> guess is that with the tab-per-process isolation, no single tab needs more 
> than 4 GB of VM space.

Or they are using defective compilers (primary supplier in that field is 
Microsoft) that cannot switch memory models without re-writing the code.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 10, 2016, at 6:03 AM, Keith Medcalf  wrote:
> 
>> Even on a 64-bit processor, there’s usually no reason to run 64-bit
>> Windows unless you have more than 4 GB of RAM, a threshold we didn’t pass
>> very long ago.
> 
> Yes, please remember to keep the "addressable memory limits" linkage to 
> "processor bitted-ness" is a Microsoft Only phenomenon.  You do NOT need 
> 64-bit processors or 64-bit Operating systems to be able to address more than 
> 4 GB of physical RAM.  In fact that there are 32-bit versions of Windows (NT 
> 3.5, 4.0, 2000, XP, 2003 etc) which have been compiled without this 
> artificially imposed limitation.  You pay more for "properly written and 
> compiled" software however because, well, it is easy to do stupid things and 
> impose stupid limits for no reason and you need higher wattage (therefore 
> more expensive people) if you want software that is not bounded by a crapload 
> of inane if not brain-dead) design decisions.

You must be talking about PAE, which is an unmitigated hack, in the dirtiest 
sense of that word:

  https://en.wikipedia.org/wiki/Physical_Address_Extension

As you hint, some OSes allow individual apps to allocate extra RAM via PAE — 
UnixWare was one such — but due to the way PAE works, it can never be more than 
8 GiB per process at a given time.

The OS *could* page in and out 4 GiB segments to give a single application the 
run of the whole 64 GiB maximum space PAE allows, but I don’t know of any OS 
that does this.

Linux in particular doesn’t let individual applications use PAE to access more 
than 3 GiB of VM space, with the standard 3/1 user/kernel split.  Instead, if 
you have more than 4 GiB of RAM in the machine and are running a PAE kernel, it 
will let you have multiple programs *collectively* using more than 4 GiB of VM 
space.  That’s not going the help the OP.

Quoting Wikipedia, “…regular application software continues to use instructions 
with 32-bit addresses and (in a flat memory model) is limited to 4 gigabytes of 
virtual address space…no single regular application can access [all 64 GiB] 
simultaneously.”

I believe the situation is essentially the same on PAE-enabled versions of 
Windows as on Linux.

It is also the case that most machines that shipped with 32-bit Intel 
processors either didn’t have enough slots to allow > 4 GiB of RAM or didn’t 
have BIOS/EFI/chipset support for that much RAM if you did have the slots for 
it.  And why should they have done?  It just adds cost with a low chance that 
the user can make use of it, so that capability only showed up in high-dollar 
machines.

PAE is also not restricted to non-Windows OSes.  Microsoft simply chose not to 
support it on the non-Server versions of Windows, but that is essentially a 
market segmentation issue, not a technical one.

PAE’s time is long past.  64-bit is the proper solution today.

> It is also quite profitable to claim that your prior incompetencies were to 
> blame on "something else" and if everyone would just spend a boatload of 
> money and replace all the defective crap we sold them with a new boatload of 
> defective crap

So…the software development industry is at fault for not building all their 
apps for 64-bit from the start, going back to the 1950s?  Just think, you could 
be booting your Broadwell i7 into UNIX V1 today instead of this bloated Linux 
stuff!  What a great thing that would be!

>> Or maybe you’d like to look to a less legacy-bound company?  Say, Google,
>> who ships Chrome still built as 32-bit, originally for compatibility with
>> 32-bit NSAPI plugins.  Since they dropped that, I can only guess why
>> they’re still building 32-bit binaries, and that guess is that with the
>> tab-per-process isolation, no single tab needs more than 4 GB of VM space.
> 
> Or they are using defective compilers (primary supplier in that field is 
> Microsoft) that cannot switch memory models without re-writing the code.

Chrome runs just fine as a 64-bit executable.  It just wasn’t the default 
version until recently.  If you’ve been using it for a while, you will still be 
on the 32-bit version, as I am here.  You have to do a full reinstall to switch 
to the 64-bit version, which is now the default for new users on 64-bit systems.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Keith Medcalf]

> Even on a 64-bit processor, there’s usually no reason to run 64-bit
> Windows unless you have more than 4 GB of RAM, a threshold we didn’t pass
> very long ago.
 
Yes, please remember to keep the "addressable memory limits" linkage to 
"processor bitted-ness" is a Microsoft Only phenomenon.  You do NOT need 64-bit 
processors or 64-bit Operating systems to be able to address more than 4 GB of 
physical RAM.  In fact that there are 32-bit versions of Windows (NT 3.5, 4.0, 
2000, XP, 2003 etc) which have been compiled without this artificially imposed 
limitation.  You pay more for "properly written and compiled" software however 
because, well, it is easy to do stupid things and impose stupid limits for no 
reason and you need higher wattage (therefore more expensive people) if you 
want software that is not bounded by a crapload of inane if not brain-dead) 
design decisions.  It is also quite profitable to claim that your prior 
incompetencies were to blame on "something else" and if everyone would just 
spend a boatload of money and replace all the defective crap we sold them with 
a new boatload of defective crap (every six months), a very few of the 
deliberately imposed limitations will be removed (plus we make yet another 
boatload of money by ripping off the customer).

> Or maybe you’d like to look to a less legacy-bound company?  Say, Google,
> who ships Chrome still built as 32-bit, originally for compatibility with
> 32-bit NSAPI plugins.  Since they dropped that, I can only guess why
> they’re still building 32-bit binaries, and that guess is that with the
> tab-per-process isolation, no single tab needs more than 4 GB of VM space.

Or they are using defective compilers (primary supplier in that field is 
Microsoft) that cannot switch memory models without re-writing the code.




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

Re: [sqlite] 64-bit SQLite3.exe

[Dominique Devienne]

On Wed, Aug 10, 2016 at 11:47 AM, Warren Young  wrote:

> On Aug 10, 2016, at 3:22 AM, J Decker  wrote:
> > I'd think many of you would know 64 bit
> > mode has more general purpose registers to carry values and the default
> > calling ABI is improved to be more of a register centric model.
>
> SQLite is largely I/O bound.
>

With CTEs, you can go compute-bound.
OP already mentioned going over the 2GB limit for complex CTEs.
So that's no longer the whole truth. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Christian Schmitz]

> I agree, but now you're talking getting the amalgamation/repo and stuff (also 
> not exceedingly difficult, but granted will take a lot longer), he was 
> however not claiming having difficulty with that, the difficulty was only the 
> "learning how to make a build script" and that (in SQLite's case) is well 
> documented and can be done in minutes.


I'd also like to have prebuild console app and dlls for various platforms, so 
you don't need to build yourself just to try something.
Or when using official binaries, we could link to them and tell clients to 
update them independent of our software later.

Sincerely
Christian

-- 
Read our blog about news on our plugins:

http://www.mbsplugins.de/

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

Re: [sqlite] 64-bit SQLite3.exe

[R Smith]

On 2016/08/10 12:01 PM, Dominique Devienne wrote:

On Wed, Aug 10, 2016 at 11:52 AM, R Smith  wrote:


I disagree on the second point though - it isn't false. Have you set up a
script for building SQLite yet? It really is that easy.


A non-developer downloading 100's of MBs of compiler/IDE and trying to
figure it out for the very first time,
then getting the amalgamation (or worse the repo: fossile, etc...), using
the proper command line flags,
troubleshooting what's wrong, etc... 30 min, that's completely false for
people w/o that experience for 99% of people, if not more.


I agree, but now you're talking getting the amalgamation/repo and stuff 
(also not exceedingly difficult, but granted will take a lot longer), he 
was however not claiming having difficulty with that, the difficulty was 
only the "learning how to make a build script" and that (in SQLite's 
case) is well documented and can be done in minutes.


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

Re: [sqlite] 64-bit SQLite3.exe

[Dominique Devienne]

On Wed, Aug 10, 2016 at 11:52 AM, R Smith  wrote:

> I disagree on the second point though - it isn't false. Have you set up a
> script for building SQLite yet? It really is that easy.
>

A non-developer downloading 100's of MBs of compiler/IDE and trying to
figure it out for the very first time,
then getting the amalgamation (or worse the repo: fossile, etc...), using
the proper command line flags,
troubleshooting what's wrong, etc... 30 min, that's completely false for
people w/o that experience for 99% of people, if not more.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[R Smith]

On 2016/08/10 11:38 AM, Dominique Devienne wrote:

On Wed, Aug 10, 2016 at 11:11 AM, R Smith  wrote:

On 2016/08/10 7:39 AM, Rousselot, Richard A wrote:

I like learning as much as the next guy but I prefer to spend my time on
skills I can use in the future; compiling a 64-bit binary is not a useful
skill.//...


You spend several posts and a multitude of lines explaining how useful a
64-bit SQLite.exe would be for you - and then claim knowing how to make one
isn't a useful skill - LoL - There's documentation, it will take you less
than 30 minutes to set up a maker script (assuming you are completely green
on the subject, else probably 5 minutes).


Now that's both condescending and false IMHO...

I think people on this list who don't care or need it, and those not in a
position to do it or not (which leaves only DRH basically), so stop this
bashing of a simple and legitimate (again IMHO) request.

Lets move on. --DD


Apologies to the OP and Dominique both if it sounded condescending - not 
meant that way (and very definitely not meant to be bashful), I found it 
genuinely amusing.


I disagree on the second point though - it isn't false. Have you set up 
a script for building SQLite yet? It really is that easy.



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

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 10, 2016, at 3:22 AM, J Decker  wrote:
> 
> I'd think many of you would know 64 bit
> mode has more general purpose registers to carry values and the default
> calling ABI is improved to be more of a register centric model.

SQLite is largely I/O bound.

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

Re: [sqlite] 64-bit SQLite3.exe

[Dominique Devienne]

On Wed, Aug 10, 2016 at 11:11 AM, R Smith  wrote:
>
> On 2016/08/10 7:39 AM, Rousselot, Richard A wrote:
>>
>> I like learning as much as the next guy but I prefer to spend my time on
>> skills I can use in the future; compiling a 64-bit binary is not a useful
>> skill.//...
>>
>
> You spend several posts and a multitude of lines explaining how useful a
> 64-bit SQLite.exe would be for you - and then claim knowing how to make one
> isn't a useful skill - LoL - There's documentation, it will take you less
> than 30 minutes to set up a maker script (assuming you are completely green
> on the subject, else probably 5 minutes).
>

Now that's both condescending and false IMHO...

I think people on this list who don't care or need it, and those not in a
position to do it or not (which leaves only DRH basically), so stop this
bashing of a simple and legitimate (again IMHO) request.

Lets move on. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[J Decker]

I'm actually kind of surprised more people aren't like 'ya, why isn't 64
bit just available?' ( *pounds on tables* "We Want 64 Bit!", no? )
being fairly low level developers I'd think many of you would know 64 bit
mode has more general purpose registers to carry values and the default
calling ABI is improved to be more of a register centric model.
Both windows and linux 64 bit programs do run a hair faster than their same
32 bit builds.  It's not like night and day and I'd be surprised if it's as
high as 5% gain. Plus, who doesn't have more than 2G of memory and a 64 bit
system that's already responded?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[R Smith]

On 2016/08/10 7:39 AM, Rousselot, Richard A wrote:


I like learning as much as the next guy but I prefer to spend my time on skills 
I can use in the future; compiling a 64-bit binary is not a useful skill.//...


You spend several posts and a multitude of lines explaining how useful a 
64-bit SQLite.exe would be for you - and then claim knowing how to make 
one isn't a useful skill - LoL - There's documentation, it will take you 
less than 30 minutes to set up a maker script (assuming you are 
completely green on the subject, else probably 5 minutes).


That said, I would like to add my vote to adding a 64-bit SQLite3.exe - 
not so much because of the few people who may need it - but because it 
is the new thing, it is the way the World is moving. Sure people still 
need 32bit, but gradually it's changing over. I am sure pretty soon, if 
not the next release of Windows, things will have moved to 64-bit only. 
Apple is already there. (Plus refer the Android tools note by J. Decker) 
etc.


SQLite's mindset (If I may use the collective) to my understanding has 
always been that of a pioneer. Unlike Richard (the OP) I use the 32 bit 
CLI simply because it's available and works fine (meaning I have no 
reason to roll my own yet), but I will happily use the 64bit if it 
becomes available, which probably lots of others like me would do, and 
it will widen the user base and go a long way towards sussing out 
possible 64bit bugs/improvements and the like.




Ryan

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

Re: [sqlite] 64-bit SQLite3.exe

[David Empson]

> On 10/08/2016, at 5:50 PM, Rousselot, Richard A 
>  wrote:
> 
> I guess it is a matter of support.  Can the people using unpatched, 
> unsupported 32-bit windows instances just live with SQLite 3.13 (or whatever 
> the cutover version)?  Are these 32-bit windows users really actively 
> updating SQLite?

You are missing an important point: it isn’t only the processor architecture, 
but the Windows installation architecture which matters.

Windows Vista, 7, 8, 8.1 and 10 are/were all available in 32-bit. All of them 
are still supported by Microsoft.

There are a lot of PCs with 64-bit processors running 32-bit Windows, because 
that is how they were supplied or originally set up. I’m not talking ten year 
old computers: my work PC is a 2011 HP with a 64-bit Core i5 that was supplied 
with 32-bit Windows 7 (we’ve upgraded these PCs to Windows 10, but it is still 
32-bit Windows 10). There will be many newer 64-bit PCs also running 32-bit 
Windows.

Numbers will dwindle over time as PCs are replaced (or the occasional OS 
reinstall), but there is probably still a significant number of PCs running a 
supported 32-bit Windows.

If the only distributed build of sqlite3.exe was 64-bit, I expect it would 
inconvenience a fair number of people on 32-bit Windows who use an up-to-date 
version of SQLite including the command line tools, but can't build it 
themselves. (I can build it, so wouldn’t mind if this happened.)

The 32-bit build runs on 64-bit Windows, and is only a limit for those who need 
to do things with the command line tool that require more than 2 GB of memory.

Having both 32-bit and 64-bit versions would be ideal, probably with a plan to 
phase out the 32-bit version, but it would mean more work for the SQLite 
developers in the meantime.

> Can the command line tool interact with a driver?  How does a 32-bit windows 
> user get SQLite3.exe to run on a legacy 16-bit (windows 3.1?) machine?

Anything that old is not supported by SQLite 3.

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

Re: [sqlite] 64-bit SQLite3.exe

[J Decker]

On Tue, Aug 9, 2016 at 10:08 PM, David Empson  wrote:

>
> > On 10/08/2016, at 3:30 PM, Rousselot, Richard A  centurylink.com> wrote:
> >
> > As I said, I am not a software engineer.  I could spend a few hours
> figuring this out and be fine but it will be painful for me.
> >
> > I see no downsides in a 64-bit CLI.  The last 32-bit Intel CPU was the
> PIII in 2004, no supported Windows OS requires 32-bit CPUs, the file size
> may be marginally bigger but who cares on a PC.  The 64-bit version will, I
> assume, happily work on DBs created in the 32-bit version.  And for those
> that need 32-bit for their applications and drivers still have access to
> the 32-bit DLL.  What am I missing?  Are windows command line tools 32-bit
> only?
>
> A 32-bit installation of Windows cannot run 64-bit executables (ignoring
> VM solutions).
>
> Because of the large installed base of 32-bit Windows, the Windows command
> line tools for SQLite needs to be available as 32-bit versions. If 64-bit
> versions were provided, they would need to be in addition to the 32-bit
> versions.
>
> There are an awful lot of 32-bit installations of Windows. This includes a
> lot of 32-bit installations of Windows on 64-bit processors, which exist
> for many reasons including defaults offered by the manufacturer, lack of
> 64-bit drivers, corporate policy decisions, reduced memory footprint in
> limited machines, or the user requiring 32-bit Windows in order to be able
> to run legacy 16-bit software (again, ignoring VM solutions).
>
>
If you're going that way; Android just pulled x86 support for their dev
tools.  Turns out noone in QA had a 32 bit computer; and when they posted a
message about it there wasn't a lot of 'no wait! I have x86!' actually not
one reply; just me saying 'ya, I can see most development machines are 64
bit; although; you shuold provide a patch now; but retooling the QA dept
for 10% of the market doesn't really make sense
see their numbers aren't 90% 32 bit, but rather 90% 64 bit, so really it
shuld be the 64 bit that's provided,  and MAYBE the 32 bit in addition to
it.


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

Re: [sqlite] 64-bit SQLite3.exe

[Dominique Devienne]

On Tue, Aug 9, 2016 at 4:31 PM, Rousselot, Richard A <
richard.a.rousse...@centurylink.com> wrote:

> I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL)
> be created.
>

+1. You make a good point, and researched the issue. --DD

PS: Not sure why some want everyone to turn into programmers and a least
people compiling code...
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 9, 2016, at 11:39 PM, Rousselot, Richard A 
 wrote:
> compiling a 64-bit binary is not a useful skill

It keeps me fed pretty well. :)

> Your 32-bit Mac is not windows machine

What, you think Intel only made Core Solos for Apple?

> How long do I have to wait for everyone to upgrade?  So, if there is one 
> person in the universe still using a 32-bit windows machine we all have to 
> wait?

It would be interesting to get data on 32-bit vs 64-bit Windows installs.  I 
wouldn’t be surprised if it’s still more than 50% 32-bit.  It wasn’t that long 
ago that XP installs finally dropped below 50%, and a huge chunk of those were 
32-bit.

Even on a 64-bit processor, there’s usually no reason to run 64-bit Windows 
unless you have more than 4 GB of RAM, a threshold we didn’t pass very long ago.

>>> no supported Windows OS requires 32-bit CPUs
>> 
>> But equally, Microsoft retrenched from their threat to make Windows 10 the 
>> first 64-bit-only version of Windows.  Wonder why? :)
>> 
> Microsoft keeps 32-bit compatibility for legacy applications.

You mean like Visual Studio 2015, released less than a year ago today?  Yes, 
the VS IDE remains 32-bit, even though the underlying compilers will build 
64-bit executables.

Maybe you’d like to talk about PowerPoint?  The version currently on my 64-bit 
Windows 10 machine runs as 32-bit.

Or maybe you’d like to look to a less legacy-bound company?  Say, Google, who 
ships Chrome still built as 32-bit, originally for compatibility with 32-bit 
NSAPI plugins.  Since they dropped that, I can only guess why they’re still 
building 32-bit binaries, and that guess is that with the tab-per-process 
isolation, no single tab needs more than 4 GB of VM space.

>> Someone has to do it.  Time is not free.
>> 
> I agree, time is not free.   If I compile a 64-bit SQLite3.exe that only 
> helps me and wastes a lot of my time.

…And teaches you a useful skill that you may use later.

You say you don’t trust software from others.  What is a more trustworthy way 
to get executables than those you have built yourself from source code?

> The 64-bit version will probably shave an hour off my many 8 hour processing 
> jobs.

As a rule, 64-bit software runs a bit slower than 32-bit software on Intel 
CPUs.I/O channels all run the same speed, so for anything not CPU-bound, 
there is no advantage.  64-bit executables are a fair bit larger, which means 
you have more cache misses.  Unless you’re running something able to be highly 
register-optimized, you don’t get the only real speed advantage of Intel 64-bit 
CPUs, that being access to more registers.

> That will add up very quickly for me.

I’d love to study your benchmarks after you manage to get a 64-bit executable.

>>> Why add powerful features like CTE if you can't access their power?
>> 
>> Because most of the SQLite binaries are shipped by third parties, not 
>> directly from sqlite.org.
>> 
> This doesn't make sense, what does a 3rd party binary based on a dll have to 
> do with a command line tool?

I’m saying that the vast majority of SQLite users are not using the Windows EXE 
downloaded from sqlite.org, therefore the answer to your question asking how 
anyone could use powerful features like CTE and > 2 GB of RAM is that the vast 
majority of SQLite users aren’t affected by the lack of a 64-bit Windows 
executable.

If I run sqlite3 on my Mac, I get a 64-bit executable shipped by Apple.

If I run an app on my iPhone and it opens a SQLite DB, it runs a 64-bit version 
of SQLite also shipped by Apple.

Those two alone account for roughly a billion of the installations of SQLite.

> Are you saying that no one needs the command line tool so its development 
> should be abandoned?

What’s with the hyperbole?  100,000 users (my informed guess) is not zero; it 
is merely small compared to the total SQLite user base.  That small user base 
is further reduced by the number of those users who would actually benefit from 
a 64-bit Windows executable.

> Why spend time making a 32-bit version for the minority of people still 
> running 8 year old equipment?

You’re making an unwarranted assumption that the last 32-bit Windows 
installation was done in 2008 just because that was the last 32-bit Intel CPU 
introduction date.  (And the latter turns out to be incorrect anyway.)

Here’s an Atom E620, introduced in Q3 2010, 32-bit only, which you can still 
buy today:

  https://www.amazon.com/dp/B0137IIR88/ref=cm_sw_r_tw_dp_x_dxSQxb2J53HJC

Here’s a mini PC rocking a 32-bit Intel processor a couple of years newer than 
that one, still commercially available:

  https://www.amazon.com/dp/B00AXK56M4/ref=cm_sw_r_tw_dp_x_3DSQxbD1Q2K25

Here’s Intel’s complete 32-bit-only CPU product table, limited to current 
products only:

  http://goo.gl/jw1vyA

I get 122 results today.

And this totally ignores all the 64-bit Intel based boxes and VMs still running 
32-bit Windows for whatever reason.
__

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

I guess it is a matter of support.  Can the people using unpatched, unsupported 
32-bit windows instances just live with SQLite 3.13 (or whatever the cutover 
version)?  Are these 32-bit windows users really actively updating SQLite?

Can the command line tool interact with a driver?  How does a 32-bit windows 
user get SQLite3.exe to run on a legacy 16-bit (windows 3.1?) machine?

Sorry to press on this so much but I find all these arguments hollow.

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of David Empson
Sent: Wednesday, August 10, 2016 12:09 AM
To: SQLite mailing list
Subject: Re: [sqlite] 64-bit SQLite3.exe


> On 10/08/2016, at 3:30 PM, Rousselot, Richard A 
>  wrote:
>
> As I said, I am not a software engineer.  I could spend a few hours figuring 
> this out and be fine but it will be painful for me.
>
> I see no downsides in a 64-bit CLI.  The last 32-bit Intel CPU was the PIII 
> in 2004, no supported Windows OS requires 32-bit CPUs, the file size may be 
> marginally bigger but who cares on a PC.  The 64-bit version will, I assume, 
> happily work on DBs created in the 32-bit version.  And for those that need 
> 32-bit for their applications and drivers still have access to the 32-bit 
> DLL.  What am I missing?  Are windows command line tools 32-bit only?

A 32-bit installation of Windows cannot run 64-bit executables (ignoring VM 
solutions).

Because of the large installed base of 32-bit Windows, the Windows command line 
tools for SQLite needs to be available as 32-bit versions. If 64-bit versions 
were provided, they would need to be in addition to the 32-bit versions.

There are an awful lot of 32-bit installations of Windows. This includes a lot 
of 32-bit installations of Windows on 64-bit processors, which exist for many 
reasons including defaults offered by the manufacturer, lack of 64-bit drivers, 
corporate policy decisions, reduced memory footprint in limited machines, or 
the user requiring 32-bit Windows in order to be able to run legacy 16-bit 
software (again, ignoring VM solutions).

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

>On Aug 9, 2016, at 9:30 PM, Rousselot, Richard A 
> wrote:
>
>> I could spend a few hours figuring this out and be fine but it will be 
>> painful for me.
>
>Or you can spend many hours waiting for someone to build it for you.  How many 
>hours are you willing to wait to save yourself some pain?  (And since when did 
>learning something new cause pain?)
>
I like learning as much as the next guy but I prefer to spend my time on skills 
I can use in the future; compiling a 64-bit binary is not a useful skill.  I 
may wait for someone to compile and provide it to me but I am really wary of 
getting code from strangers these days.  I tend to trust the SQLite team.

>As to your problem with corporate IT, will they let you install Cygwin?  
>SQLite is well-supported in Cygwin, and there is a 64-bit version of Cygwin.  
>Due to the way Cygwin works, all packages available for 64-bit Cygwin are also 
>64-bit.
>
I would probably have an easier time getting a Mac (impossible) than get Cygwin 
installed at work. :)

>Cygwin SQLite should be nearly as fast as native SQLite.  There are some big 
>speed hits in Cygwin, but for the things SQLite does, I can’t see that you’re 
>going to run into any of the biggest ones.
>
>> The last 32-bit Intel CPU was the PIII in 2004
>
>That’s simply not true.  Many P4s were 32-bit, the Atom processors were 32-bit 
>only until 2008, and I believe the Core Solo processors were also 32-bit only.
>
>(That latter caused a lot of trouble for me when Apple went 64-bit only and 
>cut off a bunch of the still-useful Macs I had still in use.)
>
Ok, P4 in 2008 that is still 8 years ago.  (Your 32-bit Mac is not windows 
machine).  How long do I have to wait for everyone to upgrade?  So, if there is 
one person in the universe still using a 32-bit windows machine we all have to 
wait?

>> no supported Windows OS requires 32-bit CPUs
>
>But equally, Microsoft retrenched from their threat to make Windows 10 the 
>first 64-bit-only version of Windows.  Wonder why? :)
>
Microsoft keeps 32-bit compatibility for legacy applications.  I don't consider 
and actively developed piece of software from 2016 a legacy application, do you?

>> The 64-bit version will, I assume, happily work on DBs created in the 32-bit 
>> version.
>
>Yes.
>
>> What am I missing?
>
>Someone has to do it.  Time is not free.
>
I agree, time is not free.   If I compile a 64-bit SQLite3.exe that only helps 
me and wastes a lot of my time.  I bet Dr. Hipp et al could have that thing 
(build scripts at least) complied in a matter of minutes and his work would be 
available for anyone in the world to use.  Why not, on the other hand, save 
some time by not compiling the 32-bit version?

The 64-bit version will probably shave an hour off my many 8 hour processing 
jobs.  That will add up very quickly for me.

>> Are windows command line tools 32-bit only?
>
>The opposite, actually: the first 64-bit versions of the Visual C++ tool set 
>were command-line only, as I recall.  I believe that was back in the 
>pre-VC++2005 days.
>
>> Why add powerful features like CTE if you can't access their power?
>
>Because most of the SQLite binaries are shipped by third parties, not directly 
>from sqlite.org.  The biggest sources are OSes (virtually all mobile phones, 
>Mac OS X, Windows, etc.) and third-party applications (virtually all web 
>browsers, many Adobe and Apple products, etc.)  These third parties built 
>SQLite to meet their needs.
>
This doesn't make sense, what does a 3rd party binary based on a dll have to do 
with a command line tool?  Are you saying that no one needs the command line 
tool so its development should be abandoned?

>I’d bet the number of regularly run instances of binaries downloaded directly 
>from sqlite.org is under 0.01% of the total usage of SQLite.
>
>(That’s a considered guess, not a wild guess.  There are billions of SQLite 
>instances in the world, and I’m betting there are less than 100,000 users of 
>the SQLite.org binaries.  I wouldn’t be surprised if it’s under 0.001%.)
>
>Of that tiny percentage, only a small fraction will actually need a 64-bit, 
>and of that fraction of a fraction, only a small number will be unable to 
>acquire or build a 64-bit binary.
>
>Why spend a lot of effort on such a small user base?
>
A 64-bit SQLite3.exe would help the whole user based of command line users.  
Why spend time making a 32-bit version for the minority of people still running 
8 year old equipment?  It's not like they can't download an older 32-bit 
version.
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglist

Re: [sqlite] 64-bit SQLite3.exe

[David Empson]

> On 10/08/2016, at 3:30 PM, Rousselot, Richard A 
>  wrote:
> 
> As I said, I am not a software engineer.  I could spend a few hours figuring 
> this out and be fine but it will be painful for me.
> 
> I see no downsides in a 64-bit CLI.  The last 32-bit Intel CPU was the PIII 
> in 2004, no supported Windows OS requires 32-bit CPUs, the file size may be 
> marginally bigger but who cares on a PC.  The 64-bit version will, I assume, 
> happily work on DBs created in the 32-bit version.  And for those that need 
> 32-bit for their applications and drivers still have access to the 32-bit 
> DLL.  What am I missing?  Are windows command line tools 32-bit only?

A 32-bit installation of Windows cannot run 64-bit executables (ignoring VM 
solutions).

Because of the large installed base of 32-bit Windows, the Windows command line 
tools for SQLite needs to be available as 32-bit versions. If 64-bit versions 
were provided, they would need to be in addition to the 32-bit versions.

There are an awful lot of 32-bit installations of Windows. This includes a lot 
of 32-bit installations of Windows on 64-bit processors, which exist for many 
reasons including defaults offered by the manufacturer, lack of 64-bit drivers, 
corporate policy decisions, reduced memory footprint in limited machines, or 
the user requiring 32-bit Windows in order to be able to run legacy 16-bit 
software (again, ignoring VM solutions).

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

Re: [sqlite] 64-bit SQLite3.exe

[Warren Young]

On Aug 9, 2016, at 9:30 PM, Rousselot, Richard A 
 wrote:
> 
> I could spend a few hours figuring this out and be fine but it will be 
> painful for me.

Or you can spend many hours waiting for someone to build it for you.  How many 
hours are you willing to wait to save yourself some pain?  (And since when did 
learning something new cause pain?)

As to your problem with corporate IT, will they let you install Cygwin?  SQLite 
is well-supported in Cygwin, and there is a 64-bit version of Cygwin.  Due to 
the way Cygwin works, all packages available for 64-bit Cygwin are also 64-bit.

Cygwin SQLite should be nearly as fast as native SQLite.  There are some big 
speed hits in Cygwin, but for the things SQLite does, I can’t see that you’re 
going to run into any of the biggest ones.

> The last 32-bit Intel CPU was the PIII in 2004

That’s simply not true.  Many P4s were 32-bit, the Atom processors were 32-bit 
only until 2008, and I believe the Core Solo processors were also 32-bit only.

(That latter caused a lot of trouble for me when Apple went 64-bit only and cut 
off a bunch of the still-useful Macs I had still in use.)

> no supported Windows OS requires 32-bit CPUs

But equally, Microsoft retrenched from their threat to make Windows 10 the 
first 64-bit-only version of Windows.  Wonder why? :)

> The 64-bit version will, I assume, happily work on DBs created in the 32-bit 
> version.

Yes.

> What am I missing?

Someone has to do it.  Time is not free.

> Are windows command line tools 32-bit only?

The opposite, actually: the first 64-bit versions of the Visual C++ tool set 
were command-line only, as I recall.  I believe that was back in the 
pre-VC++2005 days.

> Why add powerful features like CTE if you can't access their power?

Because most of the SQLite binaries are shipped by third parties, not directly 
from sqlite.org.  The biggest sources are OSes (virtually all mobile phones, 
Mac OS X, Windows, etc.) and third-party applications (virtually all web 
browsers, many Adobe and Apple products, etc.)  These third parties built 
SQLite to meet their needs.

I’d bet the number of regularly run instances of binaries downloaded directly 
from sqlite.org is under 0.01% of the total usage of SQLite.

(That’s a considered guess, not a wild guess.  There are billions of SQLite 
instances in the world, and I’m betting there are less than 100,000 users of 
the SQLite.org binaries.  I wouldn’t be surprised if it’s under 0.001%.)

Of that tiny percentage, only a small fraction will actually need a 64-bit, and 
of that fraction of a fraction, only a small number will be unable to acquire 
or build a 64-bit binary.

Why spend a lot of effort on such a small user base?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

As I said, I am not a software engineer.  I could spend a few hours figuring 
this out and be fine but it will be painful for me.

I see no downsides in a 64-bit CLI.  The last 32-bit Intel CPU was the PIII in 
2004, no supported Windows OS requires 32-bit CPUs, the file size may be 
marginally bigger but who cares on a PC.  The 64-bit version will, I assume, 
happily work on DBs created in the 32-bit version.  And for those that need 
32-bit for their applications and drivers still have access to the 32-bit DLL.  
What am I missing?  Are windows command line tools 32-bit only?

Why add powerful features like CTE if you can't access their power?  Isn't this 
just a matter of making a few changes on some automated scripts that generate 
each releases files and done?

(Sorry if this double posts, I attempted to use Nabble and the message bounced)

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Donald Shepherd
Sent: Tuesday, August 09, 2016 9:28 PM
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] 64-bit SQLite3.exe

Why don't you build it yourself as a 64 bit executable?

On Wed, 10 Aug 2016 at 00:31 Rousselot, Richard A < 
richard.a.rousse...@centurylink.com> wrote:

> I would like to request a SQLite official 64-bit SQLite3.exe CLI (not
> DLL) be created.
>
> I have reviewed the prior discussions regarding 64-bit SQLite3 and the
> reasoning for which why creating a 64-bit version is denied are "it
> does not make a real difference", "you can just use ram disks", etc., etc.
>
> Here is my plea...  I am using a set of complicated CTEs to crawl
> through a network (tree) to aggregate and calculate formulas.  I don't
> have exceptionally large datasets but my CTEs result in a ton of memory usage.
> The process works well from disk, in Windows, but using a smaller test
> sample I get about a 30% to 40% increase in processing time if I set
> the PRAGMA to temp_store = 2.  If I use a normal dataset, not a small
> test, I hit an approximate 2G limit and get a "out of memory" message,
> which I understand is due to SQLite3.exe being 32-bit.  I have found
> some 3rd party 64-bit builds for SQLite3 (best found is 3.8.5) but
> they are out of date and don't allow all functionality that I am
> using.  So, I do have a use case that requires 64-bit and I would see a 
> significant increase in speed.
>
> As to RAM disks, I work in a corporate environment that locks down
> user rights which precludes me from distributing a tool that requires
> the creation of a tool that needs administrator rights.  I also, would
> like to avoid having to compile it myself; I am not a software engineer.
>
> Thanks for your consideration.
>
> Richard
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the
> sender by reply e-mail and destroy all copies of the communication and
> any attachments.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64-bit SQLite3.exe

[Donald Shepherd]

Why don't you build it yourself as a 64 bit executable?

On Wed, 10 Aug 2016 at 00:31 Rousselot, Richard A <
richard.a.rousse...@centurylink.com> wrote:

> I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL)
> be created.
>
> I have reviewed the prior discussions regarding 64-bit SQLite3 and the
> reasoning for which why creating a 64-bit version is denied are "it does
> not make a real difference", "you can just use ram disks", etc., etc.
>
> Here is my plea...  I am using a set of complicated CTEs to crawl through
> a network (tree) to aggregate and calculate formulas.  I don't have
> exceptionally large datasets but my CTEs result in a ton of memory usage.
> The process works well from disk, in Windows, but using a smaller test
> sample I get about a 30% to 40% increase in processing time if I set the
> PRAGMA to temp_store = 2.  If I use a normal dataset, not a small test, I
> hit an approximate 2G limit and get a "out of memory" message, which I
> understand is due to SQLite3.exe being 32-bit.  I have found some 3rd party
> 64-bit builds for SQLite3 (best found is 3.8.5) but they are out of date
> and don't allow all functionality that I am using.  So, I do have a use
> case that requires 64-bit and I would see a significant increase in speed.
>
> As to RAM disks, I work in a corporate environment that locks down user
> rights which precludes me from distributing a tool that requires the
> creation of a tool that needs administrator rights.  I also, would like to
> avoid having to compile it myself; I am not a software engineer.
>
> Thanks for your consideration.
>
> Richard
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 64-bit SQLite3.exe

[Rousselot, Richard A]

I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL) be 
created.

I have reviewed the prior discussions regarding 64-bit SQLite3 and the 
reasoning for which why creating a 64-bit version is denied are "it does not 
make a real difference", "you can just use ram disks", etc., etc.

Here is my plea...  I am using a set of complicated CTEs to crawl through a 
network (tree) to aggregate and calculate formulas.  I don't have exceptionally 
large datasets but my CTEs result in a ton of memory usage.  The process works 
well from disk, in Windows, but using a smaller test sample I get about a 30% 
to 40% increase in processing time if I set the PRAGMA to temp_store = 2.  If I 
use a normal dataset, not a small test, I hit an approximate 2G limit and get a 
"out of memory" message, which I understand is due to SQLite3.exe being 32-bit. 
 I have found some 3rd party 64-bit builds for SQLite3 (best found is 3.8.5) 
but they are out of date and don't allow all functionality that I am using.  
So, I do have a use case that requires 64-bit and I would see a significant 
increase in speed.

As to RAM disks, I work in a corporate environment that locks down user rights 
which precludes me from distributing a tool that requires the creation of a 
tool that needs administrator rights.  I also, would like to avoid having to 
compile it myself; I am not a software engineer.

Thanks for your consideration.

Richard
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users