Open CyberDuck79 opened 4 years ago
Hello!
Thanks for your issue! I've fixed the installation command and will try to work around the death timing issue.
@CyberDuck79 Hey! It seems that I've fixed the thing with the new release.
Could you please check?
Thanks for your issue once again!
I can't retry on campus before Monday. But I tried at home and I can't test death timing because of performance test on WTF 1ms of delay. Why do that ? even more when your delay test say > than 1 ms on my machine. I just can't succeed and continue the test.
From my tests on a lot of gits the things to test is not absurd performance (with totally random results). The better gits I found in term of performance was totally wrong with high number of philos, for example "in theory" 20 410 200 200 should just work as 4 410 200 200 (but the delay is higher it's true) and most of the gits I tried just died in secondes because they don't launch philos the right way (but yeah ! with 4 philo it's work and it's more optimized !) and it's not perf but deadlock ! the main objective of this exercise !
It seem that you don't test that (or as I can see as test don't continue). Oh and you should check for segfault on program end with high number of philo and meal count. There a LOT of these.
Performance tests are OK but they should not stop the tests and be more diverse, because I do far better (not dying or far later) on high number of philos (and so on a far higher number of cases) but the tests stop because with 4 philos I can't be sure to launch all philo with < 1 ms because of... what I add to be right in all cases. (and even in the correction they don't ask to test < 1 ms !)
You should continue and check if the death is deadlock or delay, because with deadlocks it's SURE you program is wrong. I have no deadlock, I perfectly work with 4 410 200 200 so I don't understand why your program test 4 311 150 150, this misleads people to try to succeed this test but I think it's VERY hard if you take account of high philos number cases AND may leads people to not test deadlocks (because with 4 your test is OK).
With small number of philos (4) I don't know why but it always (or near) launch philo the right way even if you launch them the wrong way (1,2,3,4) -> 1 and 3 take forks first but in theory it's not guaranteed at all ! and it do when > 4 ! To be right you should launch even -> odd (or inverse) and be sure they are launched in right order (not guaranteed at all without mutex !). I see nobody do that but they died when they should not without that.
Oh and why your odd test is 5 600 150 150 ? It should be 5 451 150 150 to be same as 4 311 150 150, the delay with 5 600 150 150 is 50 ms ! I think that 4 320 150 150 and 5 460 150 150 are ok to test "good enough" perf. Or you can use you DELAY-O-METER results to tweak tests because it's absurd that the program tell you that you machine can't succeed the test (more than 1 or 2 ms delay) and... test it.
Hey @CyberDuck79,
Thank you very much for your input!
I'll try to answer each of your major points.
But I tried at home and I can't test death timing because of performance test on WTF 1ms of delay.
I don't understand what are you referring to. I've added a sleep accuracy test in the last release, and the only thing it does is trigger a warning (that stays on the screen for 5 seconds).
Sorry if it lead you to believe that tests won't be run. I will try to add a more clear indication that this is merely a warning, and it is for you to decide if a machine is able to handle philosophers.
The better gits I found in term of performance was totally wrong with high number of philos, for example "in theory" 20 410 200 200 should just work as 4 410 200 200
Great idea! I agree that this is a good test to run on someone's project. However, I'm not sure if I should include tests with >10 philosophers by default, because in my understanding it may fail for no reason on a slow machine. You can always configure the tests or do the tests manually, though.
you should check for segfault on program end with high number of philo and meal count.
Sounds cool! I'll try to add that (if you have some time on your hands, please feel free to add a pull-request).
Performance tests are OK but they should not stop the tests...
If you're talking about delay-o-meter, it already isn't doing that (but is probably not clear about that, sorry!). If you mean that tests should carry on even if one of them is failed, maybe a good point. But wouldn't it waste time?
... Performance tests are OK but they should not stop the tests and be more diverse, because I do far better (not dying or far later) on high number of philos (and so on a far higher number of cases) but the tests stop because with 4 philos I can't be sure to launch all philo with < 1 ms because of... what I add to be right in all cases. (and even in the correction they don't ask to test < 1 ms !)
Are you sure it is a good thing? In my opinion, both 4 and 20 philosophers are a decent and reasonable test case on a normal machine. I don't think that Socrates in its current state demands a precision of <1ms. "4 311 150 150" means less than 11 ms of delay per eat-sleep-think cycle, doesn't it? Please correct me if I'm wrong about this.
I perfectly work with <...> so I don't understand why your program test 4 311 150 150...
My understanding is that 4 311 150 150 is numerically equal to the test that you mention (150 + 150 = 300; 300 + 10 +/- 1 = 311). Again, please correct me if I'm wrong. I am also trying not to incentivise people to optimise for a given test. It is also probably a good idea to randomise the numbers to achieve the same goal.
... this misleads people to try to succeed this test but I think it's VERY hard if you take account of high philos number cases ...
I'm not sure about that. Are you sure that it's impossible to pass both 4 311 150 150 and 20 311 150 150? I've seen a couple projects accomplish that.
Oh and why your odd test is 5 600 150 150 ?
I looked at a very common test (if you know what I mean) which had exactly the same logic, time to die was 2 times time_to_sleep + time_to_eat for 5 philos.
Or you can use you DELAY-O-METER results to tweak tests because it's absurd that the program tell you that you machine can't succeed the test (more than 1 or 2 ms delay) and... test it
Sounds great! It is now only issuing a warning because at the moment I'm not sure of its real value. It is still arguably better than nothing but I totally can't say it's an absolute measure of philosopher-worthiness of a machine.
Once again, thank you very much for your comment! The main points I carry out of it are to test deadlock (for instance, with 2 and 20 philos, maybe 20 philos for a shorter time or something) and to be more clear with delay-o-meter. I will totally try to incorporate this, and will absolutely appreciate your pull-requests or any other comments.
YEP MY BAD, 150 + 150 = 300 ^^' So it's ok with delay-o-meter, it give a look at machine perf and as you say you can change test values easily.
So it OK, even more that it seem it was on my side but I'm not sure as there a lot of randomness (is it because I was doing something else on my computer ?...), I will share my results later but for now, even with the same delay, 311 150 150 seem a little harder than 420 200 200 but don't know why. EDIT -> It is really randomness, I even succeed 20 311 150 150 like you said.
And same for odd number of philo, I still think it is possible to not die with just 3*time to eat (because if it was not the case my tests would not do more than 1 "table turn") but my bad even my program does not succeed 3x40 secs with 460 tt_die (seem to deadlock -> even more convince that delay is OK).
So thank you for your work ! ;)
Oh and your delay-o-meter is right, my tests fails when "bad luck" I hit the "peak delay" 2 times in a row (for me ~5.7ms). So I think you can tweak the tests values like that: tt_eat and tt_sleep -> 150 is OK tt_die -> tt_eat + tt_die + (2 * peak_delay_ms) (+ 1 to be sure ?) like that you can make another test with 8/12 philos with a little larger tt_die, the important thing being sure that it do not deadlock regardless of performance. Deadlock are more about if forks are correctly assigned and/or philos correctly launched, some more ms in tt_die is OK if computer have a very bad peak delay.
Hello guys ! great work but two issues:
for the installation command line in 42:
python3 -m pip install psutil --user
and notpython3 -m pip install psutil -user
And death timing doesn't work for me in the school. However my printing is good:
00000000001 3 is eating
the logs: