On Thu, 11 Mar 2021 at 00:32, dmccunney <dennis.mccun...@gmail.com> wrote: > > On Wed, Mar 10, 2021 at 5:07 PM Jon Brase <jon.br...@gmail.com> wrote: > > On 3/9/21 4:35 PM, dmccunney wrote: > > > As a general rule, consumer machines are I/O bound, not compute bound. > > > The CPU spends most of its time in an idle loop waiting for stuff to > > > be read from/written to disk. > > > > Actually, as a general rule, on a consumer machine, both the CPU and the > > disk spend most of their time waiting for user input to give them > > something to do. Disk waits are nothing compared to the eternity between > > the keystrokes of a fast typist, and that's if the user is neither away > > nor lost in thought. > > I can't agree. We are not in the single-user, single tasking DOS days > when one thing was going on at a time.
Agreed. Way back in the mid-1990s I ran the testing labs for one of the UK's largest computer magazines, PC Pro. (Known as "PC @uthority" in Australia.) I organized a labs test of PCs with Win NT 4. This really showed which manufacturers knew their stuff. In the Pentium 1 era, Intel really advanced the art of motherboard chipsets. Its old 82430 "Neptune" chipset for the 5V Pentium (60MHz & 66MHz) was very conventional. The 82430 FX "Triton" chipset for the 3.3V Pentium (75/90/100/120/133MHz) was a revelation. Its EIDE controller, the PIIX chip, could do busmastering I/O, allowing the disk drives to use DMA to put data into RAM. A device driver was supplied on floppy. On Win9x this made little difference because its limited kernel could not overlap I/O. But on NT, even with 1 CPU, it was very different. Without the busmastering driver, each disk access used programmed I/O. NT booted as slowly as 9x. With the driver, when NT booted, you could *hear* when the kernel started executing. Disk access went from tick-tick-tick, tick-tick, tick-tick-tick-tick, to bzzzzzt-bzzzt-bzzzzzzzzzzzzzzt-bzzzzzt. Once the driver triggered, not only did disk access get quicker, but the CPU could get on with something else while it occurred. So your PC booted noticeably faster -- it took minutes off a long boot sequence -- and you could continue to use the PC even under very heavy disk load. It's not just a question of the CPU sitting waiting any more, although that's true, it does. But with a modern OS with a pre-emptive kernel, it can queue up a bunch of I/O commands and then leave that particular I/O subsystem to its own devices (literally!) and go off and do something else while the subsystem does the work and puts the data direct into RAM without CPU intervention. Now that multicore CPUs are standard this is even more important. One core can be doing a virus scan while another core is doing a spellcheck and another core is servicing the UI so your PC still responds to you. To measure it, for example, one can set a program transcoding a video file, which running standalone would take say 10min, and then run a script that puts Photoshop through its paces for about 10min. On a system without DMA I/O, with both tasks running, they will take on the order of twice as long. With DMA I/O, a background task will only slow the foreground task by a few %. For me, as someone who used to do benchmarking for a living, this was one of the biggest advances I ever saw in personal computing since the 1980s, and it went almost totally unnoticed in the industry as a whole -- sadly a lot of folk writing about computing in the 21st century lack training, scientific literacy, and a basic understanding of statistics and ideas like a significant or insignificant difference. I've seen websites making buying recommendations based on measuring external sources' bar charts with a ruler, when they did not notice that the Y axis did not begin at zero. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
