Bill Arnold wrote: > Leland, > > I can't speak knowledgably about gaming because I have no experience in > that area, but these loosely related thoughts came to mind, so ... > > When I heard of the $10/gb RAM purchase last week, I thought "that's > just amazing", and given the history of hardware trajectories, we may > well see that price drop even lower. Yes, this is definitely good to see computer memory so cheep. There is a down side to this I fear, though. The 32 bit software and Os(s) would only address 4G memory max, because that is the biggest integer possible in a 32 bit binary system. The 64 bit processor can address exponentially greater amounts of memory, because the number set in a binary system that uses 64 bits integer will go up to 18,446,744,073,709,551,615, (eg the top register of memory).
If history holds true developers, companies that provide OS(s), and software applications will find some way to use every bit of that memory. Once applications and OS are ported to 64 bit languages, the system requirements to run everyday software is likely to require significant greater amounts of memory than is used today, causing further disruption and turnover of software and the computers required to run the software. > > > Another thought is that this really paves the way for VM as a staple for > anyone with any use at all for it, including VFP applications if/when MS > ever does make a move to break it, all other options aside. This is > particularly exciting because, in effect, it gives VFP applications > "immortality". All we need to do is install a compatible OS along with > our application. If MS should break VFP at some point, and we're left > with the choice of going out of business or installing an older version > of Windows under VM to stay alive ... [to be continued] > This is dependent upon the hardware manufacturer providing memory, CPUs, and other hardware that maintains compatibility with applications that are 16 bit, or like VFP, that are 32 bit. At some point the industry may break with this backwards compatibility, and once a clients buys into new incompatible hardware, it may require that they purchase new specialized computers designed specifically to run in 32 bit emulation, along with the VM and application. This could be a very hard sell. A better solution would to be to get VFP into the hands of a new vendor that would port her to a standardized 64 bit instruction set, and otherwise bring VFP up to date, like making her better suited to run over the internet and increase the maximum table size. > I'll also make the general comment that these advances are monumentally > valuable to software makers, no matter the language, because with > hardware reduced to commodity status and thus making possible more > widespread use of computers, the number of prospective customers rises > at the same time that the action shifts from hardware to software. OK > > > And on that note, it's the software that we've been given time to > develop right that will be ahead of the competition. It's very hard to > invest the time to get it right when we're stuck in the re-write loop. > Isn't it far better to spend time polishing and adding features then > re-writing? > Things could be worse, You could have jumped to VS and invested tons of time and energy porting VFP to net, just to have Microsoft bring in or change things enough that you would need to begin porting VS app because of Microsoft historic churn. LOL > --- > > On OS bloat, OS makers have a powerful need to be organized, > consequently they'll manage bloat of their own volition. Bloat due to > the baggage of backwards compatibility is, well, worth the relatively > small price. > With 8 bit, 16 bit, and 32 bit software, memory was limited requiring the OS manage it very carefully. The day may be coming when programmers would have virtually unlimited amounts of memory in which to work, so I'll let your imagination fill in the blank on the possibilities and changes that might occur in the way applications are structured and how they might use the additional memory. > Worth mention, when an OS or an application 'goes to sleep', it's pages > are subject to the paging subsystem to free up physical memory if > needed. This kind of physical I/O is not the same as reading a disk > device to bring in a program or data because everything about paging is > highly optimized. OK Regards, LelandJ > > > > Bill > > > >> Gamers are a special breed, and to them the holy grail is the fastest >> computer. Gamers don't mind spending big bucks for even >> small increases in spread, even though it makes each additional small >> > increment in > >> speed/power more and more expensive. >> >> I think VMware will degrade performance on the guest OS about >> 10%, and many of the newer VM(s), such as Redhat's Zen claim to be >> > much faster > >> than VMware. >> >> Having a monstrous amount of memory on a desktop computer, even one >> running many VM(s) really isn't necessary. The VM(s) not >> being used can be put to sleep, so they are not using lots of memory. >> > For a desktop > >> computer, I think 8G or 16G would be fine, and I think it would a big >> mistake for Microsoft to up the memory requirements for it Vista and >> future OS(s). At least for me, as the OS requirement for >> more and more memory increases, the OS's attractiveness to me >> > decreases and > >> decreases. >> > > >> Someone mentioned a motherboard that supported 64G of memory >> LOL, which seem a little much for a desktop computer. Heck, Ive run >> complete OS(s) including all the applications and data on a lot less >> > space > >> than that, so unless Microsoft or someone else decide to hold the >> > entire OS in a > >> RAM disk or in a solid state HD, I don't see the advantage to lots of >> memory, especially given that huge amounts of data can be >> accessed in a database like PostgreSQL, MySQL, MSSQL, DB2, etc almost >> instantaneously. Manipulating data can also be handled >> plenty fast on a HD, like a bubble sort, etc, so huge amount of memory >> > isn't > >> needed for that. The same goes for arrays, which can be put into a >> > database for > >> manipulation, etc. Also, todays hardware is very capable of >> managing memory and grabbing files as needed and then doing garbage >> collection to clean-up and free memory as needed. However, if I were >> running servers like alike VMware's enterprise, PostgreSQL, and busy >> > web server, then > >> lots of system memory makes sense. >> >> For gamers the action all takes place on the video card, (eg GUP), so >> they just add additional video cards to increase processing power and >> memory. Still, even gamers don't need huge amounts of memory as the >> graphics are switch out from the HD. >> >> Regards, >> >> LelandJ >> > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
