5 ms·

>"Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time." The fact that Mozilla c

by FpUser 3y ago

>"Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time." The fact that Mozilla can not do a particular thing in particular way has zero value for others not in the same boat. I am not Mozilla. Do not know their problems and do not care. Maybe parallel CSS is too complex by nature. I can only relate to my own situation. My commercially deployed systems work and serve bazillion of clients with no problems.

sunshowers 3y ago
What weight do you assign Mozilla's data point? It isn't rational to say zero, is it? Also consider that Chromium still doesn't have a parallel CSS engine -- my understanding is that they tried and failed as well. I've also written systems in Rust, some embarrassingly parallel and some that are more complex than that. The embarrassingly parallel ones never took more than 10 minutes of effort to do. The more complex ones are harder but still possible. I agree that your data point should also be assigned non-zero weight.
- FpUser 3y ago
  >"It isn't rational to say zero, is it?" It is well above zero. But this is for very specific situation - parallel CSS. I on the other hand had never had problem managing / mutating state in my multithreaded programs. I did have one situation with deadlock when interacting with Directshow signal processing. That was around 2002 I think. Took me one day to analyze and fix the code after the bug was reported. But Directshow is an incredibly complex piece with some weird behaviors. Other then that I do not recall any real problems. Btw that particular software was desktop application and written in Delphi, not even C++. So yes to me the opinion of Mozilla's team is totally irrelevant. It is of course totally mutual but I suspect that my situation - C++ application servers is way more common than parallel CSS.
  - sunshowers 3y ago
    Your original assertion was: > Multithreading is just as "relatively" easy in other compiled languages. Maybe that is true for your case, but broadly speaking it isn't true.

by FpUser 3y ago

sunshowers 3y ago

What weight do you assign Mozilla's data point? It isn't rational to say zero, is it? Also consider that Chromium still doesn't have a parallel CSS engine -- my understanding is that they tried and failed as well. I've also written systems in Rust, some embarrassingly parallel and some that are more complex than that. The embarrassingly parallel ones never took more than 10 minutes of effort to do. The more complex ones are harder but still possible. I agree that your data point should also be assigned non-zero weight.

FpUser 3y ago
>"It isn't rational to say zero, is it?" It is well above zero. But this is for very specific situation - parallel CSS. I on the other hand had never had problem managing / mutating state in my multithreaded programs. I did have one situation with deadlock when interacting with Directshow signal processing. That was around 2002 I think. Took me one day to analyze and fix the code after the bug was reported. But Directshow is an incredibly complex piece with some weird behaviors. Other then that I do not recall any real problems. Btw that particular software was desktop application and written in Delphi, not even C++. So yes to me the opinion of Mozilla's team is totally irrelevant. It is of course totally mutual but I suspect that my situation - C++ application servers is way more common than parallel CSS.
- sunshowers 3y ago
  Your original assertion was: > Multithreading is just as "relatively" easy in other compiled languages. Maybe that is true for your case, but broadly speaking it isn't true.