On May 6, 2008, at 3:35 PM, der Mouse wrote: >>> Which is likely true in my case. I've done the rendering portion of >>> the HID first, and it takes it nearly a minute to render tut1.pcb. >>> It's likely I can speed that up some, but only some; I don't expect >>> to ever get it below, say, five seconds, on this hardware. >> Good heavens, what do you have in that SS20, a single SM30? > > cpu0 at mainbus0: RT620/625 @ 125 MHz, on-chip FPU > cpu0: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
Ahh, a Ross HyperSPARC. Not a bad module, but it's got a teensy tiny cache. > I don't know what that is in SMxx terms. There's no real correlation...The higher clock speed will offset the tiny cache for some applications, but not others. > There's a delay of at least a few seconds before it even _starts_ > drawing; PCB must be doing _something_ piggish, but I don't yet have > any idea what. It's clearly not _just_ the drawing that's taking all > that time. > > It strikes me as slow too. I don't know why it is so slow; I need to > find out, but "first make it work, then make it better". I've got > lots > of speculation, but so far it's only speculation. There are at least > four processes involved, for example; I speculate that it's context > switching too much, but until I measure I won't know whether it's > worth > putting any effort into cutting down on context switches. Perhaps some profiling is in order. -Dave -- Dave McGuire Port Charlotte, FL _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user