[Ham-Computers] RE: windows stuff
Hsu, Aaron (NBC Universal)
aaron.hsu at nbcuni.com
Tue Aug 30 19:51:28 EDT 2005
A basic problem is that the faster computers get, the less likely program
code will be "optimized". Back when CPU's were "slow", RAM was expensive,
and HD's were non-existant, much time and care was taken to squeeze every
last bit (pun intended) out of CPU cycles and RAM. Program sub-routines
were coded to minimize clock cycles and "hash tables" were written to
minimize code size. However, as RAM and CPU speed became plentiful and
cheap, efforts were shifted to maximize "function and features". As such,
most programs you find these days are bloated with features 90% of users
never touch.
Back in my Commodore-64 days, one of my favorite games was "Elite" by
Firebird Systems. This was one of the first graphics oriented space trading
games. There were 8 "galaxies" to explore each with 250 "worlds". Each
world had a different eco-structure and price list of goods to buy/sell.
This game loaded completely from a floppy and never accessed the floppy
again after starting the game. For those of you not familiar with the C64,
it had 64K of RAM of which 52K was available if you wrote your own I/O
routines, and only 38K available if you used the built-in routines. That's
K as in Kilo bytes, not Mega. It accomplished this by careful app coding in
assembly/machine language, use of "Hash" tables, optimizing so that if you
"ofset" by one byte, you had a completely different line of valid code.
When "Elite" was ported to the PC (DOS based), it *required* 320K available
RAM. 640K was standard on a PC by then, so the company that ported "Elite"
simplified the development by not using the optimizations found in the C64
version. Rarely do you find apps coded in assembly these days even though
these would result in the fastest and physically smallest programs.
Operating systems like Windows would benefit greatly by being coded in 100%
assembly/machine language, but the amount of time required to code in
assembly would be detrimental. It's not easy to debug assembly/machine
code, but it makes for very efficient programs!
Another problem is customer demand for "new" or updated products. This
pushes software developers to spend more time getting a new program out
rather than optimizing code (or even fixing bugs!). This customer demand
for the latest and greatest is part of the reason so many bug-ridden apps
are release pre-maturely these days. Besides, who needs optimized code
these days on systems with a 1THz CPU and a Gigabazillion bytes of RAM?
Just get the app out so we can one-up the competition...we'll worry about
the bugs later.
It's hard to benchmark the various versions of Windows as each successive
version included additional features. Many of these features, weather or
not you used them, are part of the OS and will impact any benchmark you run.
Of course, since the newer version requires more CPU speed and RAM, notice
that the newer OS is actually *slower* as it requires you to run it on a
*faster* CPU to get the relatively same performance. Many have never tried
to install an older version of Windows on their newer hardware as they
figure, "Why would I do that??? New hardware with old OS??? That's
insane!". But, if you do try it, you'll notice that the older OS does
indeed run faster on the faster CPU...but that should be expected! Only
when you install both on the same exact hardware will you notice that the
newer OS seems slower than the older OS.
A few years ago (after XP came out), I found my old Windows 3.11 disks and
decided to install it on an 866MHz Pentium III system. After copying the
contents of all seven floppies to a consolidated folder on the HD, it took
about 5 minutes to install (I remember spending 45 minutes installing Win
3.11 on a 386sx-16 many years earlier). It took less than 10 seconds to
boot and everything was running in lightning mode! I was actually pretty
surprised at two things...1) that it actually installed properly, and 2) how
blazing fast it was. It wasn't pretty without "native" video drivers, but
it did work at 640x480x4 (16 color).
So why does WinXP (and upcomming "Vista") seem to run just as fast (or as
slow) today as Windows 3.11 did back in the day??? Because they're super
bloated with features and a pretty interface. Operationally (for most
people), they're still pretty much the same, but XP is definitely more
"capable" (aka has more functionality) than Win3.11. Of all the Windows
versions out there, Win98 (SE) Second Edition is my preferred choice for
typical use. Unfortunately, support for 98SE is fading fast, so XP Pro
would be my next choice. For a managed work environment, it's really hard
to beat Win2K Pro followed by WinXP Pro. I avoid WinME as much as Microsoft
does.
And, as always, I've rambled. Frank, I hope there's some insightful info to
your questions here.
73 all!
- Aaron, NN6O
-----Original Message-----
Sent: Tuesday, August 30, 2005 12:47 PM
Subject: [Ham-Computers] windows stuff
*** mid-section snip ***
Anyway, I was wondering what the experiences of
the group were regarding windows stuff. Various
versions versus speed, versus capability.
Regards,
Frank Kamp
K5DKZ
_______________________________________________
More information about the Ham-Computers
mailing list