CSvax:Pucc-H:ags@pur-ee.UUCP (09/20/83)
Re: "UCSD P-system is too slow for many applications" A system with a resident assembler is never too slow, unless the host machine itself is too slow. In a typical program, 90 per cent of the execution time is spent in 10 per cent of the code, so that a significant speedup is possible by recoding only a few critical routines in assembly language. Dave Seaman pur-ee:pucc-H:ags
dgary@ecsvax.UUCP (09/22/83)
Original remark was the UCSD p-system is too slow for some applications. Dave Seaman's response was that anything with an assembler can be made fast enough by recoding critical routines. I'll take exception on two grounds: First, a monster OS can slow things up even on a fairly fast machine. Good case in point is VM on a 4331, which I believe ties up half the processor cycles running the operating system! Also, diskette format can have a major effect on I/O response time (try running a sort on a fragmented diskette file in CP/M or MS-DOS; assembler won't help there!). But I have a more important objection. For many users, the time spent locating critical routines, isolating them, and recoding them in assembler is prohibitive. It just moves "slow" to a different place. I think Bowles is a brilliant chap and the UCSD system is very clever and powerful for some tasks. Unfortunately, it's not suited to everything, and it's often too damned slow!
b-davis@utah-cs.UUCP (Brad Davis) (09/24/83)
One of the ways in which UCSD is too slow is its IO handling. If blank compression codes (DLE's) were removed from the system, input from a text would be about 2 times faster. The editor could read and write files much faster if page boundries were removed also. Brad Davis