dual-core to quad-core processor

I recently got a new PC and went from a dual-core to a quad-core processor. Also, the video card was improved significantly. With this, I dusted of an old model that ran very slow on my old machine. This model had an enormous amount of flow items...like 10,000 or so. Yes, they ALL don't have to be rendered. For example, most could have been created as 2d textures and then converted into 3d shapes once they became in viewing range....I pretty sure that could have been done as well as other "tricks."
Anyway, to my surprise- the model didn't run any faster on my new machine. I think I read that FlexSim will only run on a single thread, so going to the quad-core processor wouldn't help a bit. Right? Is this an industry standard for discrete event simulation? This is causing some concern in some circles because we intend to try and use FlexSim in some virtual reality applications. This could put quite a demand on FlexSim. We have the hardware, will FlexSim use it?

Gavin,

Multi-threading is a tricky problem for discrete even simulation. The main problem is the descrete event part. This means that each event in the event chain happens at an exact and seperate time (as opposed to continuous or "fluid"). The main problem occurs when you try and decide if a later event can be calculated at the same time (on another core) as the current event. It sounds simple check and see if Event A is seperate and won't affect Event B and then run Event B. But wait, any event has the possibility of spawining off seperate events that may occur before Event B (senddelayedmessage at zero time). What happens if the events spawned by Event A that happen prior to Event B change the outcome of Event B? If you are using a single thread the answer is Event A will affect Event B through a spawned event, if you are using a multi-thread then the answer is nothing and that's bad.

We have looked at different alternatives for taking advantage of multiple threads and we are currently working on some things but we don't have anything right now.

Brandon

Gavin,
Right now Flexsim is a single-threaded application, so unfortunately you will only be able to utilize one of the cores on the new hardware. This is a very difficult issue in regards to discrete event simulation, because the key requirement for being able to use multiple cores, i.e. multithread, is that it doesn't matter in which order you do a set of operations. However, discrete event simulation, by nature, does not meet this requirement, because you have an event queue for events that are to happen at certain times, and each event must be executed in the proper order, or else the simulation time won't progress properly. I do not know the specifics of other discrete event simulators, but I assume they are presented with the same issues.

However, despite the inherent problems, there are some situations/subtasks within a discrete event simulator that can be multi-threaded. These would probably need to be performed within a given event, where that subtask is a somewhat hefty operation. For example, some models are set up to do small incremental time updates, and then perform large state updates of the model on each time increment.

For example, the fluid object library uses a ticker mechanism to increase time by a small amount and then update fluid contents of each of the objects in the model. There may be some multi-threading capabilities that can be added to this task because, if set up properly, the order in which you update objects' fluid contents may not be essential (although right now it is, so emphasize the "if set up properly" there).

Also, problems that involve agent-based logic, or a "hive" type problem, where you repeatedly increment the simulation clock by a small amount then each "agent" decides what to do next based upon its environment. This can be multi-threaded because the order in which each agent decides what to do next doesn't really matter, because technically they all decide at the same simulation time. This might apply to problems like traffic simulation, war simulation, population dynamics, etc.

Another problem that might be open to multi-threading is a task that involves unordered search. For example, in Flexsim CT, there is a mechanism that tries to place a container in the "perfect spot" in the yard by searching through every single possible slot, and giving each slot a score. Then the slot with the highest score is chosen to put the container into. This can be multi-threaded because it doesn't really matter in which order you search the yard (however, if you want the simulation to be repeatable then there can be no scores that tie).

Anyway, I've probably made a short story long here, but I think you get the idea. The tough thing is that each of these problems has to be approached individually. It's not like there is some checkbox that you can just check to enable multi-threading. However, since it seems that this is the direction that future CPU development is taking, it is in our best interest at Flexsim to try and utilize the multi-core technology where we can.

Also, another option which is already available, with a little manual work on your own, is to use multiple instances of Flexsim to run different scenarios of an experiment simultaneously, one instance for each core, then merge the results of the experiments. With this option, you can't compile Flexsim, because they're sharing some resources when they compile, and it messes stuff up. But if you're just using flexscript and/or dll's, you can open several instances of Flexsim and run multiple scenarios simultaneously, and it will naturally use all of your cores. I have done this on one of my projects, and perhaps that should be something that Flexsim supports more fully in future releases, namely setting a subset of the scenarios for each instance to run, and then merging the results once finished.

Additionally, I have attempted in a previous project to use OpenMP, a multi-threading technology that makes it easier to do these types of problems, in conjunction with Flexsim's dll mechanism, to create a dll that uses multi-threading as part of a collision detection algorithm. However, I wasn't able to get it working (the dll compiled correctly, but it didn't create the worker threads properly). This may be because Flexsim's engine may need to enable OpenMP first. I hope to look into this before the next release and see what needs to be done on Flexsim's side to enable this functionality.

Also, I have been able to successfully create a dll that utilizes multi-threading. The COM control that I posted a while back uses multi-threading to set up an RPC server to listen for requests from external applications like Excel. However, this was done to set up a "listening" thread, and doesn't really apply to the speed improvement problem.

Anyway, hope this helps.