On Aug 9, 2016, at 11:39 PM, Rousselot, Richard A <richard.a.rousse...@centurylink.com> 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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
