Not interested in new proposals right now, thanks.
  • А вы реально все эти сыры едите?

    Мимолет или массадам, на бутерброды. Маасдам можно с колбасой и он не так сильно растекается на горячих бутерах, но совсем не подходик к макаронам. Мимолет сам по себе с очень выраженным вкусом, неплохо подходит к макаронам.

    Для макарон чаще покупаю Старый голландец, по-моему он не хуже пармезана, но гораздо более универсальный — его можно есть и просто так.

    Еще Дружбу вкусно делать с давленным чесноком, вареным яйцом и добавлением немного майонеза для связки.

    Поддержал: Alex Fogol
  • Прозвон номеров (мошеничество?)

    Вариант из личного опыта — ребенок закрыл жену в подъезде, чтоб не мешала мультики смотреть. Жена звонит с чужого номера, просит привезти ключи от квартиры.

  • Последний апдейт Windows 10 «окирпичивает» машины

    Так это не я, это обновление драйверов.

  • Последний апдейт Windows 10 «окирпичивает» машины

    Ага,

    rm -rf /usr /lib/nvidia-current/xorg/xorg
    © Nvidia
    Поддержал: Oleg Korol
  • Рейтинг аргументов отказов работодателей платить высокую зарплату

    Разве это не политкорректный способ дать понять, что они не хотят говорить о настоящей причине отказа?

  • Speedup memcpy

    ну, т.е. не „impossible”, конечно, мы ж специалисты. А что-то вроде „we have to decrease accuracy by 30% in order to speedup by 10%”. Но суть та же.

  • Speedup memcpy

    Я такого не видел, могу только спросить, это примерно так?

    — we need performance improvement by 10%
    — [click-click-click (160h elapsed)] unfortunately, it’s impossible, but we managed to improve it by 1.0%

    По аналогии с:
    — Люся, я люблю тебя с 8го класса, выходи за меня!
    — а я тебя нет, но знаешь, я срадостью буду дружить с тобой и напоминать о себе следующие 50 лет!

  • Speedup memcpy

    Есть aligned версии инструкций, они быстрые и падают

    о, спасибо.

    Поддержал: Denys Poltorak
  • Speedup memcpy

    такой же, как с -Ofast, но с -O0. Только в чтении проще. Или мы больше не оптимизируем дебажный код?

  • Speedup memcpy

    С тем, что скилы нужны — я не спорю. И хорошее самувствие, и ответственность, и внимательность :) Но на практике то, что «надо» и то, что «есть» иногда отличается и я считаю, что хороший код в случае таких несовпадений должен как минимум ругаться плохили словами в дебаге.

    Вопрос был в том, стоит ли игра свеч, когда усложнение кода ценой выигрыша в пару тактов повышает риск ошибок по невнимательности.

  • Speedup memcpy

    Почему? А если невыравненный dst попадёт на границу кеш-лайна, то потери будут такие, что неоптимизированный побайтовый копи будет быстрее.

    Потому, что это не возможно в общем случае. А усложять код с надеждой на везение и «выравниваемую» ошибку по-моему нет смысла.

    Либо пользователь вызывает метод правильно и все у него работает быстро, либо — неправильно, и в этом случае есть смысл в отладке вывалиться на assert(), а в релизе — работать, но медленно.

    Данный SSE код точно не будет работать тихо и неправильно, оно упадёт.

    Если упадет, то норм. Но почему упадет? Насколько я помню, SIMD на x86 вполне себе переваривают невыровненные данные, но делают это намного медленнее.

  • Speedup memcpy

    о, там должно быть деление, это мой фейл. Что в очередной раз подчеркивает, что не надо так писать — экономия пары тактов до того, как войдем в цикл на тысячи тактов (если без промахов по кешу) или с сотнями тысяч при промахах?

    Это оптимизация по результатам профайлинга? Если да, то на сколько ускоряет код?
    Если нет — то какого, собственно, мотива, мы оптимизируем с ухудшением читаемости кода до того, как убедились, что это улучшит результат?

  • Speedup memcpy

    и который никто не будет поддерживать. Или когда пофиг, кто там и как будет его поддерживать. Тогда не вопрос.

  • Speedup memcpy

    простейший вариант выглядит так:
    if(0 != ((src | dst) & 0x3F)) memcpy(/*std::memcpy*/); else { ... }
    еще можно сначала скопировать минимум байт по одному до границы выравнивания, затем скопировать ту часть src, которая идеально выровнена, и потом отдельно по одному докопировать байты после дальней границы выравнивания. Универсально и не сложно.

    Можно добавить assert().

    Можно переименовать.

    Под невыровненный dst ничего оптимизировать не надо. Но вот чего точно не надо делать — это код, который будет работать тихо и не правильно.

  • Speedup memcpy

    но мы ведь про умножение на 8 говорили, а не как написать максимально быстрый некорректный код, да?

  • Speedup memcpy

    да, но c if-ом и маской код будет будет отрабатывать на пару тактов медленнее, чем в контексте копирования мегабайтов в памяти можно и нужно пренебречь. А вот тем, что в функцию можно передать невыровненный указатель и тем, что работать в этом случае код будет непредсказуемо — я бы пренебрег только если это fixed-price write-only код

  • Speedup memcpy

    Да ну? И в чем смысл?
    Скрин: piccy.info/...​a9da83d6891aa504bc6/orig

    Забавно то, что в «оптимизированном» примере — деление, а с делением действительно отработает быстрее в 64 раза, тут не поспоришь.

  • Speedup memcpy

    Только в случае, если данные не выровнены, наверное, в обоих вариантах есть смысл сначала докопировать недостающие до выравнивания байты вручную по одному?

    На скорость это не повлияет, на фоне копирования 3 мегабайт данных, зато гарантирует остутствие трудноповторимых багов в процессе использования.

  • Speedup memcpy

    Умножение путем сдвига выполняется по религиозной причине, или в данном случае в этом есть какой-то смысл?

  • Верят ли программисты в Бога?

    Это вы еще не задумывались о том, что на самом деле делают переводчики: https://www.youtube.com/watch?v=kUDpYvXqoYU

← Сtrl 123456 Ctrl →