Здравствуйте, VladD2, Вы писали:
VD>>>Я считаю, что то же функциональное программирование в мэйнстрим ввел Майкрософт (в C# 3.0). А, до этого куча людей пытались убедить в преимуществах ФП менйстрим-программистов, но так и не добились успеха. А, ведь первый ФП язык — Лисп — появился более 50 лет назад! _>>А STL по твоему не является построенной на принципах ФП?) VD>1. Конечное не является. VD>2. Лисп старше на 30 лет.
Так и речь про мэйнстрим, а не про появление идеи ФП. )
Ну и если считать коллекции C# с его сплошным ООП ближе ФП, чем STL, то даже не знаю что ещё сказать... )))
Здравствуйте, antropolog, Вы писали:
VD>>С++ это такой же компромис как и все остальные. Не выдумывай. Никому не нужна производительность любой ценой. Иначе бы все писали на ассемблерах. A>Влад, ты даже близко не в курсе о чём ты говоришь. Компиляторы C++ ( в частности интеловский ) уже больше десяти лет генерируют бинарный код эффективней чем у самого сильного кунг-фу мастера ассемблера во вселенной.
Ну только если не учитывать SIMD... С ним у автоматики пока ещё не всё хорошо, хотя прогресс конечно налицо.
Здравствуйте, alex_public, Вы писали:
VD>>Снобизм у вас, у сиплюсплсников серьезный. Отсюда и выводы неверные. В серьезных задачах скорость достигается не за счет битовыжимательных способностей языка, а за счет грамотно организации кэшей и их инкрементальный обновлению. Важно, только чтобы отставания от битовыжимателей не было в разы. Вот именно это и происходит. _>Вообще то как раз в разы и есть... _>Вот http://rsdn.ru/forum/flame.comp/6070881
совсем не давно был конкретный простейший пример (отставание C# в 7 раз!), который никто из любителей .net'а не смог опровергнуть. Может Nemerle тут покажет класс по быстродействию? ) Если что, исходники для разных языков, а так же точные результаты измерений есть там дальше по ветке обсуждения.
Я так понимаю, отвечать на это желания нет? ) Кто бы сомневался... Только вот если нечего возразить, то тогда полагалось бы взять обратно свои слова насчёт снобизма.
Здравствуйте, antropolog, Вы писали:
_>>Ну только если не учитывать SIMD... С ним у автоматики пока ещё не всё хорошо, хотя прогресс конечно налицо. A>пример в студию. именно на SIMD и именно интеловский компайлер уделывает любого, даже Агнера Фога. Возможно ему потребуется пару хинтов об отсутствии алиасинга ( https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-32ED933F-5E8A-4909-A581-4E9DB59A6933.htm раздел "Helping the Intel® Compiler to Vectorize" ), но зато в результате сгенерит такой код, что а) хрен пойми почему такой б) охренеть какой быстрый
Речь шла про gcc и msvc (там вообще мрак). С icc я не проверял. Хотя сомневаюсь, что он уже умеет всё автоматически. Вот разве что с кучей подобных прагм, расставленных руками (что как бы уже не совсем автоматика).
О, если у тебя есть доступ к icc, то можешь сравнить на нём разницу между вариант со включенной векторизацией и выключенной на таком http://rsdn.ru/forum/flame.comp/6072279
Здравствуйте, antropolog, Вы писали:
A>Влад, ты даже близко не в курсе о чём ты говоришь. Компиляторы C++ ( в частности интеловский ) уже больше десяти лет генерируют бинарный код эффективней чем у самого сильного кунг-фу мастера ассемблера во вселенной.
и ты конечно лично знаком с этим мастером кунг-фу?
на самом деле — сейчас каждый человек, знающий асемблерные команды, воображает себя мастером оптимизации и начинает оптимизировать как может. чаще всего просто оптимизирует по кол-ву ассемблерных команд или что-нибудь ещё более весёлое. вот таких товарищей компиляторы легко опережают, и поэтому вполне справедливо сказать, что машина сейчас умнее среднего ассемблерщика
что касается мегакрутых — ты наверно не в курсе, сколько интел выпускает ассеблерного кода. патчи к openssl, статьи с реализациями рахличных криптографических и хеш-алгоритмов, ipp/mkl (их исходники закрыты, но недавно intel опубликовала исходники своего deflate — там чистый ассемблер в главном цикле)
в общем, стоит только немного углубиться в вопрос и ты тут же увидишь всю тупость компиляторов. только в этом году я имел дело
1) с алгоритмом ST4. там 3 цикла по паре строчек и в одном из них intel впятеро быстрее конкурентов. без комментариев, асемблерный код я даже не смотрел
2) алгоритмом CRC32. там разброс скоростей достигает пары раз, а ведь нужно всего лишь оптимально зашедулить зависимсые вычисления. на первом месте кстати msvc
3) вычислением скалярного проихведения sum(a[i]*b[i]), при этом a/b — 32-битные, а сумма/проихведение — 64-битные. о, какой там код генерится в sse2-режиме! gcc уступил вдвое самому простому ассемблерному коду, у icl/msvc дела обстоят ещё хуже
Здравствуйте, alex_public, Вы писали:
_>О, если у тебя есть доступ к icc, то можешь сравнить на нём разницу между вариант со включенной векторизацией и выключенной на таком http://rsdn.ru/forum/flame.comp/6072279
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mazay, Вы писали:
M>>Да, там не D, а Go. Перепутал.
VD>Ну, и почему вывода по D?
Я же сказал — я перепутал.
M>>Доказательство эквивалентности алгоритма — тот факт, что его до сих пор не выкинули из тестов. У них требование на использование такого же алгоритма, даже явная развёртка циклов запрещена.
VD>А, что там делают разные версии на одном и том же языке? Как так получилось, что есть разные, но эквивалентные версии?
Это называется "особенности" реализации алгоритма. По сути неэффективная реализация. Их там сохраняют потому что иногда после модификации неэффективной реализации она может стать самой быстрой.
VD>>>Не скажу за Рсат, а ди выдавал вполне себе приличный код. Есть даже бэкэнд для GCC.
M>>Не нашёл подтверждений. Видел опровержения: https://attractivechaos.github.io/plb/
VD>Подтверждение чего? Опровержение чего? Вроде там результаты D на уровне С-шных.
Ну вот такой взгляд разработчиков языка на результаты тестов и множит на ноль все его перспективы в HPC. D по всем тестам медленнее C. Даже на наивном умножении матриц. Это как надо накосячить в компиляторе, чтобы получить просадку на такой элементарной вещи? Там машинный код должен быть один-в-один. Если у них бэкэнд от GCC, то что же там надо было навертеть в IR? Вот у clang++ правильный подход. Если им присылают код, который на gcc компилируется в более быстрый, то они заводят багу.
M>>Кхм. Производительность сравнивают по лучшим результатам.
VD>Если результаты одного языка отличаются, то где гарантии, что дело не в том как написан тест, а именно в компиляторе?
Я в этом посте выше написал про "особенности" реализации. Никогда нельзя быть уверенным, что ты что-то не упустил, но если ты хочешь показать, что какой-то язык/компилятор крут — ты всегда можешь сравнить код и машинный код с самой быстрой реализацией (на другом языке) и поправить свой код. Если это сделать не удаётся — это баг.
VD>И уж точно дело не в языке.
M>>Хотя Раст самый близкий конкурент.
VD>Ну, вот смотри. От твоих исходных утверждений ни осталось ничего. И Раст уже не полное дерьмо, и Ди, вроде бы на уровне.
Я не говорил, что Раст полное дерьмо — он не достаточно хорош. Для HPC по крайней мере, но они вроде как именно там видят свою нишу. Ни Раст, ни Ди не дотягивают до минимально необходимого уровня производительности. Именно поэтому на них не переходят толпы. Это такой же стоп-фактор в этой области, как проприетарная платформа.
Вообще у нас диалог странный. Я сказал, что Немерл не используют, потому что он на проприетарной платформе, а ты мне в качестве контрпримера привёл также непопулярные языки на открытой платформе. Причём в которые неплохие деньги вложили. Причём они уже гораздо больше "выстрелили", чем Немерл.
Ты бы лучше привёл пример языка на проприетарной платформе, который "выстрелил" без одобрения хозяина. Под Линкусом выстрелили Python, Perl, PHP, R.
VD>Понятно, что если вложить в оптимизирующий компилятор для языка много сил, то он станет порождать более быстрый код. Но пока мы все не перейдем на этот язык никто не будет вкладывать бабки в создание оптимизирующего компилятора для него. Вот такой вот парадокс.
M>>Если язык может внезапно провалиться в 3 раза от C/C++, то мне такого не надо.
VD>А, тебе не кажется, что если в одном тесте язык в 3 раза провалился, а в другом в 3 раза выиграл, то все тоже самое можно сказать и о референсном языке? Зачем тебе язык, который провалился по отношению к Хаскелю?
M>>Ну Немерлу с дотнетом не стоит и пытаться в HPC лезть. Ему среднедотнетовской производительности за глаза хватит. Тесты хороши для продвижения, да. А ещё это объективный критерий, коих не много.
VD>Дело не в этом. Там люиноксятина и, как следствие, Моно. А, Моно — это известный тормоз, и баги. Немерл догое время не мог собрать сам себя из исходников на Моно из-за багов Моно. Мы им даже пулреквесты с фиксами давали, но их принимали по пол года, а потом они бесследно изчезли. Плюс измеряют скорость они внешней утилитой, которая за одно измеряет время джита и загрузки рантайма, а те только самих вычислений.
Собственно я о чём и говорю — вы с платформой прогадали. Моно никто не будет развивать — это странный монстр, в которого никто вкладываться не будет. Хотите поддержку открытых платформ — пилите под LLVM. Забейте на GC, сделайте ARC.
VD>На Виндовс расклад был бы иным. Особенно в х86.
х86 — это прошлый век. Его смотрят если только есть вылизанная доисторическая реализация.
M>>О тебе я сужу строго и исключительно по тебе. Благо, материала накопилось предостаточно. WH>Сказал человек, не имеющих технических аргументов.
О да. Ведь по-твоему оскорбления и позиция «я — д'Артаньян, вы — тупое стадо» — это технические аргументы. Извини, таких «технических аргументов» не имею
VD>>>Не спорю, популярность Немерла еще меньше, но и от этого та же Скала мэйнстримом не становится. M>>Мне нравится, как ты упорно говоришь про мейнстрим, хотя ни я ни Гест про мейнстрим не говорим. VD>Здесь вся тема об этом. Дай тогда свое определение "взлетевшему"/"выстрелевшему". Для меня это означает — язык массово используется, а это и есть мэйнстрим.
Про это я написал в первом же сообщении. Про это уже написал Гест. Ты, правда, упорно игнорируешь все, что тебе не нравится.
M>>То, что ты «писал по мере продвижения» всегда находилось в глубине обсуждений на РСДН — и только на РСДН. VD>Ну, дык мы ведем разработку, а не продвигаем готовый продукт. Ходить и хвастатья незаконченым продуктом смысла нет. Плюс у меня, к сожалению, не того качества английский, чтобы писать пространные материалы на нем.
Не обязательно пространные Я же говорю, у тебя в голове — набор каких-то штампов: надо миллион долларов, надо стать мейнстримнее всех, надо писать огромные статьи на каждый чих.
M>>Я лично тебе раз пять напоминал про ваш же «официальный твиттер Nitra». Там — тишина и мертвые с косами. VD>Ну, и что я там буду писать? "Я тут произвел комитик!" или "Пилим фичу ХХХ"? VD>Когда были промежуточные релизы, были и блоги, и документация, и твиты. Сейчас мы работает над Milestone 2. Я периодически обновляю эту страничку. Когда будет готово то на что стоит посмотреть, будем и в твиттере писать, и в блогах.
Иду в блог JetBrains, там написано: смотри официальный твиттер.
Иду в официальный твиттер — там тишина.
Видимо о том, что идет работа над Milestone 2 я должен догадаться от духа святого.
M>>>>- в проекте даже не было Readme VD>>>Вот целый сайт на конфлюэнсе в котором есть и рейдми, и документация и описание по установке. M>>Да. После того, как мне понадобилось четыре сообщения, чтобы донести до тебя эту простую мысль. Ту ветку ты стыдливо удалил. В тот момент, когда ты выложил Нитру было именно то, что я описал. Ни больше ни меньше. VD>Что ты несешь. Посмотри на даты. Это же вики. Там все даты есть. VD>Но главное, зачем ты врешь, что ничего нет и все на все наплевать?
Еще раз. Медленно. Когда вы выложили свой продукт в опенсорс и сообщили об этом, у проекта не было даже простейшего Readme и он не собирался, а инструкция по сборке была написана только на РСДН,в одном из сообщений/обсуждений. Это не вранье, а чистая правда, которую, к сожалению, тебе не охота ни вспоминать ни признавать. Понадобилось минимум четыре пинка, чтобы в проекте появился Readme и четыре месяца, чтобы в Readme, например, появилась секция install information. https://github.com/JetBrains/Nitra/commits/master/README.md
Самое грустное, что это — наплевательское отношение даже не к потенциальным пользователям. Это — наплевательское отношение к своему же детищу, на создание которого ты тратишь все силы
M>>«Я пишу о состоянии нитры по мере развития» ага-ага. Последнее именно что сообщение про Нитру — 27 мая 2014 года — больше года тому назад. Последнее сообщение в блоге JetBrains? Наверное, тогда же. VD>Я пишу на русском. Можешь присоедениться и помочь писать на английском. Мой английский низкого качества и пишу я на нам крайне медленно, так что я не успею работать над самой Нитрой.
Еще раз. Медленно. Не обязательно выкладывать огромные куски текста на английском. Достаточно status updates в одно-два сообщения. Плюс задать себе вопрос: поему у Kotlin это получалось, а у вас — нет
VD>То что я выкладываю на РСДН — это предварительная информация не самого лучшего качества.
Никто не требует самое лучшее качество. Требуют хотя бы какую-то информацию.
M>>При том, что я тебе уже несколько раз говорил: раз в несколько месяцев возникают вопрос о состоянии Нитры.
VD>И? Я специально по твоим просьбам пишу о том на чем работаем. Но большинству это совершенно не интересно, потому как на незаконченом продукте все равно ничего не сделаешь, а сделаешь, так придется потом переделывать, так как все может измениться.
1. Просьбы не мои. Вопросы про состояние задаю не я, а те самые «тупые которым ничего неинтересно» потенциальные пользователи
2. Ты не поверишь, но всем во всем мире прекрасно известно, что все может измениться. Но почему-то вы — единственные, для кого это — отмазка, лишь бы ничего не писать и не сообщать.
M>>Где-то в глубине подветок ты или кто-то еще в итоге отвечают. Что мешает написать то же самое в твиттере? VD>А, что можно написать о деталях в формате 140 символов? Транслировать лэйблы коммитов?
1. Напиши блог пост длиной в два абзаца раз в месяц. Дай на него ссылку в твиттере.
2. Напиши "Work on Milestone 2 started. ETA: second half of 2016, see Roadmap here". Я не понимаю, почему нельзя написать вот это сообщение
в блог, дать на него ссылку.
4. И ты не поверишь. Но можно писать даже «A feature/fix implementing/fixing some major issue added in commit X, ссылка».
Потому иначе что для любого заинтересованного что в Нитре что в Немерле потенциального пользователя (особенно глоабльного, на которого проекты — хаха — нацелены) оба проекта мертвы.
M>>Особенно теперь, когда проект в опенсорсе? Ну кроме уверенности, что все вокруг враги с черной неблагодарностью?
VD>Я предлагаю тебе не заниматься трепом, а попробовать самому. Могу рассказывать тебе все детали проходящего, а ты попробуй из этого сделать что-то интересного в твиттере или еще где-то. Лично мне не ясно, что можно твиттить о работе над чем-то.
Ты статус апдейты пишешь? Пишешь. Ты галочки в Milestone обновляешь? Обновляешь. Что мешает написать об этом в твиттер?
M>>Ничего я никуда не натягиваю. Ты постоянно плачешься, что «для пиара и продвижения нужно мегабабло». Давай посмотрим, что ты, как разработчик сделал для продвижения что Немерле, что Нитры?
VD>Я не плачусь. Я высказываю свои мысли которые сформировались в процессе анализа ситуации. Есть реальность и ее нужно осознавать такой какая она есть.
Да, но твоя «реальность» почему-то заключается в «дайте миллиард долларов чтобы стать мейнстримом информацию не выкладываем вокруг неблагодарные враги». Это — не реальность.
VD> Меня удивляют некоторые ее аспекты о чем я и говорю. Возможно, в процессе разговора удастся сформировать более точную картину мира. Это поможет в будем. Я еще не теряю надежду на то, чтобы создать действительно массовый язык включающий концепции которые, по моему, сильно упрощают разработку. Потому я потихоньку думаю как и что надо делать. Если никому не интересны мои наблюдения и выводы, ну, что же. Могу и помолчать.
Наоборот. Это тебе неинтересны ничьи наблюдения и выводы, кроме твоих собственных. Можешь посмотреть на твое общение с Гестом.
M>>Немерле: M>>- на сайте висят неработающие ссылки до тех пор, пока вас кто-то не пнет
VD>А, как по другому? Прикажешь ходить по всем ссылкам каждое утро и проверять нет ли среди них битых? Кто-то что-то забыл, что-то сломалось. Люди заметили, сказали и кто-то это дело починил.
Да. Именно так. Заходить и проверять. Обновлять. Поправлять. Мегакрутой язык же. Напишите за вечер бота, который раз в неделю будет проходить по ссылкам и проверять, что status == 200 OK.
VD>Часто бывает даже так, что люди сами же и предлагают пул-реквесты к найденным ими проблемам.
Почему-то в вашем случае это единственное, что вы хотите делать: чтобы кто-то пришел со стороны и все за вас пофиксил.
M>>1. За Nitra тебе платят. VD>Ага. Вот я и работаю над ней по 15 часов в сутки.
То есть это — твое любимое детище, для которого ты не жалеешь ни времени ни сил. Почему у тебя к нему в итоге такое наплевательское отношение, меня удивляет.
VD>Над Колином работает намного больше народу. Плюс он в совершенно другом статусе.
Что значит в другом статусе?
VD>Ну, а главное, что я тебе показываю ссылки, но ты говоришь, что информации нет.
Стоп. Какие ссылки ты мне показываешь? Одну ссылку на Milestone 2. Из которой я каким-то образом должен догадаться, что это — живая обновляемая страница. Ну-ну.
M>>2. Если проект настолько мегакрут, как описывается (это про Немерле), за 10 лет на нем можно было начать зарабатывать деньги VD>Дык люди и зарабатывают. В Касперском Интернет секьюрити с применением немерла писалась. Кто-то онлайн-трейдинг забабахал (ссылки тут давались). Мы пилим Нитру и я тебя уверяю, что выпилить ее на чем-то другом было бы очень затруднительно. Просто есть люди которым нужны нотариально заверенные ссылки, а есть люди которые берут и пользуются. VD>Вот парень взял скачал Нитру и не задавая ни одного вопроса написал парсер реального языка (HLSL) и опубликовал в блоге свои ощущения от использования Nitra. VD>Но, да, информации нет...
Да. Информации нет. Ты вообще очень смешной, Влад. Ты почему-то уверен, что абсолютно все будут ломиться на языки с непонятным статусом — это во-первых. И во-вторых, что язык должен стать сразу мегапопулярным, иначе все, жизни нет.
Специально для тебя Crossing the Technology Chasm
И ты этого не просто не понимаешь, а даже отказываешься понимать. У Немерле есть от силы несколько early adopters. И Нитры — от силы один innovator. Все. Вместо того, чтобы понять, почему так, и посмотреть, как развиваются другие языки, ты сидишь в своем домике под названием «мегабабло, мегапиар, все тупые ублюдки не понимают крутости».
При том, что каждый первый человек тут расскажет тебе, как они пользуются всякими Scala, Clojure, Erlang'ами и смотрит на прочие Elm'ы, Idris'ы и Elixir'ы невзирая на твой домик. Да блин, я, тупейший черный неблагодарный крикун, пересел на Erlang, когда для него информации было еще меньше, чем для Nemerle, например. И 9 лет вел — сам, без оплаты, без мегапиара — сайт, ему посвященный (из-за чего огромное количество русскоязычных людей в Erlang-community знают и меня и Erlang ).
M>>Что значит «уговаривать»? Почему «уговаривать» и прочая чушь не остановили ни Elixir, ни Скалу, ни Clojure, ни... ни...? Может проблема не во врагах вокруг тебя? VD>Да, потому что один ходит во круг и указывает на недостатки. Другой не видит преимуществ хотя ему их на блюдечке выкладывают. Всем надо чего-то. Причем если им это дать, то этого все равно оказывается мало и они хотят что-то еще. Единственное что они не хотят — это пробовать и помогать.
Ты не поверишь. В каждом языке, в каждом проекте, в каждом фреймворке есть такие люди. И эти проекты-языки-фреймворки продолжают существовать и намного популярны, чем Немерле/Нитра, авторы которого видят во всех врагов.
VD>Вот когда будут результаты которыми смогут воспользоваться другие, тогда сосредоточимся на пиаре. Слава богу в ДжетБрэйнсе для этого возможности есть и мне не придется делать это все в одиночку. Но пиариться раньше времени глупо. Получится только хуже.
VD>Работа не из простых. Времени тратится много. Работает над проектом всего три человека. Так что уж извини, что не все, ни сразу и не вчера.
Никто не требует все сразу и вчера. Но тебе, я вижу, твои шоры мешают это понять.
Здравствуйте, alex_public, Вы писали:
_>О, если у тебя есть доступ к icc, то можешь сравнить на нём разницу между вариант со включенной векторизацией и выключенной на таком http://rsdn.ru/forum/flame.comp/6072279
(count=500, width=1920, height=1080) тесте? А то у меня gcc выдаёт на haswell xeon ускорение всего где-то в 3 раза, что как-то не очень для AVX2...
В этом примере помимо вычислений есть ещё и доступ к памяти, который занимает существенное время. Можешь сделать следующий замер: убери из кода все вычисления, оставь только перекачку данных.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вот-вот. ты хоть знаешь, сколько сложений за такт может выполнить этот хасвел? или думаешь, что раз avx2 то всё должно быть тупо в 8 раз быстрей?
Я бы сказал раз в 6. Т.е. само сложение именно что в 8 раз быстрее, но есть накладные расходы на загрузку и выгрузку данных.
Здравствуйте, alex_public, Вы писали:
BZ>>вот-вот. ты хоть знаешь, сколько сложений за такт может выполнить этот хасвел? или думаешь, что раз avx2 то всё должно быть тупо в 8 раз быстрей?
_>Я бы сказал раз в 6. Т.е. само сложение именно что в 8 раз быстрее,
за такт хасвел может выполнить 4 скалярных сложения или 2 simd плюс два скалярных
_>но есть накладные расходы на загрузку и выгрузку данных.
за такт хасвел может выполнить 2 загрузки, причём любого размера — хоть 4 байта, хоть 32. плюс ещё есть куча ньюансов. в результате скорость загрузки ограничивает производительность скалярного, а не векторного кода, как ты думал. а точнее, её ограничивает то что за такт можно выполнить лишь 4 макрооперации (load, add или load+add), причём не более двух из них могут использовать загрузку. в векторном же как раз всё очень просто — лепим две load+add каждый такт, store совершенно бесплатен, 1 такт уходит на cmp+blend
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В этом примере помимо вычислений есть ещё и доступ к памяти, который занимает существенное время. Можешь сделать следующий замер: убери из кода все вычисления, оставь только перекачку данных.
И да и нет. Т.е. "тормоза" как раз из-за этого, но по факту данных там не много, просто компилятор не способен этого увидеть и качает одни и те же данных по несколько раз.
Здравствуйте, alex_public, Вы писали:
EP>>В этом примере помимо вычислений есть ещё и доступ к памяти, который занимает существенное время. Можешь сделать следующий замер: убери из кода все вычисления, оставь только перекачку данных. _>И да и нет. Т.е. "тормоза" как раз из-за этого, но по факту данных там не много, просто компилятор не способен этого увидеть и качает одни и те же данных по несколько раз.
Конечно лучше когда значения явно кэшируются в регистрах, но тем не менее в этом случае повторная закачка происходит всего лишь из L1.
Можешь сделать другой тест — выбери такие размеры изображений, чтобы они целиком умещались в L1 (в твоём примере ЕМНИП они в аккурат вываливались из L3 в RAM) — тогда вклад непосредственно вычислений в суммарное время будет намного больше, и получится более точно оценить непосредственно эффект от AVX2.
Здравствуйте, BulatZiganshin, Вы писали:
_>>Я бы сказал раз в 6. Т.е. само сложение именно что в 8 раз быстрее, BZ>за такт хасвел может выполнить 4 скалярных сложения или 2 simd плюс два скалярных
И причём тут это к нашей теме? )
_>>но есть накладные расходы на загрузку и выгрузку данных. BZ>за такт хасвел может выполнить 2 загрузки, причём любого размера — хоть 4 байта, хоть 32. плюс ещё есть куча ньюансов. в результате скорость загрузки ограничивает производительность скалярного, а не векторного кода, как ты думал. а точнее, её ограничивает то что за такт можно выполнить лишь 4 макрооперации (load, mul или load+mul), причём не более двух из них могут использовать загрузку. в векторном же как раз всё очень просто — лепим две load+mul каждый такт, store совершенно бесплатен, 1 такт уходит на cmp+blend
Очаровательно. ) Куча информации из документации и при этом ровно ноль информации по делу. Я вот так даже и не понял, ты собственно согласен с моим предположением, что векторизацию в том примере можно провести эффективнее, чем это делает gcc или не согласен? ) Если согласен, то к чему ты вообще всё это написал? ) А если не согласен, то где какие-нибудь аргументы? )
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>И да и нет. Т.е. "тормоза" как раз из-за этого, но по факту данных там не много, просто компилятор не способен этого увидеть и качает одни и те же данных по несколько раз.
быстрее там никак не сделаешь, так что дело не в компиляторе. более того ...
EP>Конечно лучше когда значения явно кэшируются в регистрах, но тем не менее в этом случае повторная закачка происходит всего лишь из L1.
... в данном случае load вообще бесплатен
EP>Можешь сделать другой тест — выбери такие размеры изображений, чтобы они целиком умещались в L1 (в твоём примере ЕМНИП они в аккурат вываливались из L3 в RAM) — тогда вклад непосредственно вычислений в суммарное время будет намного больше, и получится более точно оценить непосредственно эффект от AVX2.
по моим прикидкам оптимальный avx2 код на 4ГГц будет читать 25.6 ГБ/с и писать ещё столько же, поэтому достаточно немного уменьшить высоту изображений чтобы заведомо влезать в L3C. сейчас же там 8 мб входных+8мб выходных данных, так что при тестировании на десктопе мы упрёмся в скорость ОЗУ
Здравствуйте, alex_public, Вы писали:
_>И причём тут это к нашей теме? )
ясно ok
1) твои рассуждения бессмысленны, поскольку невозможно рассуждать о быстродействии, не зная микроархитектуры
2) я прикинул оптимальный скалярный и avx2 код и у меня получилась разница в скорости в районе 6 раз
3) твой тест мог упереться в скорость озу, как я сказал в пред. сообщении
4) несложно самому написать оптимальный avx2-код на mm256_* операциях и посмотреть его скорость
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Конечно лучше когда значения явно кэшируются в регистрах, но тем не менее в этом случае повторная закачка происходит всего лишь из L1.
Не факт. Там же всего 64 байта на линию, а мы грузим 32 байтными кусками со сдвигом в 4 байта.
EP>Можешь сделать другой тест — выбери такие размеры изображений, чтобы они целиком умещались в L1 (в твоём примере ЕМНИП они в аккурат вываливались из L3 в RAM) — тогда вклад непосредственно вычислений в суммарное время будет намного больше, и получится более точно оценить непосредственно эффект от AVX2.
Ну уменьшил высоту в 10 раз и увеличил количество циклов в 10 раз. В итоге стало считаться не 1,31 с, а 1,17 с. )
