Time relevance

[jzhou]

Hello.How is the time unit in Simio related to real time? And what is speed factor?

[dsturrock]

In the current version of Simio, there is no fixed relationship between simulated time and real time. The model will run as fast as possible given the contraints of the number of simulation events and related "work" being done. The two other things that most dramatically impact simulation speed are Trace (when trace is on it excuted slower) and Animation (3D animation with a low speed factor runs slower).

We have plans to provide an Emulation product for use in training and testing. Before that product is created, we will add the capability for Simio to run in real time or any multiple of real time.

Speed Factor can be used to speed or slow the animation. Its main purpose is to improve the quality of an animation by decreasing the factor. This also has the side effect of slowing the animation so you can see certain events more clearly. Conversely, if you increase the speed factor, the animation will run faster, but in doing so, certain events (like movement on a path) might become jumpy or too fast to observe.

Fast-Forward can be used to temporarily disable animation to allow the model to execute much fsater.

Running an Experiment provides the fastest execution possible. Not only is animation and user interaction turned off, but it will also take full advantage of all processors on a multiprocessor machine, often running 2-4 times faster.

[KDanielsen]

I have a source (exp(1)) --> Server (exp(1/1.2)) --> sink.

This way, the Server gets a load of lambda=1 and serves at a rate of mu=1.2, giving a util of rho=1/1.2 = 0.833..

Endtime is set to 1 million seconds, so nbr. of jobs to the server is 1 million.

Simio computes a rho of .833, so the sim is correctly set up, I believe.

But, to run this takes me 115 seconds in Simio (I clicked on Fast-Forward, Trace is turned off).

Are there ways to make Simio run this any faster?

(I have searched the Intro PDF and the Reference PDF for things such as "fast-forward", "fastest" ... but found nothing new)

I have an average Windows-7 64 bit

Dual Core E8400 @3ghz, 4GB Ram

Thanks. --Ketil

[KDanielsen]

I see that the EXPERIMENT MODE is 2-4 times faster. I try this (one replication) and it runs slightly faster (109 runtime seconds compared to 115).

One CPU ran at 90 %, the other at 10 %.

I try to run two replications, now both CPUs run at 100 %. Runtimes are 121 and 124 seconds (wall clock time is about 125 seconds).

So, I can see that experiment mode on my dual core CPU halves my waiting time when running experiments.

But, each individual simulation is still 110-115 seconds runtime on a dual core CPU that is about 50 % utilized.

I assume there is no way to speed up Simio further than this.

[dsturrock]

As you have discovered (and I discussed in my post above), running an experiment puts Simio in its fastest run mode possible. And in this mode it will automatically distribute the replications and scenarios across all of your processors/cores. This alone can provide dramatic speedups.

If you have Team Edition, you can actually extend that to use spare processing power in your work group. So if you have 4 quad-processor machines available on your local network, you can run up to 16 simultaneous replications or scenarios.

In terms of modeling, the most dramatic improvement you could make is to build your model at a lower level. The model you described is simple to model entirely in a single process with steps:

(begin) - Seize - Delay - Release - Tally - (end)

with the process triggered by a Timer element and using TallyStatistics elements for any token-related statistics like Time In System. You would not even need to create any entities, it could all be done using tokens which are smaller and faster.

The process approach should be many times faster.

[KDanielsen]

Thanks for the suggestion.

It now takes 30 seconds runtime for 1 million ... tokens, I guess that would be.

First time I try this low-level approach.

I followed your instructions (begin-seize-delay-release-tally). Read the Reference PDF as well.

Added a Resource1 though (so there was something to seize?).

Can see utilization of Resource1 (seems correct at .8321), but no queueing stats

and cannot find any results from that Tally Statistics. Will continue to try.

Still, I find it slow. I have a Javasimulation of an M/M/1 that takes only 4 seconds

to run 1 million customers (=tokens/entities in Simio). Each customer has to be

generated, wait for a resource (seize), delay, release it and ends up in a sink (that tallies).

Same computer.

The javasim has none of the GUI that Simio has, but then, there's no GUI processing overhead in FastForward/experiment mode.

And, the Javasim reports queue and worker statistics (mean, variance).

Perhaps Simio is collecting excessive statistics (if so, can it be turned off)?

Or is it that I made a mistake by adding a Resource1 (to be seized)?

[ASagan]

I am not surprised by your findings.

I would expect an simulation executed entirely in a traditional programming language to be many times faster than a simulation created in a seperate software package.

