🚀 go-pugleaf

In article <nevin-2509951527160001@mac-nevin.cs.arizona.edu> nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:
>In article <FAT.95Sep25135716@fat.cnit.nsk.su>, fat@cnit.nsk.su (Dmitry V.
>Irtegov) wrote:

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

>Is every single line of your code a socket call?

Each third-fourth line of my "linear address" code is socket call.
It looks like this: 

send message;
handle error condition;
get answer;
handle error condition;
handle answer;

send next message;
      etc

Basically, it is unrolled state automata.

>> With linear address space you don't need those microoptimisations at
>> all.

>It has nothing to do with linear address spaces (hint, the 68000 has one),
>and everything to do with heap fragmentation.

Well, I did my program on Win16, which uses handles too. I hope you
wouldn't claim Win16 uses linear address space :).

>> 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.

>Well, the rest of us haven't had the luxury of assuming a large backing
>store on every machine out there.  That is changing, with disk space
>costing $.25 a meg.

By missing piece of hardware I meant not extra RAM/HDD, but MMU.
VM allows me to have large _virtual_ backing store without having large
physical one. Also, I wrote many programs for PDP-11 (58K physical RAM,
64K address space) and DOS small model (64K code, 64K data), and I never
have met problems with fragmentation. BTW, smallest VM system I seen was 
RSX-11, which can run on 32K (thirty-two kilobytes) systems. When 
applications use separate address spaces, heap fragmentation for 
_each_ application is usually (in 99.9999% cases) nonexistant. 
Fragmentation on OS level in multitasking environment is significant, 
but VM fights this _very_ efficently.

It looks like Mac programmers are _taught_ to be afraid of heap fragmentation.
Beleive me, in most situation it isn't an issue for single app.
For _some_ apps it is an issue, so they are forced to use some complex
allocation schemes; but in VM system nothing forces me into using that
complex scheme in _all_ applications.

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

>If you get to assume that everyone who runs your application has tons of
>RAM, just lock all the handles and don't worry about it.

Well, my Win16 application is "user exit" in Oracle Forms for Windows.
This masthodont likes RAM very much, so I cannot interfere with
it's RAM defragmentation. If I had decent VM system (even Win32),
this wouldn't be an issue.

>> 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.

>This is no different on a Mac; each app gets its own heap under MultiFinder.

It's own _heap_ or it's own address space? Anyway, why cannot I lock all 
my handles and use plain pointers under MultiFinder? I would tolerate
the sticker "MultiFinder required" on the box :).

>> It decreases fragmentation
>> by several orders of magnitude.

>Well, fragmentation actually increases; it's just that there is so much
>(virtual) memory available, that the likelyhood of not finding a large
>enough free block greatly decreases.

When program deals only with own continuous heap, fragmentation _decreases_,
because fragmentation is function of number of malloc/free operations.
Each app does less mallocs/frees on its own heap than all apps
running on the system together. How separating of heaps can increase
fragmentation?

>> 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. 

>Of course, those aren't programs that put things like windows up on
>screens.  Only the most simplistic stuff doesn't have a need to use a
>heap.

Well, most unix filters basically do not need the heap at all :).
I wouldn't call sed or grep a simplistic program ;), though their
code size is fairly small.

>> but for most programs it isn't
>> an issue.

>Well, there are plenty of programs for the Mac that can prove you wrong.

There are plenty of programs for other platforms that can prove me rigth.

EMTeX is program written in C. AFAIK, it uses standard allocation scheme
(I haven't checked the source, though). When TeX typesets the page,
it stores all paragraphs, pictures, etc in it's internal pool;
then it places all objects on their own places, outputs the page
to DVI file and cleans it's data area. Though, many internal variables
are passed from this page to next one, so, in theory, it must lead to 
fragmentation. I never have seen TeX chewing more memory on longer 
documents, up to many hundreds of pages in size.

>> > 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?

>It's getting there.  People have this funny notion that they want their
>old programs to keep running.

What the hell is problem with old programs? If new system uses virtual
memory, it shouldn't be a problem to make one-to-one mapping between
handles and virtual addresses, so GlobalAlloc will actually allocate
a virtual address and return a handle referring to that address.

New applications would use address directly, old ones would lock/unlock
corresponding handle and get same address on each lock. Point me to the 
problem with this approach, except babbling about "fragmentation"? 

I see one inconvenience: there should appear two forms of each API call: 
one that accepts a handle and other that accepts a pointer. "Handle" form 
would be implemented as stub that does lock and passes resulting pointer 
to "pointer" form.

If there is a problem, either the very idea of handle memory management
is braindead, or something else was broken by design in original Mac OS.

>> > 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.

>Yup.  Tons of variables to consider.

May be my English isn't good :(. I wanted to say that _not_ consumers
choose what to run. Retailers, marketing departments, etc, have much
more influence on platform choice than end user. At least, this is a 
case in modern PC market and this is very sad.

>> Mass-market is driven by marketing and advertisement, not by technology
>> nor by actual needs of consumer.

>Not true.  It is driven by both.  More specifically, it is driven by what
>the consumer *perceives* that he needs, and that is influenced by
>marketing, among other things.

I'd rather said "what consumer was lead to beleive..." :(.
When people act as mob, they are easy manipulable; history of Soviet Union,
nazist Germany, People Respublic of China and mass market economy confirms 
this. 

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.