Sleeping Barber benchmark slowing on large inputs

[ith8]

I am working on benchmarks for the C target. Barber.lf has trouble running on my local machine when I increase the problem size to over 1000 customers. For instance, I was able to run a smaller input size of 500 customers and finish within a few seconds:

191 | main reactor Barber(cut_time:time(1 nsec), num_chairs:int(100), num_customers:int(500)){

But when I increase the parameters num_customers or num_chairs, the compiled program just hang and does not terminate even after 10-20 minutes.

191 | main reactor Barber(cut_time:time(1 nsec), num_chairs:int(100), num_customers:int(1000)){ 

[cmnrd]

Interesting! At first, I thought this is related to #433, but it seems that not the slow compilation process is the issue here, but that there is a problem in the generated C code or the C runtime.

[edwardalee]

I have determined that there is a deadlock associated with tracing. If you turn off tracing, this benchmark runs in 42 msec with 100 chairs and 1000 customers. Compile time is several minutes, however.

Tracing should always be turned off for benchmarks, except perhaps when debugging the benchmark or analyzing it for performance issues, but even in the latter case, probably it needs to be much smaller than this for tracing to be useful.

Still, there is a deadlock bug with tracing. We need to chase that down.

[cmnrd]

Closing this as I think the initial issue is resolved. I opened #634 and #635 to follow up.

[edwardalee]

Barber.lf has disappeared. Where can I find it?

[lhstrh]

It was moved here in 478291f

[edwardalee]

OK, I guess it's not in master. 478291f seems to imply it's in benchmarks. I get this:

EALMAC:src eal$ git checkout origin/benchmarks
Note: checking out 'origin/benchmarks'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 478291f38 move sleeping barber to examples and remove cog
EALMAC:src eal$ git branch
* (HEAD detached at origin/benchmarks)
  master

Being in a "detached head" state seems kind of disconcerting, but what the hey, this is git (not Eclipse, the favorite whipping boy). If I follow the instructions in the above message:

EALMAC:src eal$ git checkout -b origin/benchmarks
Switched to a new branch 'origin/benchmarks'
EALMAC:src eal$ 
EALMAC:src eal$ 
EALMAC:src eal$ git status
On branch origin/benchmarks
nothing to commit, working tree clean
EALMAC:src eal$ git branch
  master
* origin/benchmarks
EALMAC:src eal$ pwd
/Users/eal/lingua-franca-master/git/lingua-franca/example/C/src
EALMAC:src eal$ ls
Deadline.lf			MQTT				ReflexGame.lf
Delay.lf			Patterns			Rhythm
DistributedDatabase		ProtocolBuffers			RockPaperScissors.lf
DistributedHelloWorld		ROS				Smokers.lf
DistributedResourceManagement	ReflexGame			TrainDoor

Note that I am now on a local branch and there is no SleepingBarber.lf.

[Soroosh129]

The detached state is because you are checking out an origin (remote) branch.

Using the following should resolve this issue:

git fetch --all # Fetch all the remote branches
git checkout benchmarks # Switch to the local version of the branch

[lhstrh]

@edwardalee is using a very old version of Git that doesn't have the switch command...

Just checking out master, doing a git fetch --all and git checkout benchmarks should also do the trick. I'm not even sure the first step is necessary.

[Soroosh129]

In that case (by creating a local origin/benchmarks branch) @edwardalee's local git repo should be back into an (attached?) stable state, so the first line is not needed at all. I removed it.

[edwardalee]

Guess we should add this to the Oomph instructions, since you really have to do this every time you do a fresh checkout... Unfortunately, git now thinks I've modified about 30 files that I haven't touched so it won't let me switch back to master... This git personality is quite creative...

[Soroosh129]

This git personality is quite creative...

Well, it's Linus Torvalds' pet project that people have latched onto for some reason...
He's like the Elon Musk of open-source software in that regard.

[lhstrh]

BTW, AFAIK, if you do a normal git pull, the default behavior is to fetch all and merge/rebase the current branch based on what was fetched; the other branches are also fetched and you can switch to them using the git switch or git checkout command. The error here was to try to switch to a remote branch.

Git is a rather powerful tool with very good documentation, like most GNU tools. Git might not always to what you expect, but in situations like these, I have always found it was me not having read the docs, never Git doing something wrong or being unstable.

[lhstrh]

Guess we should add this to the Oomph instructions, since you really have to do this every time you do a fresh checkout...

Not sure I understand: what does this issue have to do with Oomph?

Unfortunately, git now thinks I've modified about 30 files that I haven't touched so it won't let me switch back to master... This git personality is quite creative...

Which files? If I had to guess, the files were changed by another tool, and perhaps these files belong on a .gitignore list?

[lhstrh]

This git personality is quite creative...

Well, it's Linus Torvalds' pet project that people have latched onto for some reason... He's like the Elon Musk of open-source software in that regard.

Ugh, the comparison between Elon Musk and Linus Torvalds is about as far-fetched as the comparison between Git and Eclipse.

Also, good luck trying to git blame Linus for anything in Git; https://github.com/git/git/graphs/contributors

[edwardalee]

The SleepingBarber.lf that is now in example/C/src in the benchmarks branch is not an example. Running the program does nothing (no output) and if I uncomment the printf statements, it is way too big to be an example.

[cmnrd]

I moved it to the new location, because this is what we decided in the discussion of #401. Please feel free to extend the program so that it becomes more accessible as an example.