> On Aug 10, 2016, at 6:03 AM, Keith Medcalf <kmedc...@dessus.com> 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 solution today. What does the size of the data bus and registers have to do with the amount of addressable memory, either physical or virtual? There are two-bit (bit slice) processors on the market for the past 30 years which have exceptionally huge addressable storage (far beyond 4 GB). > > 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
