[Ktechlab-devel] looking at Simulator

Alan Grimes agrimes at speakeasy.net
Mon Dec 29 02:13:57 UTC 2008


I pushed out the patch to take switches out of the simulator, Switch
will need to be patched somehow, see the todo.

The todo's for Simulator are as follows:

1. The simulator should not be tied to the UI, remove all UI calls from
the simulator.

There should be a separate UI refresh class that will operate in a
different thread that will update the screen as fast as possible while
the simulator can do it's computations without having to wait for GUI
stuff to happen, this should allow the usable number of simulator
steps/second to be increased dramatically.

2. If it's still a problem after fixing 1, implement an interface class
so that we don't have redundant code like this:

##################
		// Update the non-logic parts of the simulation
		{
			list<Component*>::iterator components_end = m_components->end();

			for (list<Component*>::iterator component = m_components->begin();
component != components_end; component++) {
				(*component)->stepNonLogic();
			}
		}

		{
			list<Circuit*>::iterator circuits_end = m_ordinaryCircuits->end();

			for (list<Circuit*>::iterator circuit = m_ordinaryCircuits->begin();
circuit != circuits_end; circuit++) {
				(*circuit)->doNonLogic();
			}
		}
#####################

Which is basically the same code twice because of the way C++ works and
how it was coded...

Ideally there would be a simulator thread that is forked off from the
main application thread. The current best practices for doing that
appears to be by using OpenMP, I'm gonna hafto buy me a book on that. =\


-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.





More information about the Ktechlab-devel mailing list