Dennis_Grant@cmr001.bitnet (02/24/91)
I needed a first program for my new copy of NorthC, and I happened to
have an old BYTE magazine lying around, the issue where they introduced
their new benchmark suite. Inside was the source code for the sieve
program (the one that finds prime numbers). I typed it in, less the 2 lines
that dealt with getting system time values (I'd save those for later) and
ran the program.
For those who may not be familliar with the program, it finds all the
prime numbers up to 16000 or so, 100 times over. In the version in the
magazine, it printed out each prime as it was found, so you wound up with a
LONG list of about 1600000 numbers. On a PC-XT, it (supposedly) took about
250 seconds.
So anyway, off it goes, printing numbers. 5 minutes go by, and I start
to get suspicious. So I rebooted the machine, checked my code vs the code
in the magazine (it was right), and added a printf to print out what loop
it was on. I ran this one, and went to bed. (It was 03:00)
I got up at 10:30, turned on the monitor, and lo! It hadn't finished.
I waited for the numbers to wrap over so I could see how far it got, and
I found it was on loop 57. The machine got the 3 finger salute.
I edited the source code, got rid of the printf("%d\n",prime);
statement inside the main loop, and reran it. Bingo! One loop each second.
(More or less) for a final score of about 100 or so. As expected.
My conclusion: The printf was taking a LOT of time to execute.
My question: Is this normal? Could a lowly XT really crank out 1600000
printfs faster than my Amiga, or is this a quirk of NorthC? (or did BYTE
delete those printfs too?) Any ideas?
-------------------------------------------------------------------------------
Dennis Grant 3rd year CS student at Le College Militaire Royal de St-Jean
DETUD595@CMR001.BITNET
How much do I love thee? My accumulator overflows!ccplumb@rose.uwaterloo.ca (Colin Plumb) (02/24/91)
Dennis_Grant@cmr001.bitnet wrote: > My conclusion: The printf was taking a LOT of time to execute. > > My question: Is this normal? Could a lowly XT really crank out 1600000 >printfs faster than my Amiga, or is this a quirk of NorthC? (or did BYTE >delete those printfs too?) Any ideas? Sorry, but the answer is yes. An IBM XT has a text screen... it generates characters in hardware from a character and an attribute byte. The Amiga finds the character in the font, clips, blits, etc. It can be done very fast in PC-XT like cases (one bitplane, writing directly to screen, monospaced font -> no clipping), where you remove the extra checks from the code, but if you're printing to a console window on a 2-bitplane workbench screen, you're doing a lot more work. Then, if your printf isn't that smart (remember, it scans the string for % signs; puts() is faster), and uses putchar() for each character, and putchar() isn't buffered, then you call the dos.library once per character, which sends a packet to the console.device, which is not a shining example of tense code, which calls the graphics.library, which checks layers, then digs through the font, then queues the blit and returns from the mess... it can become a real pig. -- -Colin
clcp16@vaxa.strath.ac.uk ((Stewart C. Russell)) (02/27/91)
In article <1991Feb24.041825.428@watdragon.waterloo.edu>, ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: > Dennis_Grant@cmr001.bitnet wrote: >> My conclusion: The printf was taking a LOT of time to execute. >> >> My question: Is this normal? Could a lowly XT really crank out 1600000 >>printfs faster than my Amiga, or is this a quirk of NorthC? (or did BYTE >>delete those printfs too?) Any ideas? > > Sorry, but the answer is yes. An IBM XT has a text screen... it generates > characters in hardware from a character and an attribute byte. The Amiga > finds the character in the font, clips, blits, etc. It can be done very fast > in PC-XT like cases (one bitplane, writing directly to screen, monospaced > font -> no clipping), where you remove the extra checks from the code, > but if you're printing to a console window on a 2-bitplane workbench screen, > you're doing a lot more work. > > Then, if your printf isn't that smart (remember, it scans the string > for % signs; puts() is faster), and uses putchar() for each character, > and putchar() isn't buffered, then you call the dos.library once per > character, which sends a packet to the console.device, which is not a > shining example of tense code, which calls the graphics.library, which > checks layers, then digs through the font, then queues the blit and > returns from the mess... it can become a real pig. ...coupled with the fact that NorthC's printf looks like it's coming straight down the line at 300 baud. A reasonable compiler, but the console IO is unacceptably slow. No problems with any other compiler (even ZC, which is also based on Sozobon C). Stewart C. Russell University of Strathclyde, Glasgow, Scotland Also at CIX: scruss (scruss@cix.compulink.co.uk)
GKZ117@uriacc.uri.edu (F. Michael Theilig) (02/28/91)
On 27 Feb 91 10:30:25 GMT (Stewart C. Russell said: >In article <1991Feb24.041825.428@watdragon.waterloo.edu>, [Munch, munch ...] > > ...coupled with the fact that NorthC's printf looks like it's coming >straight down the line at 300 baud. A reasonable compiler, but the console >IO is unacceptably slow. No problems with any other compiler (even ZC, which >is also based on Sozobon C). > I believe the newest version of NorthC has much better screen output. I'm not really sure. I'd have to try it out again. Actually, I think that the screen output speed is more of a factor of the libraries being linked in. As ZC, DICE, and PDC all use amiga.lib, it's my guess that there isn't going to be much of a difference between them. SAS also. NorthC uses it's own replacement for amiga.lib and the consequence is speed. Please correct me if I'm wrong. > > Stewart C. Russell University of Strathclyde, Glasgow, Scotland > Also at CIX: scruss > (scruss@cix.compulink.co.uk) -------- F. Michael Theilig - The University of Rhode Island at Little Rest GKZ117 at URIACC.Bitnet GKZ117 at URIACC.URI.edu Though you'd like to know.
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/02/91)
In article <46088@nigel.ee.udel.edu> GKZ117@uriacc.uri.edu (F. Michael Theilig) writes: >On 27 Feb 91 10:30:25 GMT (Stewart C. Russell said: > I believe the newest version of NorthC has much better screen output. > I'm not really sure. I'd have to try it out again. > Actually, I think that the screen output speed is more of a factor of > the libraries being linked in. As ZC, DICE, and PDC all use amiga.lib, > it's my guess that there isn't going to be much of a difference between > them. SAS also. NorthC uses it's own replacement for amiga.lib and > the consequence is speed. Please correct me if I'm wrong. >-------- > F. Michael Theilig - The University of Rhode Island at Little Rest > GKZ117 at URIACC.Bitnet Well, it depends how complete the other compilers are, the main factor in screen output is buffering. When outputting to the screen, line buffering is normally used. When redirecting to a file, full buffering is normally used. Using amiga.lib has nothing to do with it, there is no way to get around having to eventually call Write() to write to a file handle (e.g. Output()). What does matter is how often you make the call (e.g. buffering used, if any). -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
andrew@teslab.lab.OZ (Andrew Phillips) (03/06/91)
In article <45620@nigel.ee.udel.edu> Dennis_Grant@cmr001.bitnet writes: > [ about using BYTE Sieve of Eratosthenes Benchmark with NorthC ] >... > On a PC-XT, it (supposedly) took about 250 seconds. With which compiler? >... > I edited the source code, got rid of the printf("%d\n",prime); >statement inside the main loop, and reran it. Bingo! One loop each second. >(More or less) for a final score of about 100 or so. As expected. > > My conclusion: The printf was taking a LOT of time to execute. > > My question: Is this normal? Could a lowly XT really crank out 1600000 >printfs faster than my Amiga, or is this a quirk of NorthC? (or did BYTE >delete those printfs too?) Any ideas? The printf is *not* part of the benchmark, as should be mentioned somewhere in the textof the Byte article. The benchmark is not designed to test I/O (which would be somewhat operating system dependant anyway). The printf is in there to make sure that the program is working properly and should be deleted before any timings are made. PS Taking 40% of the time of an IBM PC (100/250) does not say much for NorthC. I would expect a good C compiler to produce code five time faster (on a standard 7MHz Amiga vs a standard 5MHz PC clone). Andrew. -- Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 289 8712