Using an appropriate language (for example, Java), and provided you know what you're doing, threading is not hard. One of the apps I am responsible for routinely runs 800+ threads on 16 processor boxes. I'm no rocket scientist, but it works.
I've written theaded code, too. I've done it in several languages, including Java. The last Java app I wrote that routinely used more than 100 threads per proc was server software that used one thread for each connection, with many hundred simultaneous connections. Sounds like it was probably similar to your app.
In that case, the move to threads wasn't a performance issue. Having that many threads involves quite a lot of overhead, so it would have run much more slowly than something with a more modest number of threads. It was a matter of convenience. I had a single chunk of state data, and it needed to be fed to all the clients. None of the threads had to interact with each other.
Now, let us imagine a game. The renderer needs the geometry in place before it can send it to the graphics card. The physics engine will move the geometry. The physics engine needs to work out the results of the AI. There are lots of relationships like this where it is easy to say that each task should be its own thread, but done with a simple implimentation like in my server software (and I assume your software), the various tasks would be clobbering data, leaving data in an inconsistent state, using extra memory for multi-buffered state, or losing lockstep per-frame synchronisation.
Also, you need to work with single threaded libraries and API's. You can't have two threads trying to render to the same DirectDrawSurface or OpenGL context. That'll run you into a world of hurt (if it does anything at all!). You need to deal with locking and mutexes, and all that fun stuff.
No, threading isn't fundamentally that hard. There are many cases where it is very easy. Making a game ain't one of them.
That said, there are certainly quite a few straightforward ways to take advantage of multiple threads. Audio and Graphics rendering don't need to make significant changes to state, and they can run in parallel as soon as all the geometry is in place. (Audio needs to run after physics so that collisions can trigger audio sound effects.) If you have ten monsters who all need to have AI computed, you can give each monster his own thread. Unless they have gauntlets of psychic communications +2, the threads won't need to interact. Of course, if you are trying to leverage an existing code base to get the game out by the time of the console launch, it may be very difficult to make all that actually happen in practice. I expect that as time goes on, the middleware will become more thoroughly threaded, and we'll see better use of the hardware.
It baffles me beyond words that a (ANY) religious belief system could be so unbelievably willfully ignorant, nearsighted and completely arrogant as to assume their mythical belief system, unsupported by evidence nor reason could even hope to compare to the fantastic wonders of the cosmos which are revealed by actually studying it through the use of telescopes at the top of Mauna Kea. There have been something like 100 planets outside of our solar system which have been discovered using the telescopes on that mountain. Ponder that for a moment. That's sacred.
Well, I'm not a religeous person myself, but I can understand how people get into it. Personally, I think that the telescope issue is primarily ones of salesmanship...
Hey, local tribal leaders. The spirits created the land and the sea and the sky. They made the sacred mountain. They also made the mountain the best place to look at the heavens, and see the works of the spirits. Clearly, in order to better honor them, we should do what we can to see what they have made. Honoring them requires the construction of four small auxilliary telescopes, which would be built according to the appropriate ceremonies.
Instead, the scientists probably started the conversation with a very dismissive attitude, pissing off the other people involved.
There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.
Shouldn't this be that no language makes it any harder to write bad code than to write good code? I mean, it seems to me that it really is quite hard to write a bad program (which does something useful) in Intercal, bf, or optimal IA64 ASM...
Even so, you can't stash something in the menu of the MP3 player that tells it to update its own index? Sure, it may take a moment, or even several minutes if you dump oodles of songs all at once, but it would be really convenient. I keep two copies of some stuff on my iPod so that I can listen to it either on the iPod, or copy it onto a computer I plug the iPod into. It's a waste of space, and it is annoying.
In a real space elevator, you would have a metal wire running all the way past geosynch. orbit - of a thick enough guage to power something that is hauling a large satellite. Yeah, that would add too much mass. There isn't too much in the way of needing to figure out how to power it.
Basically, the thought process is this: Don't bring fuel - it's a waste of effort hauling it up. Don't get energy from the elevator - too much mass. So, energy has to be beamed to the crawler.
Whether that means microwave, or laser doesn't really matter from a physics standpoint. It's clearly possible. It's a damned significant engineering task to try to work out the best way to do it, but nothing too crazy.
Ah, I think I understand this kernel/userland distinction. What you are saying is that Linux is just a kernel, and the GNU people make X11 and KDE, which is how people actually interact with the system. Oh, wait, no they didn't. They made ls and whatnot. Oooooh, they makes it surely worth noting loudly everytime I talk about my OS.
To be fair, I do prefer the GNU userland to the BSD stuff. None of it would exst without gcc, which is probably the single most important Open Source project in existence. But, even so, I find the "GNU/Linux" issue to be just a bunch of whiny pedantry.
Aluminium is always in fashion. I reccomend a full-face covering helmet with thee fins sticking out the back, at least long enough to act as antannae to absorb all the radiation that is the same frequency as your brain waves. Be sure to keep the hat grounded at all times.
Basically, it's very simple. Set up your scene with accurate scale, and out the camera where the kid will be. Have your "extended scene" with whatever. Render.
Then, on the second pass, you put the camera where the projector will be, and use projective texture mapping, so that there is basically a 'spotlight' projecting the previously rendered image onto the walls/screen. This time, the extended scene is not directly visible - the wall you will be making disappear" is what you project the texture onto. I'm going to use a simple vertex for this.
I'm sure it's possible to make a single-pass technique with wicked matrix math, but I'm not that adventurous with only a week left. I think if you did a single pass technique, you would have to restrict yourself to only projecting onto one flat wall. The two pass method will allow fairly arbitrary geometry, as long as every point can be seen by both the viewer and the projector.
What, are you dissing my "costume" made of metal foil? I'm a board certified metallic foils haberdasherer, god dammit, and I demand respect! (And, sometimes I get a little...)
I've decided to go a little nuts this year. At the office, we are decorating the conference rooms, and allowing kids to come in for trick or treat. Our room's theme is "dialogs in the hall of the pumpkin king."
Since we work with kids who have developmental disabilities (and children of parents with developmental disabilities), we can't do anything with strobe lights (a lot of the kids would go into seizures.) or anything very scary. (Where "very scary" literally means anything that would bother a mentally hadicapped five year old...)
So, I decided it would be fun to write a "performance animation" program. Basically, there will be a 3D pumpkin character projected on one of the walls. He will have a background that appears perspective-correct to a person standing in the right spot, thanks to a two-pass rendering algorithm. The character will have a set of triggerable animations and gestures for his hands, and several facial morphs so that he can appear to talk. I will be in another room controlling the animation of the pumpkin king over VNC, and doing the voice, while I watch the kids on a hidden web cam in the room.
It should be pretty slick as soon as I get afew more things finished. It parses and displays the hand animation just fine - still need to add image loading, get texture coordinates from the object files, and add a bit of extra glue for my facial morphing code.
When all is said and done (friday), the kids will be able to have a complete interactiveconversation with a large friendly vegetable.
Of courtse, I would like a chance to work on the "soul stealing vertigo inferno" that I would do if this were for older, less challenged people. I wouldn't want to do it alone though. It would be way more work.
For the vertigo inferno, I wanted to have a few cameras, and some image processing code tied into the renderer, so that it would track the approximate position of the head of the person, and screw with the perspective projection. Given enough projectors to cover most of the visual field, and enough time, I'm pretty sure I could get just about anybody to lose their balance apon entering the room, if they kept their eyes open. Then the zombies would start to get mean...
Oh, the things I could do with a massive budget and a team of ten graphics programmers, modellers, and animators!
The iPod shows up as an ordinary USB mass storage device. I've gotten over 50 GB on my 60 GB Photo. It was episodes of Dr. Who that I wanted to play from my iBook, but couldn't fit on the iBook's 30 GB (and largely full of its own stuff) drive.
My iPod is more portable than pretty much any other easy USB storage option. (I do have an external drive caddy I use with my 3.5" hard disks - I know they exist - they don't fit in my pocket.) I use it all the time just as a hard drive. The fact that it plays music was almost incidental.
So, 60 gigs of music... No, not many people will actually have 60 gigs of music on the iPod. I think I have about 500 MBof MP3's on mine. That doesn't make it a bad buy. The 60 GB iPod becomes more attractive as soon as you aren't sure that the 30 GB iPod will hold everything you want to have on it.
Also, I wasn't sure how to get Linux on my Palm Pilot.
Hell, no. I feel like a giant super man that can pick up a million cars with his bare hands, and knock over thousands of cars with a breath. How the hell is that humbling?
Okay, so... How well will I need to know Swedish, and what are the paperwork hurdles for an american to get a job there? I know a little German, which is in the same general family as swedish, so I could probably get to rudimentary functionality a whisker faster than most Americans.
Given the cost of developing a modern video game in entireity, very few people would be able to afford it. Given the amount of dedication required to really be involved in developing a game from scratch, fewer still would stick with it.
It's about on par with commisioning a major motion picture. Either you let somebody else screw it up for you, or you dedicate two years of your life to screwing it up personally.
You omit one important point from your otherwise well reasoned logic...
vi users are mammals, and they flip out and kill people *all the time.* Some guy dropped a spoon and a vi user edited a whole source tree. That's what I call a Real Ultimate Editor!
Wait, maybe I'm thinking of something else. Something to do with pirates...
The ability to have instant electronic conversations isn't new. Also, private messages on IRC...
Granted, these examples require that you be connected to the same server/network. But, the basic protocols to connect (telnet, ssh, IRC) were always open and documented, so you could connect freely to whatever server you would like, using whatever client you like best, from whatever OS floats your boat.
Common sense also forbids most of quantum mechanics, and relativity. A space elevator is actually quite feasible, but most people do have some very wrong ideas about how it might be built. It's basically just a thin ribbon of carbon so long that the center of mass is in geostationary orbit. Tension holds it up. Mechanically, it really couldn't get any simpler. You have a robot crawl up and down the ribbon.
No, we don't have large scale carnon nanomanufacturing technology in place. It's an engineering issue, not a fundamental problem of impossibility.
Yeah, I'd never put it in real code. I'm generally pretty trusting of my compiler. There are occasional times when I do wacky stuff, but it almost always happens after profiling, and becoming shocked to realise where my slowdown is. Most recently, I was using a C++ vector class for storing lights in a 3D scene. I had to do lighting calculations for every vertex. What surprised me was that the actual lighting calculations were very fast, but what was slow was accessing the light data from the vector of lights! So, I wound up making my own container class for the lights, even though the STL version "worked."
If I hadn't found that I was being bottlenecked by the vector access, I never would have written my own container class. (The more I write, the more chance I'll write a bug, after all.)
The only problem with "job interview" type code snippet questions is that the only compiler is usually your interviewer. You've never met them before, and you have no context for determining optimality outside of what he/she says. In cases like that, I will often assume a non-optimising compiler, and be very literal about the question. I also apologise profusely for answering the question, and explain that in a real project, outside of teh vacuum of an interview question, I would have takena different approach. (And sometimes I will just write it twice if there is time.)
Many of their conclusions are valid. They've shown that pissing on the "live" rail of a 3-rail train system will not shock you (urine stream is too fragmented by the time it hits the rail for electricity to travel), exactly how many bug bombs you would have to set off in a room with an ignition source before the gas was concentrated enough to explode, and that you cannot get sucked into the intake on one of those firefighting helicopters while wearing scuba gear, only to be dumped into the fire and die.
Actually, the 3rd rail episode is one of the ones I consider to have been done poorly. If I recall correctly, they never actually did anything to verify whether an actual urine stream breaks up like that in all cases. They only established that the pressurised stream going through the plastic tube did so. They didn't even address my favorite version of the myth, which is that a drunk guy wet his pants. By wetting his pants and drunkenly walking onto the rail, they would almost certainly have had it. Also, at lower oressure and flow rates, it seems less likely that the stream would have broken up in that manner. given that biological systems are wierdly efficient, it wouldn't surprise me at all if real urine would be a less turbulent flow. This was never investigated...
Bah, the original requirement was to do it with as little memory allocation as possible. You still use a temp variable. Let bitwise operations be your friend.
Oh my god, there is blood everywhere! I had better use Tide brand laundry detergent to do my laundry today. Only tide can get out the horrible filth of an accidental death due to slip and fall in the shower. Oh, if only steve had been wearing Nike brand shoes with new SuperGrip soles, he might still be alive. Nike shoes could have saved him from slipping to his death. If he were still alive, we could go to a McDonalds restaurant to eat Big Mac Value Meals, just like we had planned. I still have the appointment in my handy and reliable Palm Tungsten. Woe is me!
This way, they can still charge for ads, but they can get away without editing them out for the bought downloads. Hooray for double dipping.
Slashdot Mirror
I've written theaded code, too. I've done it in several languages, including Java. The last Java app I wrote that routinely used more than 100 threads per proc was server software that used one thread for each connection, with many hundred simultaneous connections. Sounds like it was probably similar to your app.
In that case, the move to threads wasn't a performance issue. Having that many threads involves quite a lot of overhead, so it would have run much more slowly than something with a more modest number of threads. It was a matter of convenience. I had a single chunk of state data, and it needed to be fed to all the clients. None of the threads had to interact with each other.
Now, let us imagine a game. The renderer needs the geometry in place before it can send it to the graphics card. The physics engine will move the geometry. The physics engine needs to work out the results of the AI. There are lots of relationships like this where it is easy to say that each task should be its own thread, but done with a simple implimentation like in my server software (and I assume your software), the various tasks would be clobbering data, leaving data in an inconsistent state, using extra memory for multi-buffered state, or losing lockstep per-frame synchronisation.
Also, you need to work with single threaded libraries and API's. You can't have two threads trying to render to the same DirectDrawSurface or OpenGL context. That'll run you into a world of hurt (if it does anything at all!). You need to deal with locking and mutexes, and all that fun stuff.
No, threading isn't fundamentally that hard. There are many cases where it is very easy. Making a game ain't one of them.
That said, there are certainly quite a few straightforward ways to take advantage of multiple threads. Audio and Graphics rendering don't need to make significant changes to state, and they can run in parallel as soon as all the geometry is in place. (Audio needs to run after physics so that collisions can trigger audio sound effects.) If you have ten monsters who all need to have AI computed, you can give each monster his own thread. Unless they have gauntlets of psychic communications +2, the threads won't need to interact. Of course, if you are trying to leverage an existing code base to get the game out by the time of the console launch, it may be very difficult to make all that actually happen in practice. I expect that as time goes on, the middleware will become more thoroughly threaded, and we'll see better use of the hardware.
Well, I'm not a religeous person myself, but I can understand how people get into it. Personally, I think that the telescope issue is primarily ones of salesmanship...
Hey, local tribal leaders. The spirits created the land and the sea and the sky. They made the sacred mountain. They also made the mountain the best place to look at the heavens, and see the works of the spirits. Clearly, in order to better honor them, we should do what we can to see what they have made. Honoring them requires the construction of four small auxilliary telescopes, which would be built according to the appropriate ceremonies.
Instead, the scientists probably started the conversation with a very dismissive attitude, pissing off the other people involved.
Shouldn't this be that no language makes it any harder to write bad code than to write good code? I mean, it seems to me that it really is quite hard to write a bad program (which does something useful) in Intercal, bf, or optimal IA64 ASM...
Even so, you can't stash something in the menu of the MP3 player that tells it to update its own index? Sure, it may take a moment, or even several minutes if you dump oodles of songs all at once, but it would be really convenient. I keep two copies of some stuff on my iPod so that I can listen to it either on the iPod, or copy it onto a computer I plug the iPod into. It's a waste of space, and it is annoying.
No, no -- it's "forget the blackjack, and screw the competetive models!"
Ar ethere birthday celebrations planned anywhere? I uess I'll have to ocntact the local planetarium to see if they want to throw a little shindig.
In a real space elevator, you would have a metal wire running all the way past geosynch. orbit - of a thick enough guage to power something that is hauling a large satellite. Yeah, that would add too much mass. There isn't too much in the way of needing to figure out how to power it.
Basically, the thought process is this:
Don't bring fuel - it's a waste of effort hauling it up.
Don't get energy from the elevator - too much mass.
So, energy has to be beamed to the crawler.
Whether that means microwave, or laser doesn't really matter from a physics standpoint. It's clearly possible. It's a damned significant engineering task to try to work out the best way to do it, but nothing too crazy.
Ah, I think I understand this kernel/userland distinction. What you are saying is that Linux is just a kernel, and the GNU people make X11 and KDE, which is how people actually interact with the system. Oh, wait, no they didn't. They made ls and whatnot. Oooooh, they makes it surely worth noting loudly everytime I talk about my OS.
To be fair, I do prefer the GNU userland to the BSD stuff. None of it would exst without gcc, which is probably the single most important Open Source project in existence. But, even so, I find the "GNU/Linux" issue to be just a bunch of whiny pedantry.
Aluminium is always in fashion. I reccomend a full-face covering helmet with thee fins sticking out the back, at least long enough to act as antannae to absorb all the radiation that is the same frequency as your brain waves. Be sure to keep the hat grounded at all times.
Basically, it's very simple. Set up your scene with accurate scale, and out the camera where the kid will be. Have your "extended scene" with whatever. Render.
Then, on the second pass, you put the camera where the projector will be, and use projective texture mapping, so that there is basically a 'spotlight' projecting the previously rendered image onto the walls/screen. This time, the extended scene is not directly visible - the wall you will be making disappear" is what you project the texture onto. I'm going to use a simple vertex for this.
I'm sure it's possible to make a single-pass technique with wicked matrix math, but I'm not that adventurous with only a week left. I think if you did a single pass technique, you would have to restrict yourself to only projecting onto one flat wall. The two pass method will allow fairly arbitrary geometry, as long as every point can be seen by both the viewer and the projector.
What, are you dissing my "costume" made of metal foil? I'm a board certified metallic foils haberdasherer, god dammit, and I demand respect! (And, sometimes I get a little...)
oddly enough, it comes from the french for "left," near as I can figure. I don't know exactly how it came to have the current meaning, though.
I've decided to go a little nuts this year. At the office, we are decorating the conference rooms, and allowing kids to come in for trick or treat. Our room's theme is "dialogs in the hall of the pumpkin king."
Since we work with kids who have developmental disabilities (and children of parents with developmental disabilities), we can't do anything with strobe lights (a lot of the kids would go into seizures.) or anything very scary. (Where "very scary" literally means anything that would bother a mentally hadicapped five year old...)
So, I decided it would be fun to write a "performance animation" program. Basically, there will be a 3D pumpkin character projected on one of the walls. He will have a background that appears perspective-correct to a person standing in the right spot, thanks to a two-pass rendering algorithm. The character will have a set of triggerable animations and gestures for his hands, and several facial morphs so that he can appear to talk. I will be in another room controlling the animation of the pumpkin king over VNC, and doing the voice, while I watch the kids on a hidden web cam in the room.
It should be pretty slick as soon as I get afew more things finished. It parses and displays the hand animation just fine - still need to add image loading, get texture coordinates from the object files, and add a bit of extra glue for my facial morphing code.
When all is said and done (friday), the kids will be able to have a complete interactiveconversation with a large friendly vegetable.
Of courtse, I would like a chance to work on the "soul stealing vertigo inferno" that I would do if this were for older, less challenged people. I wouldn't want to do it alone though. It would be way more work.
For the vertigo inferno, I wanted to have a few cameras, and some image processing code tied into the renderer, so that it would track the approximate position of the head of the person, and screw with the perspective projection. Given enough projectors to cover most of the visual field, and enough time, I'm pretty sure I could get just about anybody to lose their balance apon entering the room, if they kept their eyes open. Then the zombies would start to get mean...
Oh, the things I could do with a massive budget and a team of ten graphics programmers, modellers, and animators!
The iPod shows up as an ordinary USB mass storage device. I've gotten over 50 GB on my 60 GB Photo. It was episodes of Dr. Who that I wanted to play from my iBook, but couldn't fit on the iBook's 30 GB (and largely full of its own stuff) drive.
My iPod is more portable than pretty much any other easy USB storage option. (I do have an external drive caddy I use with my 3.5" hard disks - I know they exist - they don't fit in my pocket.) I use it all the time just as a hard drive. The fact that it plays music was almost incidental.
So, 60 gigs of music... No, not many people will actually have 60 gigs of music on the iPod. I think I have about 500 MBof MP3's on mine. That doesn't make it a bad buy. The 60 GB iPod becomes more attractive as soon as you aren't sure that the 30 GB iPod will hold everything you want to have on it.
Also, I wasn't sure how to get Linux on my Palm Pilot.
Those are the sound guys and network programmers.
Hell, no. I feel like a giant super man that can pick up a million cars with his bare hands, and knock over thousands of cars with a breath. How the hell is that humbling?
Okay, so... How well will I need to know Swedish, and what are the paperwork hurdles for an american to get a job there? I know a little German, which is in the same general family as swedish, so I could probably get to rudimentary functionality a whisker faster than most Americans.
Given the cost of developing a modern video game in entireity, very few people would be able to afford it. Given the amount of dedication required to really be involved in developing a game from scratch, fewer still would stick with it.
It's about on par with commisioning a major motion picture. Either you let somebody else screw it up for you, or you dedicate two years of your life to screwing it up personally.
You omit one important point from your otherwise well reasoned logic...
vi users are mammals, and they flip out and kill people *all the time.* Some guy dropped a spoon and a vi user edited a whole source tree. That's what I call a Real Ultimate Editor!
Wait, maybe I'm thinking of something else. Something to do with pirates...
man write; man mesg; man talk;
The ability to have instant electronic conversations isn't new. Also, private messages on IRC...
Granted, these examples require that you be connected to the same server/network. But, the basic protocols to connect (telnet, ssh, IRC) were always open and documented, so you could connect freely to whatever server you would like, using whatever client you like best, from whatever OS floats your boat.
Common sense also forbids most of quantum mechanics, and relativity. A space elevator is actually quite feasible, but most people do have some very wrong ideas about how it might be built. It's basically just a thin ribbon of carbon so long that the center of mass is in geostationary orbit. Tension holds it up. Mechanically, it really couldn't get any simpler. You have a robot crawl up and down the ribbon.
No, we don't have large scale carnon nanomanufacturing technology in place. It's an engineering issue, not a fundamental problem of impossibility.
Yeah, I'd never put it in real code. I'm generally pretty trusting of my compiler. There are occasional times when I do wacky stuff, but it almost always happens after profiling, and becoming shocked to realise where my slowdown is. Most recently, I was using a C++ vector class for storing lights in a 3D scene. I had to do lighting calculations for every vertex. What surprised me was that the actual lighting calculations were very fast, but what was slow was accessing the light data from the vector of lights! So, I wound up making my own container class for the lights, even though the STL version "worked."
If I hadn't found that I was being bottlenecked by the vector access, I never would have written my own container class. (The more I write, the more chance I'll write a bug, after all.)
The only problem with "job interview" type code snippet questions is that the only compiler is usually your interviewer. You've never met them before, and you have no context for determining optimality outside of what he/she says. In cases like that, I will often assume a non-optimising compiler, and be very literal about the question. I also apologise profusely for answering the question, and explain that in a real project, outside of teh vacuum of an interview question, I would have takena different approach. (And sometimes I will just write it twice if there is time.)
Actually, the 3rd rail episode is one of the ones I consider to have been done poorly. If I recall correctly, they never actually did anything to verify whether an actual urine stream breaks up like that in all cases. They only established that the pressurised stream going through the plastic tube did so. They didn't even address my favorite version of the myth, which is that a drunk guy wet his pants. By wetting his pants and drunkenly walking onto the rail, they would almost certainly have had it. Also, at lower oressure and flow rates, it seems less likely that the stream would have broken up in that manner. given that biological systems are wierdly efficient, it wouldn't surprise me at all if real urine would be a less turbulent flow. This was never investigated...
Bah, the original requirement was to do it with as little memory allocation as possible. You still use a temp variable. Let bitwise operations be your friend.
I expect lots of product placements.
Next week on CSI:
Oh my god, there is blood everywhere! I had better use Tide brand laundry detergent to do my laundry today. Only tide can get out the horrible filth of an accidental death due to slip and fall in the shower. Oh, if only steve had been wearing Nike brand shoes with new SuperGrip soles, he might still be alive. Nike shoes could have saved him from slipping to his death. If he were still alive, we could go to a McDonalds restaurant to eat Big Mac Value Meals, just like we had planned. I still have the appointment in my handy and reliable Palm Tungsten. Woe is me!
This way, they can still charge for ads, but they can get away without editing them out for the bought downloads. Hooray for double dipping.