home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.beos      Underrated early 90's OS, sad it died...      1,512 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 1,004 of 1,512   
   LawsonE to Randy Howard   
   Re: OsX compared to Linux and BeOS   
   27 Apr 05 22:43:20   
   
   XPost: comp.sys.mac.advocacy, alt.os.linux.mandrake, comp.os.linux.advocacy   
   XPost: alt.os.linux.redhat   
   From: nospam@nospam.com   
      
   "Randy Howard"  wrote in message   
   news:MPG.1cda3141379fe12b98a51c@news.verizon.net...   
   > In article , nospam@nospam.com says...   
   >>   
   >> "Randy Howard"  wrote in message   
   >> news:MPG.1cd9ea13f6a960d198a4fa@news.verizon.net...   
   >> > In article ,   
   >> > Nowhere@spamfree.com says...   
   >> >> In article ,   
   >> >>  Randy Howard  wrote:   
   >> >> > True, but I doubt that the majority of people with G5 dual towers   
   >> >> > are   
   >> >> > running high load averages currently.   
   >> >>   
   >> >> Why would the average matter? What matters in determining if a faster   
   >> >> system will help is the peak.   
   >> >   
   >> > Anybody can spike the load average to 100% in a burst, keeping it   
   >> > there under normal use is a different matter entirely.  You know   
   >> > that, but just like to argue.  Entertain yourself.   
   >>   
   >> For anyone using a 3D animation package, the rendering can take hours,   
   >> just   
   >> for a few seconds of animation. Even a hobbyist can casually create stuff   
   >> that takes hours to render.   
   >   
   > If it's multi-threaded and compute bound, then they probably love   
   > every CPU bump they can get.   
      
   The benchmark we ran a few days ago is a turnkey version of a professional   
   3D graphics app. They're all multi-thread, and ALL compute bound when doing   
   rendering, believe me.   
      
   One issue I have with that benchmark is that it does realtime updating by   
   scanline on the multi-processor benchmark. That's generally EXTREMELY   
   inefficient and benches the pixel-plotting speed more than it does the CPU   
   speed, often by a major ratio, like 5:1 or even more. Better to render the   
   entire thing offscreen (or at least in big blocks) and then blit it   
   onscreen, then to plot one-pixel-at-a-time...   
      
   Of course, that may have been intentional, come to think of it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca