Slashdot Mirror
Biomorphic Software
CowboyRobot writes "From the molecular structure of spiders' silk to the efficient use of energy by insects and fish, we can learn many things from Nature and apply them to our engineering tasks.
One thing that nature is particularly good at is the development of dynamic, self-organizing systems.
Ken Lodding is a software engineer at NASA and is currently developing 'swarm algorithms for groups of wind-driven, remote exploratory vehicles'.
He has a six-page article at Queue on 'biologically inspired computing', how to develop 'algorithmic design concepts distilled from biological systems, or processes.'"
It's worth noting that I never said you couldn't. I said it was HARD. If you look farther up the thread, I reiterated this point.
Why is it hard ? Open Visual Studio, make one or more DLL projects, then use these DLLs from the main project according to what you want to do. Making a DLL is nothing more than pressing a few buttons anyway.
10ms res on 2000/XP
Where did you read that? Windows NT provides 1 milisecond resolution. 10 milliseconds is the default timer interrupt granularity. By using the function 'timeBeginPeriod' the resolution can be set to 1 millisecond. Here is an example.
Furthermore, all waitable functions are guarranteed to return at 1-millisecond resolutions (even 'Sleep()'). I have personal experience with this, as I have used the waitable timer functions in many projects.
Finally, Windows have a hidden API ('NtSetTimerResolution') that you can set the timer resolution in nanoseconds. This is kernel stuff, though. And for profiling, you can't beat 'QueryPerformanceCounter' which returns number of clock ticks passed via the RTDSC instruction.
Most Unix systems have a hi-res timer that dives down to the nanosecond range
Which Unix systems are that ? Linux, for example, also starts with a 10 ms granularity, just like Windows (the link above actually saids that any granularity below 10 ms will result in degrading performance on Intel systems). High resolution POSIX timers is a kernel patch, and it is mostly offered in the context or real-time Linux systems.
Solaris also starts with a 10 ms granularity that can be adjusted. Solaris also offers a timer solution based on CPU timer instruction (RTDSC on 80x86).
OS X, not running on the Intel platform, has the benefit of not having the interrupt limitations of Windows, Linux and Solaris on 80x86.
You mean the documents that say "this timer is not actually accurate and is only useful in certain situations", or do you mean the documents that say "the resolution of this timer is dependent on how many processors are in the system".
The "this timer is not actually accurate and is only useful in certain situations" is valid for 'SetTimer' which sets a timer event for a window. This is because timer events are dispatched on the gui message queue.
The "the resolution of this timer is dependent on how many processors are in the system" is valid for all operating systems running on multiprocessor computers. Google it out, if you don't believe me.
Sorry, as far as the industry is concerned, Windows timing blows. Just about every other OS does a better job.
I've shown you that you overreact concerning Windows timers. The 80x86 platform has an archaic interrupt architecture, and that's where the problem is. And this problem concerns all systems, Windows or Unix, running on 80x86. Windows on Alpha have an 1-ms granularity, by default.
There are solutions though to overcome the problems. A nice solution is to use critical sections (that take nano seconds to lock/unlock) and 'QueryPerformanceCounter'). If you search the web, you can even find MFC-based classes for this.