🚀 go-pugleaf

In article <1992Nov20.065829.28459@dtint.uucp> nevin@dtint.dtint.com writes:
> In article <BxzEsF.60C.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes:
> > In article <1992Nov19.000858.26075@dtint.uucp> nevin@dtint.dtint.com  
writes:
> > >> 3.0 which might tend to reverse NeXT's original position (most of the  
3.0
> > >> slow-down is related to nib/disk/memory stuff).
> > >
> > > I've heard a slightly different story about the 3.0 slowdown, from an
> > > ex-NeXT employee.  It was caused (according to him) by a
> > > generalization of things like "malloc(512)" to
> > > "malloc(sizeof(somesuch) * 4)" in order to better support new
> > > platforms (ala 486).
> > 
> > That sort of construct is evaluated at compile-time, not at
> > execute-time.  So it would explain a slow-down in compiles, but not in
> > general performance.
> > -- 
> > Doug DeJulio
> > ddj+@cmu.edu
> 
> You're right about that particular construct.  But never-the-less, one of the  
> obvious features of "malloc()" is the ability to compute desired block size  
via  
> an arithmetic expression at run-time.  And, it's quite reasonable to choose  
an  
> appropriate arithmetic expression such that the arithmetic expression's  
syntax  
> is constant, and yet it's value changes at run-time depending on the  
hardware,  
> due to architectural differences.  I just threw out a lousy example--from the  
> hip.
> 
> I realize that many such problems could probably be handled via compile-time  
> switches and #defines, but I believe it is reasonable to conclude that some  
> would fall into the aforementioned category and be computed at run-time.   
> Hence, I believe what I was told by the ex-NeXT employee.
> 
> --
> Nevin Pratt, Digital Technology, Int'l    Orem, Ut
> NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com

Besides, we don't need to get bogged down in "malloc()" details.  There are  
plenty of other ways that slow-downs due to code generalizations to accommodate  
architectural differences can occur.  I shot from the hip with the "malloc()"  
thing in an attempt to illustrate at least one.

--
Nevin Pratt, Digital Technology, Int'l    Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com

-- 
---
root	                               root@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438