0xd34df00d
17.12.2012 19:24 Azoth_primary
Что дешевле — при проходе по строке и преобразовании символов тупо безусловно обновить содержимое строки (std::string), или проверить, равен ли новый символ старому, и обновлять только тогда? Ну, соображения CPU cache, COW и все дела.
Бенчмарки делать лень.
безусловно быстрее будет, явно
Что?
+1/
экспертное-мнение-с-дивана.jpg
ти недолугий чи дурний просто, га?
Блядь, ты опять набухался шоле?
нет. Ты сам-то в глаза не долбишься? Что в /1 непонятного, зачем переспрашивать?
>Бенчмарки делать лень.
>Бенчмарки делать лень.
>Бенчмарки делать лень.
Скорее всего, бранчинг будет дороже. (диван-кун).
Хули ты так отвечаешь на вопрос с «или», мудила
?
О, спасибо, первый разумный довод (хотя неочевидно).
> безусловно обновить ... или проверить
> или
> безусловно быстрее будет
ебать ты слепой
Блядь, с каких пор цитату и референс не заковычивают или не отмечают нормально? Мудак ты ебаный.
такое же мнение // а дедфуд не понимает
какая нахуй цитата блядь? если меня спросят «лимон или томат?» — мне ответ тоже в кавычки заключать?
Да.
не мог моар покормить блджад. Плохой дедфуд.
Сломался // на самом деле, у меня просто кофе кончился.
Руководствуюсь pipeline-приспособленностью архитектур вроде x86.
> Бенчмарки делать лень.
ну заебись теперь
блджад, ну по-моему, даже дедфуду должно быть очевидно, что store — это быстрее, чем compare + conditional jump + store (которые без иных предположений будут выполняться в большинстве случаев, кроме ~1 из 256). Учитуя, что затраты на поддержку cond jump чуть ли не выше от экономии на одном store (который почти всегда будет в кеш из-за последовательного доступа к строке) — ответ станет очевиден даже магогу, даже аллаху.
Но чем теоретиков слушать, лучше пошёл бы да измерил.
store там unlikely.
А что там с кешем, я хуй знает, недостаточно в CPU шарю.
в смысле unlikely? функция трансформации редко меняет символы что ли? так это ж блядь уже другой вопрос совершенно.
Хотя ответил бы я на него так же. Это явно не та оптимизация, которую надо делать софтварно.