Сообщение Re[7]: о0 от 31.05.2015 14:17
Изменено 31.05.2015 14:23 Sheridan
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Sheridan, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи?
S>>>>Даже я считаю, что в итоге осилят.
V>>>Ну тыж не программист чтобы так считать?
S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Ф>Шеридан!
Ф>Я с многопоточностью воюю уже лет семь, наверное.
Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Ф>Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Я в курсе, что это сложно. Так же я в курсе, что это вполне осуществимо, хотя и сложно.
Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Ф>Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Я нигде не писал, что это легко.
Ф>А ты сам-то способен "писать многопоточно"?
Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает. И да, пока что это потоки, которым как правило не нужно обмениваться данными.
Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая от скрипта, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности. Ну, и чтото многопоточное есть и там.
Ф>Здравствуйте, Sheridan, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи?
S>>>>Даже я считаю, что в итоге осилят.
V>>>Ну тыж не программист чтобы так считать?
S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Ф>Шеридан!
Ф>Я с многопоточностью воюю уже лет семь, наверное.
Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Ф>Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Я в курсе, что это сложно. Так же я в курсе, что это вполне осуществимо, хотя и сложно.
Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Ф>Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Я нигде не писал, что это легко.
Ф>А ты сам-то способен "писать многопоточно"?
Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает. И да, пока что это потоки, которым как правило не нужно обмениваться данными.
Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая от скрипта, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности. Ну, и чтото многопоточное есть и там.
Re[7]: о0
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Sheridan, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи?
S>>>>Даже я считаю, что в итоге осилят.
V>>>Ну тыж не программист чтобы так считать?
S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Ф>Шеридан!
Ф>Я с многопоточностью воюю уже лет семь, наверное.
Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Ф>Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Я в курсе, что это сложно. Так же я в курсе, что это вполне осуществимо, хотя и сложно.
Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Ф>Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Я нигде не писал, что это легко.
Ф>А ты сам-то способен "писать многопоточно"?
Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает. И да, пока что это потоки, которым как правило не нужно обмениваться данными.
Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая скриптом, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности. Ну, и чтото многопоточное есть и там.
Ф>Здравствуйте, Sheridan, Вы писали:
S>>>>Ты считаешь, что программисты НАСТОЛЬКО плохи?
S>>>>Даже я считаю, что в итоге осилят.
V>>>Ну тыж не программист чтобы так считать?
S>>Ты хочешь сказать, что программисты настолько тупые, что неспособны писать многопоточно?
Ф>Шеридан!
Ф>Я с многопоточностью воюю уже лет семь, наверное.
Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Ф>Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Я в курсе, что это сложно. Так же я в курсе, что это вполне осуществимо, хотя и сложно.
Так или иначе, но многопоточность придется использовать, иначе это сделают ваши конкуренты
Ф>Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Я нигде не писал, что это легко.
Ф>А ты сам-то способен "писать многопоточно"?
Ну, пока что получалось. Я совершенно не мегакрут в этом вопросе, но везде гле прикручивал многопоточность — везде работает. И да, пока что это потоки, которым как правило не нужно обмениваться данными.
Как правило это всевозможные скрипты, начиная от рекурсивного обхода сетей с подсетями и заканчивая скриптом, снимающего по 1 кадру раз в 30 секунд с нескольких камер в отдельности. Ну, и чтото многопоточное есть и там.