Closed ith8 closed 3 years ago
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.
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.
Closing this as I think the initial issue is resolved. I opened #634 and #635 to follow up.
Barber.lf has disappeared. Where can I find it?
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.
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
@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.
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.
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...
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.
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.
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?
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
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.
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.
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:
But when I increase the parameters
num_customers
ornum_chairs
, the compiled program just hang and does not terminate even after 10-20 minutes.