c compiler benchmarking

Comments

• thricenightly

  March 2017

  Hmmm, no responses, which is a bit disappointing 'cos I was hoping to learn some stuff from this thread. :) I guess no one else knows much about it either.
  
  The problem with the benchmarks you have so far is that they appear to be math exercises, and I don't think those are very useful for Spectrum stuff. Obviously benchmarks aren't particularly representative of anything in particular at the best of times, but these appear to be way off what most people would probably code a Spectrum to do.
  
  What do Spectrum's do these days? Since it's probably mostly games, I'd guess that copying memory about and shifting/rotating values would see most valuable optimisations. Sprite manipulation, screen buffers, collision detection? I'm guessing really. As I said, I hoped to learn. :)
  
  Do any of the more experienced developers on here have any ideas? What sort of code might be written in C which might benefit speedwise from an optimising compiler?
• Alcoholics Anonymous

  March 2017

  thricenightly wrote: »

  The problem with the benchmarks you have so far is that they appear to be math exercises, and I don't think those are very useful for Spectrum stuff. Obviously benchmarks aren't particularly representative of anything in particular at the best of times, but these appear to be way off what most people would probably code a Spectrum to do.

  
  I have found more standard benchmarks that I will include. People can argue about their utility later.
  
  The dhrystone one should have some vague connection to spectrum programming. It's meant to test common tasks in integer programming (ie not numerical) and can represent, in a fashion, the glue logic used in games.
  
  Whetstone is a test of the floating point package which won't have much connection to the type of programming commonly done on spectrums. However among the z88dk examples are a number of games that do use the float package for simulation so it could be relevant for game types that involve simulation. In these cases program size rather than speed would be most important.
  
  Pi is about 32-bit integer computation, again maybe not so relevant.
  
  Sieve is there because everyone does this benchmark. I'm not sure what it tells you other than let you know if any compiler has noticeably more loop overhead than another.
  
  Binary trees is one of the new benchmarks I found. Really it's there to test whether malloc/free is working properly. Unless you do systems programming (this could happen on a spectrum with disk access) you're going to use something else like static allocation (arrays in global scope), obstack or block memory allocation.
  
  Fannkuch I'm not sure what that is about yet other than possibly being useful as a vaguely game logic operations type thing.
  

  What do Spectrum's do these days? Since it's probably mostly games, I'd guess that copying memory about and shifting/rotating values would see most valuable optimisations. Sprite manipulation, screen buffers, collision detection? I'm guessing really. As I said, I hoped to learn. :)

  
  I'm interested in setting up a sort of gamer's benchmark (mentioned near the end of this thread):
  
  https://www.msx.org/forum/msx-talk/development/c-benchmarks
  
  If you have any suggestions for code fragments, I'm all ears :) Mentioned in that thread is a small code snippet used in msx software for updating sprites. The spectrum has about 40 games written in C I think but very little of it is open source. The only large open source c game I can think of is Pietro Bros. Churerra was used as engine for a large number of games so I may be able to trawl that for common game code.
  

  Sprite manipulation, screen buffers, collision detection?

  
  For the spectrum at least, these things are normally handled by the sprite engine. Sprite engine can mean one of the available sprite libraries but it can also mean some bespoke set of asm routines.
  
  An msx with sprite hardware (eg) is much easier to get good results out of without a game library which means more housekeeping code could be in C. On the spectrum, the engine must be fast so a lot of functionality gets rolled into it.
  
  With sp1, sprite manipulation and buffers are handled by the engine. The program just tells it where to move sprites to and what background tiles to update.
  
  Nirvana and bifrost are a little lower level. You have to print and erase like you do in basic but otherwise the engines do all the screen drawing and buffering.
  
  FASE I am still coming to grips with so I can't say how it works with authority. But again, it manages the screen buffer and draws it. The user updates sprite characteristics like position and animation frame.
  
  
  A very important characteristic is compiled program size so I will be including a set of programs compiled for cpm (lowest common denominator) to compare compiled program size. On the (48k) spectrum, it's always a struggle to fit what you want in memory when programming in C. If anyone has anything sans platform specific code that is fit for use in a size benchmark, let me know. It has to run on cpm so nothing more than printf and scanf for interaction.
  

  Z88DK - A Complete Z80 Development Toolkit
  Write games in C using Z88DK and SP1
  
• Timmy

  March 2017 edited March 2017

  thricenightly wrote: »

  The problem with the benchmarks you have so far is that they appear to be math exercises, and I don't think those are very useful for Spectrum stuff.

  On the contrary, most people who are using C is using it for math exercises... Multiplications, array manipulations, that's mostly the stuff you'd use C for. Sprite routines? I wouldn't write that in C.
  

  What do Spectrum's do these days? Since it's probably mostly games, I'd guess that copying memory about and shifting/rotating values would see most valuable optimisations. Sprite manipulation, screen buffers, collision detection? I'm guessing really. As I said, I hoped to learn. :)

  Out of these things, only collision detection (which can be one simple but long line of 'if') would be done in C, at least on the Spectrum. I'd also say movement logic would be done in C too, but a lot of low level routines still belong to assembly (or a separate libray like sp1). For newer computers, a lot of things you've mentioned above can be done in C too, but it's not feasible for the humble Speccy.
  
  The sp1 library is fast enough for most of the casual usage, by the way, and stuff like sprites, screens and input is quick enough if you've seen my z88dk/sp1 demo somewhere in the Development part of this forum.
  
  What is worrying is stuff like simple collision detection or movement logic. There are times when a bounding box check will generate hundreds of bytes of code. Movement logic is even worse, they can take up multiple K's if I write it in C, which is a lot if you want to fit everything into 48K.
  

  Do any of the more experienced developers on here have any ideas? What sort of code might be written in C which might benefit speedwise from an optimising compiler?

  I think that you'd be surprised to hear that most of the C uses in games is still the simple array manipulation (for maps), movement logic (for monsters), and collision detection (for the player). They are the same category as math exercises, because both require array manipulation, and logic manipulation. What I also would like to see is a test with many function calls to see how much they blow up in size and speed. As for the low level stuff, just use sp1 instead. It's fast enough for most uses.
  
  
  EDIT: If you want to learn, start by the sp1 demo thread I wrote in the Development section (I think there's a newer version included in the z88dk distribution.) It's more geared as an introduction to the low level parts than random benchmarks.

  Post edited by Timmy on March 2017

  How to write a simple BASIC* horizontal scrolling game (Tutorial) - How to write a simple C+asm horizontal scrolling game (Tutorial, z88dk)
  Games List 2016 - Games List 2015 - Games List 2014