-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M/M/c model way too slow #1
Comments
Hi, The problem is the sampling rate. It is calculated in You can fix it now if you do
More realistically would be to model the server as a process, taking the next customer immediately after becoming idle without waiting. Furthermore I would implement the queue as a I will open an issue on that problem over at |
Thanks. I will see if I can figure out how to use a channel as you recommended. I might retain this model to see how it compares to the channel approach. The preliminary results (with the incorrect temporal resolution) suggest that this model is much slower (about 200 times slower) than the same model in SimJulia. |
This is interesting. There are several ways how the I can confirm that it is slower, albeit not 200 times:
the files are in There we can improve and compare the approaches. |
I don't have the ability to check at the moment unfortunately. It's possible that the discrepancy in benchmarks is due to the number servers and customers I used. I think I used 100 and 10,000 respectively before I decreased the values for validation. |
Ok. I had the opportunity to run a benchmark. The problem here is poor scalability.
|
Now I did the exact analog to the
The file is On writing this I realised that the customers are created before running the simulation. This is not fair enough. Customers (arrivals) should be created during a running simulation. |
I adapted your code to run the same benchmark. Unfortunately, the results were very similar (although slightly better): |
This is tremendous 😰. There are two problems for the
I will test those hypotheses one by one tomorrow. |
Now I did the following:
The benchmark #2 then comes out as follows: As you see there is a big improvement. So the above slowdown is likely due to the Julia scheduler. Still the simulation is slower than the Interestingly I couldn't gain anything if I only moved the first model to thread 2 (benchmark #1). Still the task queues are too long. I hope that anytime soon those problems with the Julia scheduler will be improved. |
DiscreteEvents
than SimJulia
DiscreteEvents
than SimJulia
Great work! As far as I can tell, SimJulia uses a priority queue to manage a resource. Do you think this is the reason for the performance difference and the fact that it can front load all of the customers? |
This is not the problem. In our example servers are seen as resources and there are only two of them. But in a sense you are right: In But remaining native Julia has multiple advantages in being versatile to express simulation problems and - as you see - if you do the right thing, you can also be pretty fast. I am rewriting the documentation and examples in BTW and IMHO creating the customer/process queue beforehand is not the best thing to do and feasible only for simple examples.
|
That seems like a reasonable course of action. In fact, it looks like benchmark 3 is faster than SimJulia. Perhaps the reason is that the arrivals are distributed throughout the simulation rather than all at the beginning. Please feel free to use my implementation as an example of poorly written code. I think it will be instructive for others =) |
My main point here is modeling approaches. There are various ways to express a simulation problem in For practical purposes speed does mostly matter
Those are mostly uncharted territories for simulation systems, which I hope to open further with |
updating documentation see also issue #1
Now the next step: modeling the servers instead of the customers eliminates most of the task setup needed for generating a task for every customer. Instead the next model ( The server benchmark comes out as: It is yet faster than benchmark #2 (modified model). Can this be improved by moving it to another thread as before? The server benchmark on thread 2 ( It now takes about 30 ms for 4000 customers. Clearly the model matters a lot for speed. |
Now it would be interesting to see if you can speed up similarly the model in |
This is interesting. Tomorrow I will have time to study your examples in more detail. I will try to make a similar model in SimJulia. |
Now I wanted yet to add another activity-based solution. This model doesn't work with processes/tasks but only with event-scheduling. Thus there is no task-switching and no intervention of the Julia scheduler. The activity based model bench_queue_mmc_act.jl gives the following results: It takes about 60 ms for 4000 customers, longer than the last model since it checks conditions with clock sampling. But it is still pretty fast. |
I'm having trouble trying to make an analog of bench_queue_srv.jl in SimJulia. I'll have to dig into the documentation to see if it is possible. |
I think you could implement the customer queue as a Unfortunately documentation doesn't seem one of the strengths there 🙁. |
Thanks for the suggestions. Unfortunately, sometimes code itself is the only documentation. I will have time to look into this periodically throughout the week. |
Hi pbayer-
I am trying to implement the queue model in DiscreteEvents. One problem I have run into is that I don't know how to enforce a first come first served wait policy. In the example below, there are 10 customers and 2 servers, which process one customer at a time. Each customer arrives in succession and must wait if no servers are available. As you can see, customer 3 waits for either 1 or 2 to finish. However, when customer 2 finishes first at 1.735, customer 3 continues to wait and customer 4 eventually arrives and takes the available server. Eventually customer 3 finishes at the very end.
Is this a bug or am I doing something incorrectly?
The text was updated successfully, but these errors were encountered: