Я не «догадываюсь», а знаю что
1. в Intel Compiler даже по умолчанию включены некоторые SIMD оптимизации (автоматичекая векторизация например)
2. настройки оптимизации Release весьма далеки от настроек по-умолчанию (кстати, список ключей в студию).
Хотя знать тут вовсе не обязательно, можно и догадаться что 6-ти кратный прирост производительности без SIMD оптимизаций в этих тестах просто не возможен.
И об этом надо было писать статью? Без специалистов Intel мы бы конечно никогда не догадались включить оптимизацию в компиляторе. А то что SSE инструкции быстрее FPU вообще за гранью нашего понимания.
А как на счет разобраться и объяснить почему в тестах sinf, expf и logf ускорение в 6 раз, когда наивно можно предположить в только в 4 раза?
Такое ощущение, что у вас в Intel статьи заставляют писать в качестве наказания, поэтому большая их часть получается рекламной водой высосанной из пальца.
Краткое содержание сегодняшней статьи: компилятор Intel использует по-умолчанию более агрессивные оптимизации, чем компилятор MSVS и поэтому код получается быстрее. Ну надо же, а мы-то не знали! Особенно забавны пространные рассуждения о кол-ве ALU не в тему.
На графике ясно как день видно, что на коде написанном на SSE intrinsics (те оптимизированном вручную — тесты с _ps) оба компилятора показали идентичный результат. Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными?
Использование VirtualAlloc/VirtualFree для выделения пулов это экономия на спичках. Точно также как и использование mmap для этой цели в Линуксе. Совершенно неоправданно класс становится привязан к платформе.
Это где интересно «научные сети» с ограниченной скоростью? Все скорее наоборот, например Tier 1 узлы WLCG соединены с CERN выделенными 10-гигабитными линками.
Серверные платформы обычно едят только регистровую память с ЕСС, которая раза в 4 дороже. Получается в районе шести тысяч за 128GB только за память. Но сути конечно не меняет.
Для п. 1 нужно хранить список прошлых salt пользователя (их в любом случае придется где-то хранить, чтобы избежать повторного использования) и соответственно прогонять новый пароль через них для проверки.
Зачем сравнивать теплое с мягким? Мы не о гугле говорим, а переборе паролей. Одно чтение с диска на поисковый запрос никак не навредит гуглу, но полностью убьёт перебор паролей.
Разница в том, что скорость EXISTS наращивается не втыканием дополнительных видеокарт (что сравнительно дёшево), а покупкой довольно приличного кол-ва памяти (в районе террабайта, что дорого и далеко не во всякую машину влезет).
При использовании хеширования пароль и так уже не однозначный. В данном случае он становится чуть-чуть более неоднозначным, параноики могут компенсировать используя хеш функции большей длины (но практической разницы всё равно не будет).
log(n) будет только если база влезает в память. А если не влезает, то скорость дисков будет ограничивающим фактором. При чём, скорость дисков наращивать гораздо сложнее чем скорость CPU.
В реальном мире репутация действует не в мировом масштабе, а в пределах некой социальной группы. И каждый индивидуум может иметь (и имеет) целый спектр репутаций в тех группах к которым он принадлежит или с которыми как-то взаимодействует. При чем нередко бывает что положительная репутация в одной группе автоматически означает отрицательную в другой.
Главная проблема хабра в том что модель слишком простая — плоская. Нет деления на группы по интересам. Например кто-то любит Windows и имеет в соответствующей группе высокую репутацию. С другой стороны в лагере Linux его могут недолюбливать, но это не должно мешать вносить вклад в развитие Windows части сайта (но может как-то ограничивать возможности в топиках о Linux).
Совершенно ясно, что задача просто так взять и идеально смоделировать реальные социальные отношения невыполнима. Но можно хоть как-то попытаться усложнить модель (вопрос в том как). Сейчас она хоть и примитивна, но стабильна и в принципе готова к следующей итерации.
Очень часто такие комментарии просто не в тему. Зачем лезть в чужой монастырь со своим ненужным им мнением? Точно также любителей Windows и MacOS заминусуют в линуксовых темах, ибо локальный оффтопик.
Несмотря на то что официальных инструментов для этого нет, некая незримая клановость здесь сложилась и по «чужому району» ходить опасно))) Вообще это интересное направление и возможно администрации стоит задуматься о введении более расширенных средств самоидентификации пользователей, чем простая подписка на блоги/хабы.
Стилисты залажали обоих королев (Cersei и Daenerys). «Натуральные» блондинки с черными бровями выглядят совершенно не в тему. Непонятно как можно покрасив, волосы забыть о бровях. такое невнимание к деталям огорчает.
1. в Intel Compiler даже по умолчанию включены некоторые SIMD оптимизации (автоматичекая векторизация например)
2. настройки оптимизации Release весьма далеки от настроек по-умолчанию (кстати, список ключей в студию).
Хотя знать тут вовсе не обязательно, можно и догадаться что 6-ти кратный прирост производительности без SIMD оптимизаций в этих тестах просто не возможен.
А как на счет разобраться и объяснить почему в тестах sinf, expf и logf ускорение в 6 раз, когда наивно можно предположить в только в 4 раза?
Краткое содержание сегодняшней статьи: компилятор Intel использует по-умолчанию более агрессивные оптимизации, чем компилятор MSVS и поэтому код получается быстрее. Ну надо же, а мы-то не знали! Особенно забавны пространные рассуждения о кол-ве ALU не в тему.
На графике ясно как день видно, что на коде написанном на SSE intrinsics (те оптимизированном вручную — тесты с _ps) оба компилятора показали идентичный результат. Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными?
И с какой стати выделение пула malloc'ом будет «фрагментировать heap»?
Например экспорт всего класса Bar из namespace Foo, кроме символов начинающихся с private_stuff.
Главная проблема хабра в том что модель слишком простая — плоская. Нет деления на группы по интересам. Например кто-то любит Windows и имеет в соответствующей группе высокую репутацию. С другой стороны в лагере Linux его могут недолюбливать, но это не должно мешать вносить вклад в развитие Windows части сайта (но может как-то ограничивать возможности в топиках о Linux).
Совершенно ясно, что задача просто так взять и идеально смоделировать реальные социальные отношения невыполнима. Но можно хоть как-то попытаться усложнить модель (вопрос в том как). Сейчас она хоть и примитивна, но стабильна и в принципе готова к следующей итерации.
Несмотря на то что официальных инструментов для этого нет, некая незримая клановость здесь сложилась и по «чужому району» ходить опасно))) Вообще это интересное направление и возможно администрации стоит задуматься о введении более расширенных средств самоидентификации пользователей, чем простая подписка на блоги/хабы.