Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / problems with memblocks

Author
Message
Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 17th Sep 2006 19:30 Edited at: 25th Sep 2006 22:46
I made this program after reading a tutorial about memblocks, but it's very slow. Do I not understand something or is it just lag?



When I don't use sync sleep and the memblock commands are executing the hard drive sounds like it is being accessed. I'm very confused because memblocks are supposed to be stored in RAM, not the hard drive.

Confucius Say...Programmer who makes genetic programming system loses job
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 17th Sep 2006 22:10
Code Dragon....how much system RAM do you have? That is much more of a factor than you might imagine. Are you running many applications at once? HD access is not only on your app, or DBPro...Windows will swap your code and data to disk without your asking it to if it needs RAM. Since your app makes memory requests, Windows sometimes has to page other things out to the HD in order to fulfill your memory request. Also, DBPro is accessing memory all the time, even when you make function calls that do not directly request memory.

Try running only your app. You could also disable/exit things in your system try that are not needed to stop the HD access, but...add 128 or 256MB of RAM. Also, check your virtual memory settings. Should let Windows handle it, but...sometimes the minimum swap file size is too small. It should be at least 1.5 times the total RAM.

I did not try to run your code, however.
Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 17th Sep 2006 22:53
My system has 1.93 GB of RAM. The memblocks are made from 256x256 images, and as far as I know that's about 512 KB. When I run this program as a stand alone application I still have this problem even though I'm not low on virtual memory.
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 17th Sep 2006 22:58
Sorry..I was hoping that my fix was yours, too. Seriously...you think you got enough RAM This is indeed an interesting thing, I think I want to study it...later, after football.
Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 25th Sep 2006 22:51
No one has any idea what's going on?

Now that I think about it the noise doesn't really sound like the hard drive at all, but not the fan either, so I'm really confused. If no one is trying this code because they think it might break their computer, my computer is working fine.

My computer is an AMD Athlon 64 X2 Dual Core Processor 4200+ 991 MHz, if this clarifies anything.

By the way, it uses DarkMATTER.

Confucius Say...Programmer who makes genetic programming system loses job
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Sep 2006 04:12 Edited at: 26th Sep 2006 04:16
Hello,

One thing I noticed is you have several update matrix commands occuring in your main loop inside the functions. Update matrix commands take a lot of system processing and definately affect speed and performance. This command should be used as little as possible.

Another speed hit can come from using trig calculations in a loop. If you can, it may be helpful to set up a lookup table for values that you know are going to be in a specific range - say between angle = 10 and angle = 30. Take the sin of these 21 values and store them in an array. Then, reference the sin of the angle with the array instead of calculating it: mysin(angle) = previously stored sin value in index angle.

Also, global variables take up more memory than local variables. While this isn't as much of a concern as it was several years ago in programming, it's something to think about. Arrays and memblocks behave like globals in that they don't get destroyed until they are undimensioned or deleted - they continue to use up memory. The more memory that is used up, the more of a performance hit your app may suffer.

Also try setting your sync rate somewhere between 40 and 60. While sync rate 0 is supposed to use the maximum sync, I've run into situations where it seemed to behave the opposite and hindered my program.

I don't have DB Pro so I can't test your code without having to modify it.

Enjoy your day.
Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 28th Sep 2006 01:22
Thank you for responding.

When I turn off the update matrix command, I don't get much of a speed boost, but thanks for pointing out about the trig functions, I didn't know they were so slow.

I figured out why it's so slow on my own; 256x256 images are just too large. The memblocks are processing 256 KB every loop. I scaled down the images to 64*64 and now there is no noticable FPS drop, and the images still look pretty good.

I still have no idea what that strange noise was, though.

Confucius Say...Programmer who makes genetic programming system loses job

Login to post a reply

Server time is: 2024-11-27 05:38:04
Your offset time is: 2024-11-27 05:38:04