I'm very impressed that Simio managed 30 seconds compared to 4 seconds for your java simulation. The 4 seconds actually looks slow to me!

[KDanielsen]

Tried free eval version of Csim20, the included console M/M/1 demo. CPU-time reported is 2.5 secs (same computer) for 1M jobs. A bit faster than the Javasim. Csim obviously does book-keeping of all arrival/departure times to show queueing averages, but this can be turned off, which is what I now want to do in SIMIO. Turn on statistics only for specified objects.

[KDanielsen]

Just tried Arena ... 1M jobs completes in 5-6 seconds runtime...

[KDanielsen]

Still hoping to speed up Simio. Any suggestions? I MUST be doing something "wrong"; as described earlier, My (token-optimized) Simio is 6x slower than Arena or my Javasim or my Csim for the M/M/1 running 1 million jobs. My colleagues say "why are you so obsessed with speed"?

[KDanielsen]

[quote="ASagan"

I would expect an simulation executed entirely in a traditional programming language to be many times faster than a simulation created in a seperate software package.

Wasn't Simio written in C#? Any simulator X is written in a "separate software" package Y.

[dsturrock]

My colleagues say "why are you so obsessed with speed"?

I tend to agree with your colleagues.

Simio is probably not the fastest executing product, in part because it has so much built into it that other products don't have. When you do trivial models you don't see that, but when you do "real" models you will.

Computer time is cheap; skilled modeler time is not. If you can do a typical project in 2 weeks in Simio versus 6 weeks with a competing project what is that 4 weeks of time saved worth? What is the benefit of producing answers (and the resulting savings) sooner? And what is it worth to be able to model something accurately that would have been approximated in other products?

To take your assertion from above, what if Simio happened to take 6X (say 60 minutes versus 10 minutes) to replicate that typical project? In the worst case to do 30 reps would take 30 hours of unattended computer time versus 5 hours. Who cares? You are still seeing your results more than 3 weeks earlier with dramatically reduced effort.

Given that Simio can use multiple processors and most competitors don't, on a common quad processor machine there is little difference (8 hours vs 5 hours). And if you take advantage of Simio's ability to use up to 16 external processors, then Simio can actually produce results in less than half the time (2 hours versus 5 hours). All of that is assuming that 6X figure you used is accurate on a real system model - which I tend to doubt.

The point is, as a modeler my top concerns include:

--Can I model the situation accurately enough to generate meaningful results?

--How much skill and effort (my time) does it require to do so?

--How long (calendar time) until I can provide an answer to my stakeholders?

In most applications I feel that Simio provides the best answer to the above questions.

[ASagan]

[quote="ASagan"

I would expect an simulation executed entirely in a traditional programming language to be many times faster than a simulation created in a seperate software package.

Wasn't Simio written in C#? Any simulator X is written in a "separate software" package Y.

I meant programming directly in C#/java would probably produce a much faster package than creating a simulation in a specialized software package.

If you working on simple SSS models, forget all this and just go straight to assembly... (joking)

[KDanielsen]

OK.

Forget programming sims in C/Java.

Arena is a competitor to Simio. Has many of the same advantages as mentioned by Sturrock.

Arena executes 6x faster for M/M/1. They ought to be similar in speed?

I still insist that I must be doing something wrong in the way I set up my Simio experiments.

Just tried something even simpler this morning.

Set up a Source/Create that generates 1 job/hr for

100 years. 876000 jobs.

Jobs go to a Sink/Dispose via a connector/link.

Simio: 53 sec (can be reduced if using tokens)

Arena: 2 sec

?????

[dsturrock]

SSS was used as shorthand for Source-Server-Sink.

Arena is a competitor to Simio. Has many of the same advantages as mentioned by Sturrock. Arena executes 6x faster for M/M/1. They ought to be similar in speed?

Actually no, the difference/advantages I cited were in comparison to products like Arena. Arena does not have objects, it's modules have no intelligence, it's entities are much like Simio tokens, Simio entities are MUCH more sophisticated, Simio has built-in statistics calculations, ... . A process/tokens approach in Simio is the only thing remotely comparable.

Simio objects are so much more sophisticated that REAL systems can be more accurately modeled in Simio in less than half the time. The products are only superficially similar so why would one expect them to execute at the same speed? This is like comparing a car and a jet going 1000' down a runway and declaring the car "faster". But if your journey involves traveling 1000 miles and carrying 100 passengers, I think your conclusion would be much different.

For such a simple problem, I'm sure you could program a solution in assembly code that would run MUCH faster. Why don't people do that? Because it would take too long to build the model and they value their modeling time and time to solution, more than the computer time.

If your study is looking to see how solving a trivial academic problem in different ways can impact execution speed, then you should probably include the assembly code solution. But if your analysis involves any measure of how people solve real problems, then I think you need to start with a real problem and measure all aspects of project performance.

Writing this is rather odd for me because within Simio staff I am often on the opposite site of this argument. I am continually (and successfully) arguing that we should put more time into optimizing Simio to make it run even faster. And in fact, at least quarterly we put significant effort into improving Simio execution speed, so Simio is getting steadily faster. But the other side of this argument is that computers keep getting faster, so the execution speed tends to take care of itself (particularly considering the cloud) and we can better serve our customers by improving the product features to permit even faster and more accurate modeling of real projects.

[KDanielsen]

But if your analysis involves any measure of how people solve real problems, then I think you need to start with a real problem and measure all aspects of project performance.

I get your message, Sturrock.

Simio (current version) cannot run faster.

That was my question.

[dsturrock]

Out of all that discussion, you managed to attribute to me something I didn't even say.

I did give tips above like:

In terms of modeling, the most dramatic improvement you could make is to build your model at a lower level. The model you described is simple to model entirely in a single process with steps:

(begin) - Seize - Delay - Release - Tally - (end)

with the process triggered by a Timer element and using TallyStatistics elements for any token-related statistics like Time In System. You would not even need to create any entities, it could all be done using tokens which are smaller and faster.

The process approach should be many times faster.

and lots more tips here.

But you apparently disregarded that advice when you did:

Just tried something even simpler this morning.

Set up a Source/Create that generates 1 job/hr for

100 years. 876000 jobs.

Jobs go to a Sink/Dispose via a connector/link.

You are obviously not building your test models entirely in processes. Are you using .Net 4.5?

I built the model above the way you did and it took about 7 sec on my computer to run an experiment of 100 years. The process approach to the same model took under 1 sec to run (7 times faster). And of course if you wanted to run multiple replications, up to 16 concurrent replications would still require only about 1 sec (over 100 times faster).

Here is that model:AcademicTestModel.spfx

So, the short answer to your question "Is there something I can do to make Simio run faster?" is YES.

[KDanielsen]

Hmm.

I wasn't disregarding your advice, I think.

The M/M/1 (see post from feb 29, 2012) used process/token, which reduced runtime nicely from 120 to 30 sec.

 

I built the model above the way you did and it took about 7 sec on my computer to run an experiment of 100 years. The process approach to the same model took under 1 sec to run.

I downloaded your model (thank you). I have .NET 4.0.30319. Endtime set to 5200 weeks=100 years. About 873600 entities created/disposed.

OBJECT APPROACH

Your model (named "ObjectApproach") runs in 3 seconds on my computer.

I try to make a similar model myself (Source-Connector-Sink). Mine runs in 53 seconds.

I turn off Statistics for all three objects (Model Entity, Source, Sink). It runs in 51 seconds.

PROCESS APPROACH

I see your code (process steps).

It is exceptionally fast. I run it for 52000 weeks (1000 years). Completed in 10 seconds. So 5200 weeks is 1/10 of that, would take 1 second.

I try to make a similar model. Run it for 52000 weeks. It runs in 10 seconds. Same execution speed as your (relief).

It creates about 8.7 million entities, I think (since there is a Create step). Am I right?

I attach an .spfx-file with your two models and my two models.

Perhaps (when you have time), you can find why my object approach is 10x slower than yours.

AcademicTestModel2.spfx

[dsturrock]

First, if you are not running XP, then I highly recommend updating to .Net 4.5 - this can make a dramatic difference in Simio execution speed.

Second, I made an error in my model - I accidently ran one for 5200 weeks and the other for 5200 days.

Perhaps you did something similar because 3 of the 4 models in your project had different run durations as well.

I fixed that problem and while I was at it illustrated 4 different approaches to this simple model. All had periodic activity every hour for 5200 weeks (100 years). All at least track the number of activities logged (873,601 events) by adding an Integer State, an Assign to that state, and an OutputStatistic to make it display in the results. The approaches vary based on the objects involved. The approaches using objects provide additional statistics. If you run them in the Experiment window you can look to the Pivot Grid to verify results.

 

RunTime    Approach
42 sec     Facility model (Source-Connector-Sink)
13 sec     Process that creates objects (Create-Destroy)
3.2 sec    Process with Tokens (no entity objects) created by Timer
1.7 sec    Process with single Token (no entity objects) that recycles hourly

Sorry for the confusion. I hope this helps.AcademicTestModel.spfx

[KDanielsen]

Thank you.

I probably should/will stop now.

I have learned very much from these last two days (seeing how you code the steps).

But, I did run your most recent four models. And got wild results.

I added a column to your results.

Ketils runtime    | RunTime    Approach
   1,4 sec        | 42 sec     Facility model (Source-Connector-Sink)                        
  20,0 sec        | 13 sec     Process that creates objects (Create-Destroy)
  1,3 sec          | 3.2 sec    Process with Tokens (no entity objects) created by Timer
  1,6 sec          | 1.7 sec    Process with single Token (no entity objects) that recycles hourly

Your facilitymodel (was "objectapproach") still runs VEERY fast.

Recall, mine took 53 seconds, yours took 3 in my previous message.

Was hoping you could elaborate how yours get the 10x faster time?

I also downloaded/installed .NET 4.5.

No change in execution times.

Have to check to see if Simio actually loaded the correct DLL-files,

I am a bit unsure of the way .NET installed (it is an in-place replacement, overwriting

the DLL-files, but keeping the 4.0 version numbering, ...

That's another story ...

[dsturrock]

But, I did run your most recent four models. And got wild results.

Did you run it exactly as I sent it, unmodified? Did you execute it from the experiment window, resetting before each run? Did you have anything else running on your computer? For example in such short runs if your email decided to download a big file it could take processor time.

Recall, mine took 53 seconds, yours took 3 in my previous message.

I believe that was due to the days versus week mistake I made.

[KDanielsen]

But, I did run your most recent four models. And got wild results.

Did you run it exactly as I sent it, unmodified? Did you execute it from the experiment window, resetting before each run? Did you have anything else running on your computer? For example in such short runs if your email decided to download a big file it could take processor time.

Recall, mine took 53 seconds, yours took 3 in my previous message.

I believe that was due to the days versus week mistake I made.

 

1) I ran from the experiment window (no change).

2) I have other programs active, but they don't do anything that hog the cpu.

3) But, could you help me with a small comparison.

