Performance may be improved by reading tracefile in large blocks.

[aarontabor]

The throughput of the simulator may be further improved by optimizing the way we read the tracefile in. Currently, the tracefile is being read line-by-line, which would generate a system call for every line of the file.

Reading could be improved by reading a block of the tracefile into a buffer, and then parsing lines from the block. A system call would only need to be generated after an entire block had been processed.

[aarontabor]

The idea for this came from noticing the significant difference in throughput when running a simulation in an environment with a physically mounted drive compared to one where the drive was mounted through the network.

[marceldombrowski]

How about we spawn a thread that constantly reads from the tracefile and places the commands in a queue for the simulator (a la producer/consumer)?

[aarontabor]

Ya, that could work! I have already tried a couple of things without much luck:

• Read blocks of file into a buffer (as suggested in the initial description)
• Converted tracefiles to a binary format, then read in a blokc of binary lines (this eliminated the need for string processing)

@marceldombrowski I'll take a shot at doing it producer/consumer too.

[marceldombrowski]

We have been talking quite a bit about parallelizing our simulator in the past, that could be a good start. Afterwards we should figure out how we can parallelize the actual simulation steps (e.g. what consecutive tracefile operations can be done in parallel).

[marceldombrowski]

I just finished the producer/consumer thread for the tracefile reading. In my tests I was able to speed up a particular tracefile from 80s to 25s (speedup of 3.2) just by having a thread handling the file I/O. I have to do some cleaning up in the code and will then push it to my branch for testing before we push it back to master. Also, I removed almost all the warnings from the code, so we should continue from my branch. Can anybody run some tests on my code (as soon as it's published) so that we can push it back to master?

[aarontabor]

@marceldombrowski let me know when you push your changes, and I can test them as well.

[marceldombrowski]

Pushed into 8d1f635 please test.
If my changes are tested and working please push back to master and close this issue.

[marceldombrowski]

Just realized that something is now broken with the retrieval of the tracefile line in Simulator::doNextStep()

[marceldombrowski]

Just fixed the issue in 05d9b46. The reason why it wasn't working was because of a race condition within the producer/consumer and because I overwrote data. The latter was easy to fix. The former was fixed by introducing a mutex for the producer and consumer, so that both do not operate on the data at the same time. The current implementation is slower than without multithreaded, I'll look into boosting the performance on it when I have some spare time.