Sunday, May 02, 2010
DMA Design radio program
A while back the BBC did a little radio program on Dave and DMA Design, it's a pretty good program and well worth a listen. It's mainly four of us talking about how it all started, and you can hear Dave, Me, Russell and Steve talking about how it all got going. Anyway... it's pretty good, so have a listen.
Friday, April 09, 2010
Quiz...
Okay, so perhaps I should have been a little clearer, but the general rule of question one sticks through out. So here we got...
1) Memory Access. This is it pretty much it, especially on today's hardware but does have a similar effect (if not as profound) on older machines as well. If someone is reading/writing gigs of data every frame, it's gonna suck, not just because they have a huge loop in there, but because in modern computing (and we'll stick with this just now), memory is the number 1 enemy.
In the past, CPU access was around the same speed as memory, so it would be a little slower to read from memory - usually just a few cycles. These days, memory is incredibility slow compared to the CPU. Register operations will (in real terms) take less than a cycle, while un-cached memory access can take thousands of cycles (once you remember page faults and the rest).
This is crazy, so the less memory you can touch the better. Now... this may include reducing passes over data and doing it in one pass (while doing a little more register based work), or simply removing data access and tables if you can do it in a simple calculation. In the past, we used to have multiply and divide tables, but these days this table can be so expensive, you're far better just doing the ASM instruction which only takes a few cycles.
So, heres a real world example - particles. If your doing particles on the main CPU (we'll ignore the GPU for now), then the smaller you can make your particle structure the more you'll be able to render; not because you can draw more, but simply because the CPU only has a limited memory bandwidth and reducing that means you can do more, or better yet, do other things - like gameplay.
I've seen it over and over again. People continually looping over large amounts of data, wondering why things are slow when it's not that much data they're processing. Remember in this day of the multitasking OS, a 1Mb cache is not yours alone. You're data will be continually kicked out by other processes, so even if you only have 64K of data, you'll be surprised how little time it spends in the cache. The answer is to prefetch the next block, and do a little more processing on the current one, thereby reducing the number of iterations you have to do. After all, if your talking 400 cycles (say) to read a cacheline (around 64bytes last time I checked), then why not use the 400 cycles doing something instead of 400 cycles waiting on memory coming into the cache?
2) This actually has nothing to do with optimisation - by bad. Its a simple 2 part question...
2.a) Release it. No game, or application is any good if you never release it. No matter how shiny, awe inspiring, or ground breaking; who cares if it never sees the light of day? So rule 1 of any program development, make sure you get something out, or it's just wasted effort.
2.b) Make it fun. In games, it's easy to release something with lots of features and levels, but if it's not fun, no ones gonna play it. It's that simple. I can name several games that appear to have been developed by idiots. Games that were all gloss and no gameplay. Some teams fixate of making things as pretty as possibly, but thats really not the most important thing. You have to enjoy being IN the game, or like 2.a it's pointless and a waste of time and effort. You'd be amazed how often this rule is ignored, or something particularly frustrating removes all the fun that SHOULD be there.
So there you go... Yeah, not the best phrased questions, but I bet looking at these you're either nodding in agreement, or shouting at the monitor something like "Rubbish! Algorithms are FAR more important!!". Well, this is true... but given even a reasonable algorithm, you can then apply the memory rule and speed it up more. The less memory you touch, the quicker your code will be, it's that simple.
oh... and no smart answers about being in a calculation loop with no memory access for a second - we're assuming you're not a moron. :)
1) Memory Access. This is it pretty much it, especially on today's hardware but does have a similar effect (if not as profound) on older machines as well. If someone is reading/writing gigs of data every frame, it's gonna suck, not just because they have a huge loop in there, but because in modern computing (and we'll stick with this just now), memory is the number 1 enemy.
In the past, CPU access was around the same speed as memory, so it would be a little slower to read from memory - usually just a few cycles. These days, memory is incredibility slow compared to the CPU. Register operations will (in real terms) take less than a cycle, while un-cached memory access can take thousands of cycles (once you remember page faults and the rest).
This is crazy, so the less memory you can touch the better. Now... this may include reducing passes over data and doing it in one pass (while doing a little more register based work), or simply removing data access and tables if you can do it in a simple calculation. In the past, we used to have multiply and divide tables, but these days this table can be so expensive, you're far better just doing the ASM instruction which only takes a few cycles.
So, heres a real world example - particles. If your doing particles on the main CPU (we'll ignore the GPU for now), then the smaller you can make your particle structure the more you'll be able to render; not because you can draw more, but simply because the CPU only has a limited memory bandwidth and reducing that means you can do more, or better yet, do other things - like gameplay.
I've seen it over and over again. People continually looping over large amounts of data, wondering why things are slow when it's not that much data they're processing. Remember in this day of the multitasking OS, a 1Mb cache is not yours alone. You're data will be continually kicked out by other processes, so even if you only have 64K of data, you'll be surprised how little time it spends in the cache. The answer is to prefetch the next block, and do a little more processing on the current one, thereby reducing the number of iterations you have to do. After all, if your talking 400 cycles (say) to read a cacheline (around 64bytes last time I checked), then why not use the 400 cycles doing something instead of 400 cycles waiting on memory coming into the cache?
2) This actually has nothing to do with optimisation - by bad. Its a simple 2 part question...
2.a) Release it. No game, or application is any good if you never release it. No matter how shiny, awe inspiring, or ground breaking; who cares if it never sees the light of day? So rule 1 of any program development, make sure you get something out, or it's just wasted effort.
2.b) Make it fun. In games, it's easy to release something with lots of features and levels, but if it's not fun, no ones gonna play it. It's that simple. I can name several games that appear to have been developed by idiots. Games that were all gloss and no gameplay. Some teams fixate of making things as pretty as possibly, but thats really not the most important thing. You have to enjoy being IN the game, or like 2.a it's pointless and a waste of time and effort. You'd be amazed how often this rule is ignored, or something particularly frustrating removes all the fun that SHOULD be there.
So there you go... Yeah, not the best phrased questions, but I bet looking at these you're either nodding in agreement, or shouting at the monitor something like "Rubbish! Algorithms are FAR more important!!". Well, this is true... but given even a reasonable algorithm, you can then apply the memory rule and speed it up more. The less memory you touch, the quicker your code will be, it's that simple.
oh... and no smart answers about being in a calculation loop with no memory access for a second - we're assuming you're not a moron. :)
Saturday, April 03, 2010
Performance...
Here's a little quiz for you. Both of these issues have come up in conversation over the past week or so, and I thought it would be interesting to pose them, and give you the chance to prove your smarter that most games developers...
Question 1
Whats the main thing to tackle inside a program, that's virtually guaranteed to speed it up?
Question 2
When writing a game, whats the 2 most important things to make sure you do? (In order please)
The answer to both these questions should be obvious, but lets see how you do. I'll answer them in a couple of days...
Now... if you cast your mind back a few years, you'll remember me doing a fancy little routine for XeO3's bullet allocation. This was a simple "stack allocator" that sped up my code by quite a bit. Well, you can now find this article in the new Games Programming Gems 8 book. Yes, about a year ago I got the article accepted, and it's now in print and out. This is the 1st time I've decided to try and get an article published, but I thought it was about time. It takes the general concept a little further and uses it in standard programming (rather than 6502), and comes with a few little examples.
The only reason I mention this (aside from being chuffed that I finally got something published), is that this is one of the main reasons I still code old machines. Without writing XeO3, this would never have occurred to me. Old machine place unique limits on what you can do, limits that simple don't appear to be around anymore, and as such require you to think outside the box. They are still a valuable learning tool, and can lead to better code on a day-to-day basis. I've now used the Stack Allocator in several applications I've since written, and found it much simpler/quicker to implement than linked lists, not to mention easier to follow. I love how retro coding really can teach an old dog new tricks....
Question 1
Whats the main thing to tackle inside a program, that's virtually guaranteed to speed it up?
Question 2
When writing a game, whats the 2 most important things to make sure you do? (In order please)
The answer to both these questions should be obvious, but lets see how you do. I'll answer them in a couple of days...
Now... if you cast your mind back a few years, you'll remember me doing a fancy little routine for XeO3's bullet allocation. This was a simple "stack allocator" that sped up my code by quite a bit. Well, you can now find this article in the new Games Programming Gems 8 book. Yes, about a year ago I got the article accepted, and it's now in print and out. This is the 1st time I've decided to try and get an article published, but I thought it was about time. It takes the general concept a little further and uses it in standard programming (rather than 6502), and comes with a few little examples.
The only reason I mention this (aside from being chuffed that I finally got something published), is that this is one of the main reasons I still code old machines. Without writing XeO3, this would never have occurred to me. Old machine place unique limits on what you can do, limits that simple don't appear to be around anymore, and as such require you to think outside the box. They are still a valuable learning tool, and can lead to better code on a day-to-day basis. I've now used the Stack Allocator in several applications I've since written, and found it much simpler/quicker to implement than linked lists, not to mention easier to follow. I love how retro coding really can teach an old dog new tricks....
Monday, March 29, 2010
DMA Design - Now part of history.... apparently.
So a couple of years back the old museum in Dundee closed to get a well needed refurbishment, and while shut it got in touch with Realtime Worlds and asked for everything DMA that would could get our hands on. Now the museum is open again and it has a section based on local history, and a selection of the DMA stuff has been put on display. It's very odd seeing something that I've been intimately involved with appear in a museum! Particularly as (last time I checked), I'm not dead yet! But it's very cool to see DMA Design given the same kind of importance as Timex (who made the ZX Spectrum, right here in Dundee) and D.C. Thomson who...well.. own half of Dundee. There's also lots of stuff dealing with life sciences and the like, and to think that we've managed to influence Dundee's past enough to warrent a little display is very satisfying, not to mention a little cool.The newly opened museum is pretty good, so if your in the area, you should pop in and see it
Thursday, March 04, 2010
Update....
So, it's been sometime since I've posted anything and a lot has changed - well, for me at least. I've left Realtime Worlds after some long term disagreements with how the project I was on was being handled, but I wish them all the best and hope they make a go of it. All I can say about the project is that IF they manage to pull it off, then it's gonna be huge! Good luck to all involved, I spent 5 years of my life on it, so I'm still very keen to see it work.
Still onwards and upwards I guess. I'm currently on gardening leave from RTW and have just over a week left before my official end date. It's nice to be able to kick back and relax a bit, although I have been finishing off some freelance stuff I've been doing on the side. I hope this will be announced soon so I can start blogging a little more about it, because it's really interesting in its own right. With luck, I'll have things sorted out in a couple of weeks and everything will become clear.
Because of all this, my retro projects have obviously taken a back seat, and will remain so for some time to come; and the same goes for my electronics. I'd love to get back into them but I have bills to pay like everyone else so I have to concentrate on other things. I'd love to dabble back with my electronics in particular, but it's going to be a while before I can afford to do that again.
Anyways... I hope to announce some stuff in a couple of weeks, and with any luck, you'll all be interested in that as well!
Oh! And you can follow me on Twitter if you REALLY have no life and nothing else to do... I'm on there as MDF200 (which was my old Visual Sciences login ID!
Still onwards and upwards I guess. I'm currently on gardening leave from RTW and have just over a week left before my official end date. It's nice to be able to kick back and relax a bit, although I have been finishing off some freelance stuff I've been doing on the side. I hope this will be announced soon so I can start blogging a little more about it, because it's really interesting in its own right. With luck, I'll have things sorted out in a couple of weeks and everything will become clear.
Because of all this, my retro projects have obviously taken a back seat, and will remain so for some time to come; and the same goes for my electronics. I'd love to get back into them but I have bills to pay like everyone else so I have to concentrate on other things. I'd love to dabble back with my electronics in particular, but it's going to be a while before I can afford to do that again.
Anyways... I hope to announce some stuff in a couple of weeks, and with any luck, you'll all be interested in that as well!
Oh! And you can follow me on Twitter if you REALLY have no life and nothing else to do... I'm on there as MDF200 (which was my old Visual Sciences login ID!
Thursday, January 21, 2010
The cool wall
A little while back the members of our team during a week of coffee breaks came up with the following cool wall. It was a hard fought list with many arguments about the virtue of each machine, but in the end we had our definitive list of old machines. Fans of TopGear will know all about the cool wall, and know it's nothing to do with how good anything is - just that it's cool or not. So heres our list... let battle commence!
Now remember... it's how COOL they were, not how useful, or powerful. The Plus/4 is a great little machine, but I'm not gonna pretend its cool. Also machines like the Amiga 4000 were awesome! But too expensive to be cool. So there you go - thats the rules.
Subscribe to:
Posts (Atom)