🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.powerpc
Article #2328

Re: Ask yourself these before you choosing a 32bit OS...

#2328
From: Dmitry V. Irtegov
Date: Mon, 25 Sep 1995 07:57
106 lines
5588 bytes
In article <nevin-2309950443170001@mac-nevin.cs.arizona.edu> nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:
> In article <FAT.95Sep20151221@fat.cnit.nsk.su>, fat@cnit.nsk.su (Dmitry V.
> Irtegov) wrote:

>> If you lock handles before each use and unlock them after,
>> your code inflates 2-3 times,

> Unless all your code is doing is a system call just about every line (and
> I can't think of any useful non-trival program that does this), the
> additional code is nowhere near that inflated.  A couple of percent at
> most.

My code does socket library calls each three-four lines.

>> and if you don't you have werid
>> bugs when you pass pointer outside of lock/unlock region.

> Why aren't you passing the handle?  Micro-optimized code usually ends up
> buggier than well thought out code.  Don't do microoptimizations until you
> know there is a bottleneck.

With linear address space you don't need those microoptimisations at
all. In some cases I would need macrooptimisations to fix memory allocation
strategy (use alloca instead of malloc whenever possible, etc), but
I never have to do microoptimisations of this kind.

>> Been there, done that.

>That says more about your skill as a programmer than it does about the
>Mac's memory scheme.

Well, most my programming experience come from systems with linear memory.
I consider myself skilled in program and algorithm design, not in
specific kind of microoptimisation. Handles distract me from high-level
stuff and force me to emulate missing piece of hardware.

>> Handle memory management is crap 
>> and nobody can convince me otherwise.

>That says more about you being a close-minded person than it does about
>the Mac's memory scheme.

Well, my statement as it written says more about my opinion than about
objective properties of Mac. In this sence you are right.

I thought about handles more kindly untill I was forced to use them.

>> Basically, handles is a patetic attempt to emulate hardware MMU in software.

> Not true.  The problem doesn't go away with VM; it merely gets delayed. 

From practical standpoint it goes away. VM separates data spaces of 
different programs, so each program has to deal only with _own_ 
fragmentation, not with system-wide one. It decreases fragmentation
by several orders of magnitude. And for most programs
fragmentation doesn't become an issue while copy of program is running.
Many programs which allocate all memory they need on startup do
not have fragmentation problem at all. 

As I admitted in previous letter, some daemons that run for several
months might have heap fragmentation problem, but for most programs it isn't
an issue.

> One could argue that if you can delay it enough, it isn't worth the
> additional complexity to deal with it, but that certainly wasn't true in
> the 80s, when RAM and disk space were damn expensive.

Well, why it wasn't fixed since then?

>> Virtual address is basically a handle, but MMU hardware does equivalent
>> of locking and unlocking for you, which is order of magnitude faster and 
>> easier.

>You mean (possibly) writing a page to disk and reading a different page
>from disk?  These are fairly slow operations.

No, I mean checking presence bit in page descriptor. It is being done
on each access to the page. When this bit isn't set, page fault happens.
It doesn't always lead to disk access.

>> Win16 and Mac programmers are forced to fight with handles,
>> when in any decent environment (including win32 here) programmers
>> just rely on hardware doing all handle-related stuff for them.

> But the customers, not the programmers, get to choose (with their
> pocketbooks) what environment they are willing to run the software on. 

It is very complex question who choose the software and hardware.
Software and hardware vendors use different methods to manipulate
the consumer and to drag out contents of their pocketbooks :).
Mass-market is driven by marketing and advertisement, not by technology
nor by actual needs of consumer.

> Personally, if everybody had 4G of RAM and a couple of terabytes of disk
> space, as a programmer my job would be a heck of a lot easier.  Should I
> send you my address so you can give me this hardware?

Well, I have 8Mb RAM and 210Mb HDD on both my computers at work and at home.
OS/2 demand-paged VM works very well on both, thank you. I used to run home
system with only 4Mb, but was forced to upgrade in order to run Heretic
(it suxx in 4Mb). Linux without GUI runs quite nicely in 4Mb too.

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.
Technical Details
Message-ID: <FAT.95Sep25135716@fat.cnit.nsk.su>
Path: arc1-ca.pugleaf.net!mx.nsu.nsk.su!fat
References: <3vh2hc$9dd@falcon.ccs.uwo.ca> <43auuk$41@starfruit.csd.sgi.com> <43d484INNlge@keats.ugrad.cs.ubc.ca> <nevin-1709951616450001@mac-nevin.cs.arizona.edu> <43kai7INNjvp@anvil.ugrad.cs.ubc.ca> <wade-1809952212460001@f182-067.net.wisc.edu> <FAT.95Sep20151221@fat.cnit.nsk.su> <nevin-2309950443170001@mac-nevin.cs.arizona.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!mx.nsu.nsk.su!fat
From: fat@cnit.nsk.su (Dmitry V. Irtegov)
Newsgroups: comp.sys.powerpc,comp.os.linux.advocacy,comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.sys.amiga.advocacy,comp.sys.intel,comp.os.ms-windows.advocacy
Subject: Re: Ask yourself these before you choosing a 32bit OS...
Date: 25 Sep 1995 07:57:15 GMT
Organization: Novosibirsk State University
Distribution: world
Message-ID: <FAT.95Sep25135716@fat.cnit.nsk.su>
References: <3vh2hc$9dd@falcon.ccs.uwo.ca> <43auuk$41@starfruit.csd.sgi.com>
 <43d484INNlge@keats.ugrad.cs.ubc.ca>
 <nevin-1709951616450001@mac-nevin.cs.arizona.edu>
 <43kai7INNjvp@anvil.ugrad.cs.ubc.ca>
 <wade-1809952212460001@f182-067.net.wisc.edu>
 <FAT.95Sep20151221@fat.cnit.nsk.su>
 <nevin-2309950443170001@mac-nevin.cs.arizona.edu>
NNTP-Posting-Host: fat.cnit.nsk.su
In-reply-to: nevin@CS.Arizona.EDU's message of Sat, 23 Sep 1995 04:43:17 -0700