АК
Мне нрав наблюдать как он себе жизнь усложняет каждый раз и экономит на спичках.
ты сначала напиши свой полуторапоточный мморпг сервер, а потом поговорим
Size: a a a
2020 April 24
VD
ты сначала напиши свой полуторапоточный мморпг сервер, а потом поговорим
Хмм, звучит масштабируемо.
RM
ты сначала напиши свой полуторапоточный мморпг сервер, а потом поговорим
Не всегда многопоточная реализация быстрее однопоточной, в большинстве случаев - просираешь железо впустую
RM
Как то читал, что 80% времени программа ничего не делает
АК
Не всегда многопоточная реализация быстрее однопоточной, в большинстве случаев - просираешь железо впустую
именно так, могу сказать и обратно - не всегда однопоточная реализация быстрее многопоточной, в большинстве случаев - просираешь неиспользуемые ресурсы
RM
именно так, могу сказать и обратно - не всегда однопоточная реализация быстрее многопоточной, в большинстве случаев - просираешь неиспользуемые ресурсы
Неиспользуемые ресурсы можно выделить чтоб держать другие сервисы, этот вариант куда лучше, чем просирать железо в холостую
RM
Переходить на многопоточность нужно только тогда, когда однопоточная реализация перестанет справляться с нагрузками я считаю
АК
Неиспользуемые ресурсы можно выделить чтоб держать другие сервисы, этот вариант куда лучше, чем просирать железо в холостую
в случае, когда тебе хватает одного потока, конечно
VD
Для серва мульти тред — мастхев. Вот зайдёт на серв 15к рыл вместо 10к и что тогда пытатся каждый раз выжать ещё оптимайзя на спичках?
RM
Для серва мульти тред — мастхев. Вот зайдёт на серв 15к рыл вместо 10к и что тогда пытатся каждый раз выжать ещё оптимайзя на спичках?
Мое стремление к оптимизации никак не связано с тем, что я пишу, я всегда был помешан на оптимизации
АК
Переходить на многопоточность нужно только тогда, когда однопоточная реализация перестанет справляться с нагрузками я считаю
а кто спорит? вопрос в том, что бездумно написанное приложение, работающее в один поток, которое изначально не проектировалось под многопоток, переписывать крайне затратно
IL
Переходить на многопоточность нужно только тогда, когда однопоточная реализация перестанет справляться с нагрузками я считаю
Просто интересуюсь. А если ты захочешь прикрутить многопоточку к своей готовой системе, ты сможешь это сделать без переписывания значительной части кода?
Е
Просто интересуюсь. А если ты захочешь прикрутить многопоточку к своей готовой системе, ты сможешь это сделать без переписывания значительной части кода?
omp parallel for
VD
omp parallel for
)
RM
Просто интересуюсь. А если ты захочешь прикрутить многопоточку к своей готовой системе, ты сможешь это сделать без переписывания значительной части кода?
Да, я писал код так чтобы все проекты имели общий интерфейс, так что замена кода в одном проекте делает это для всех остальных решений
AB
Переходить на многопоточность нужно только тогда, когда однопоточная реализация перестанет справляться с нагрузками я считаю
Или когда задача позволяет увидеть места лля параллелизма
RM
Artöm Bakri Al-Sarmini
Или когда задача позволяет увидеть места лля параллелизма
Тоже верно, если какой нибудь большой массив, то почему бы не использовать возможности С++, к примеру, тот же for_each с распараллеливанием, но это лишь параллелизм, не думаю, что это можно назвать многопоточным приложением
TS
Пойду обновлюсю до 10го ведра
Прикольное ведро
EU
chenglong
I
На cppref в методе .erase для хеш карты сказано, что удаление по pos имеет константную сложность, а по ключу - средний случай, что значит средняя сложность? Там указано что эта сложность равна одному вызову a.count(key), я правильно понимаю? По сути разница между удалением по pos и ключу в производительности нет, разве что вызов count метода
Ну, как бы, хеш таблицы могут быть сделаны бакетами, корзина и. То есть, у тебя в ячейке массива про хешу, хранится список или что то подобное. Чтобы в нем найти элемент, надо дефолт но, пройти из начала в конец.