Author Topic: Regarding the enviroment grid!  (Read 4307 times)

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Regarding the enviroment grid!
« on: April 09, 2006, 04:00:21 PM »
Okay I have thought about the environment grid, and under all circumstances we need it.

What is the problem:
To CPU expensive, will slow down the simulation a lot! (Just to update others)

So what can we do? I have read on our wiki about this, and I recently had a course at uni, about OS' and Multiprogramming, so a simple idea started to form in my tiny head. In the VB version it will be nearly impossible to add threads (the timer being the best bet), but I the C version, it should be no problem, or so I think (but I do not known how we do it exactly). We could have a main thread with as it is now, and a secondary environment grid thread. Still this needs some more considerations, as is, but right now the C version is threaded, by the one main and the GUI.

Please correct me if I am wrong.
« Last Edit: April 09, 2006, 04:01:47 PM by Greven »
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Regarding the enviroment grid!
« Reply #1 on: April 09, 2006, 04:10:16 PM »
Yes, threading is an option if you have an idea that could use it.

If you've read what I have on the wiki about it, then you know as much as I know about it.  Especially be sure to read the posting on the Gamedev forum about it.

Feel free to share

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Regarding the enviroment grid!
« Reply #2 on: April 09, 2006, 04:15:06 PM »
Geee I have "easter free" as I might put it. It will think a little more about it, but maybe I come up with nada!
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Regarding the enviroment grid!
« Reply #3 on: April 09, 2006, 06:21:32 PM »
In general, threading won't buy us much w.r.t. overall performance unless running on an MP machine.  The architecture is CPU bound on a single proc box even in the current VB version.  Threading alone, no matter what you thread, won't increase speed of sim execution on a single proc box (and might slow it down a few percent due to context switching overhead) though it does have the potential to improve things like UI responsiveness to the user (I beleive Nums already has the UI in it's own thread in the C++ version).   Algorithim improvement like what Nums has been working on is the best bet for notable performance improvements in the new version.
« Last Edit: April 09, 2006, 06:34:59 PM by EricL »
Many beers....

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Regarding the enviroment grid!
« Reply #4 on: April 12, 2006, 11:58:38 AM »
EricL that might just be true. About the UI (GUI) I already hinted that Num had incorporated a secondary therad, but it was just some random thoughts shooting wild. I really hope to see a nicely implemented enviroment grid w. diffusion etc., and I really hope that Num will succed.

Regarding the algorithmic approach I cannot agree more, and Num have already found numerous ways to improve both eye-recognition and the collision detection. But w/o some miracle, the improvements in this area (which alone, threads will not improve at all) will do nothing, unless we settle for some less than perfect approach regarding the grid. However this might be the case (f.ex. we just update the grid every 10th cycle or something like this) we will end up with, and I think all (including me) are more than happy to get the grid going, with a more interesting DB as a result.

Btw. DB is not entirely CPU bound. Some autosaving can be switched on, and here threading will do. Maybe we could implement both, I dont know, only time will tell.
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Regarding the enviroment grid!
« Reply #5 on: April 12, 2006, 12:22:38 PM »
Completely agree that threading will help in cases where the program does I/O either to disk or to the network or as we add architectual artifacts which create global critical sections.  The affordability of MP machines is also improving, so it won't be long before threading helps main-line perf as well for those with such machines.  Didn't mean to sound negative on threads, just wanted to make the point that they arn't magic or free.  Multi-threaded bugs are a bitch to find sometimes...

As far as the grid, I don't know enough about it to comment intelligently, but I'm all for a more complex environment.
Many beers....

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Regarding the enviroment grid!
« Reply #6 on: April 12, 2006, 12:32:16 PM »
Quote
Multi-threaded bugs are a bitch to find sometimes...


Oh you bet. I have just made an exam project about diskscheduling in C on linux/unix machines, with thread, mutex' you name it, I have used it.
My program compiled perfectly etc., but when run I got an error ---> killed (in 1 out of 10)! The program just returned the text "killed" instead of some error or something!!!! I were able to track it down to just one line of code, a free()! When I removed this single line the program did run fine, excepted that the program then had a memory leak then... It took me well of 6 hours to track this shit down.... But I settled for some mixed approach, indicating it in my paper... Well back to topic... right
« Last Edit: April 12, 2006, 12:34:39 PM by Greven »
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Regarding the enviroment grid!
« Reply #7 on: April 12, 2006, 12:48:19 PM »
Quote from: EricL
Multi-threaded bugs are a bitch to find sometimes...

 Amen, hehe.


When I finish the C++ version to a stable, releasable version my 5 top priorities are:

1.  Speed
2.  Environment Grid
3.  Metabolism
4.  Specialization and Speciation
5.  Sexual Reproduction

in that order.

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Regarding the enviroment grid!
« Reply #8 on: April 12, 2006, 01:01:59 PM »
OK sounds good to me....
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001