64-bit SQLite3.exe

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

64-bit SQLite3.exe

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

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

Re: 64-bit SQLite3.exe

RichardR
This post has NOT been accepted by the mailing list yet.
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?  
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

RichardR
In reply to this post by Donald Shepherd
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:[hidden email]] On Behalf Of Donald Shepherd
Sent: Tuesday, August 09, 2016 9:28 PM
To: [hidden email]
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 < [hidden email]> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

Warren Young-2
On Aug 9, 2016, at 9:30 PM, Rousselot, Richard A <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

David Empson
In reply to this post by RichardR

> On 10/08/2016, at 3:30 PM, Rousselot, Richard A <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

RichardR
In reply to this post by Warren Young-2
>On Aug 9, 2016, at 9:30 PM, Rousselot, Richard A <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

RichardR
In reply to this post by David Empson
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:[hidden email]] 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

Warren Young-2
In reply to this post by RichardR
On Aug 9, 2016, at 11:39 PM, Rousselot, Richard A <[hidden email]> 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.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

Dominique Devienne
In reply to this post by RichardR
On Tue, Aug 9, 2016 at 4:31 PM, Rousselot, Richard A <
[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

J Decker
In reply to this post by David Empson
On Tue, Aug 9, 2016 at 10:08 PM, David Empson <[hidden email]> wrote:

>
> > On 10/08/2016, at 3:30 PM, Rousselot, Richard A <Richard.A.Rousselot@
> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

David Empson
In reply to this post by RichardR
> On 10/08/2016, at 5:50 PM, Rousselot, Richard A <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

R Smith
In reply to this post by RichardR

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.


</2c>
Ryan

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

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

Re: 64-bit SQLite3.exe

Dominique Devienne
In reply to this post by R Smith
On Wed, Aug 10, 2016 at 11:11 AM, R Smith <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

Warren Young-2
In reply to this post by J Decker
On Aug 10, 2016, at 3:22 AM, J Decker <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

R Smith
In reply to this post by Dominique Devienne


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

> On Wed, Aug 10, 2016 at 11:11 AM, R Smith <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit SQLite3.exe

Dominique Devienne
On Wed, Aug 10, 2016 at 11:52 AM, R Smith <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

Re: 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
123