Multiple processors - multiple instances of an app
Blitz3D Forums/Blitz3D Programming/Multiple processors - multiple instances of an app
| ||
| Hi, in a program of mine I perform a pre calculation that can take approximately 5-10 minutes to perform on my machine. I am pretty sure that if I ran it on a machine with dual processors (of similar speed individually) it would not be any faster because blitz doesn't do multiple threads, or so I've heard. However - if I created 2 versions of the app which performed the same process but on different data (ie app 1 might deal with all points on a grid in one region while app 2 might deal with the remaining points on the grid) would simply running the two apps simultaneously on a dual processor machine allow me to make use of the additional processing power, after which I could recombine the data into a single data file? |
| ||
| You could produce 2 different Blitz programs that each dealt with half (or a quarter) of the job. If you detect dual processors (or a P4 with HT) then you could launch the 2 external programs from your main app. All your main app would have to do is wait for some sort of signal that the 2 external apps have finished. The signal could be your 2 external apps writing out their data to a file (which your main app can then combine). You might want to go with 4 external rather than 2, there are going to be people out there with dual CPU's with dual cores, and P4 dual cores with HT (4 virtual CPU's). Of course, the biggest speedup may be a change in your algorithm or optimisation of your code. Can I ask what it is you're precalculating? If it's something relatively simple yet repetative, could it be done in C? |
| ||
| I have a P4 3.0Ghz with HT and no programs ever really use more than 50%, which is great for multithreading. Your idea would work fine with dual processors or a HT processor (which as far as I know is almost the same thing), as long as you can get multiple instances of your app to "cooperate" with each other properly, or however you combine their results. |
| ||
| Thanks for the response. Vinylpusher - I am precalculating pathfinding for a static 2d map so that creatures in my game can get from any point to any other point on the map taking the shortest route simply by knowing the start location on the grid and the end location on the grid and using a lookup table to determine 'what grid square should I go to next to get there'. |
| ||
| Right-o. Tricky one, that :) |
| ||
| I've herd of dual processors just taking half the job, so one would calculate the maths and the other with the file handling and all. But i dunno really. |
| ||
| I've herd of dual processors just taking half the job, so one would calculate the maths and the other with the file handling and all. But i dunno really. |
| ||
| Thanks for the response. Vinylpusher - I am precalculating pathfinding for a static 2d map so that creatures in my game can get from any point to any other point on the map taking the shortest route simply by knowing the start location on the grid and the end location on the grid and using a lookup table to determine 'what grid square should I go to next to get there'. Bloomin eck! I was doing the exact same thing myself yesterday!!!! :) took my system half an hour to map out a small 16x16x16 (3d) grid. May i suggest A*? I need to learn it myself too! |
| ||
| Cygnus - I am quite happy with the pathfinding technique I use - it is in use in the Gauntlet style game I am working on it just takes exponentionally longer (^4) if I increase the size of the grid. |
| ||
| I know exactly. Does your code work then? Because I cant get mine to, and I need to get it to. I would be very interested in knowing how you got it to work :) 16x16x16 grid= (16x16x16)x(16x16x16) calculations. Lol, Sorry for HiJacking. :) |
| ||
| The code works fine (I am using a 2d grid) and the pathfinding around a static environment is perfect - basically all each creature has to do is check what grid square they are in, what grid square the target is in, read the value of an array at those coordinates which says what direction to go in to get to the next grid square along the route. I will post it when I get the chance. |
| ||
| Indeed. My question is how you found the path from A to B in the first place- since im in 3D, but on y=0 always, im linepicking from the enemy towards the player. if its not there, i check in 8 directions around the enemy, and with each of these, i check from their collision point towards the player. Until the player is hit, or too much time is taken. (stop it from freezing with map bugs). the things keep driving the wrong way :) I would be interested in how that part of your code works. :) |
| ||
| Hi Cygnus - I've uploaded my pathfinding routine to the code archives. It can be found here: http://www.blitzbasic.com/codearcs/codearcs_bb/1488.bb It has a very tiny example but you should be able to see how it works from here. I have been working on another pre calculated method that uses regions rather than grid squares. While I haven't written it yet it works like this: Divide the world into regions that (once again a 2d map) from any point in that region to any other point in that region are able to get to each other by moving in a straight line without crossing a boundary or obstacle. Then if a unit wishes to move within that region then it is free to do so, if it wishes to move to another region then do so by moving to the boundaries between regions. Similar to waypoints but with 'zones' (much like the borders of a country on a map) where regions join. |
| ||
| Matty- I think our minds are thinking the same. I was going to ask Evak to define some "regions" just last night to speed everythnig up. In 3D, i set out a grid, but any of the points could be put anywhere else, so i thought of optimising it using areas. You've just given me a 3rd idea. I will try to program it later- and I too will show the code if it works. Its a bit hazy at the mo. Thanks man. It's very generous of you to share :) |
   |