Your model "ObjectApproach" runs VEEERY fast on my computer:

Your model has a Source, a Connector and a Sink.

I make the APPARENTLY SAME model "ObjectApproachKetil".

It has a Source (1/hr), Connector and Sink, and 5200 weeks simtime.

I also add a ModelEntity1 for the Source to generate (as DefaultEntity is not an available choice).

I also turn off statistics for all 3 objects (Source, Sink, ModelEntity1). Here is the result:

 

Yours: 1.14 seconds

Mine: 50.8 seconds

I enclose an .spfx. It is a copy of the one you posted most recently, PLUS the fifth model, the aforementioned "ObjectApproachKetil".

In your spare time (?), could you try these two ObjectApproaches (yours vs mine) on YOUR computer, see if you get the same relative difference in runtime?

AcademicTestModel-twoObjectApproaches.spfx

[dsturrock]

In your spare time (?), could you try these two ObjectApproaches (yours vs mine) on YOUR computer, see if you get the same relative difference in runtime?

On my machine both performed identically (about 1.5 seconds). You are not crazy - it's just your computer is playing head games with you.

I cannot explain why they would run different on your machine.

[KDanielsen]

In your spare time (?), could you try these two ObjectApproaches (yours vs mine) on YOUR computer, see if you get the same relative difference in runtime?

On my machine both performed identically (about 1.5 seconds). You are not crazy - it's just your computer is playing head games with you.

I cannot explain why they would run different on your machine.

I downloaded the latest version of Simio.

Now they run at the same speed.

Thanks for all your help, though.

[KDanielsen]

In your spare time (?), could you try these two ObjectApproaches (yours vs mine) on YOUR computer, see if you get the same relative difference in runtime?

On my machine both performed identically (about 1.5 seconds). You are not crazy - it's just your computer is playing head games with you.

I cannot explain why they would run different on your machine.

I downloaded the latest version of Simio.

Now they run at the same speed.

Thanks for all your help, though.

Correction. Just discovered:

They run at same speed (FAST, about 1.3 secs) if I run it as experiment.

In design mode (Fast-Forward), mine is SLOOW, yours stays same (FAST).

Unfair.