In our laser-produced plasma (LPP) source, molten tin droplets of around 25 microns in diameter are ejected from a generator at 70 meters per second.
Там есть как минимум ещё одна неточность — на самом деле после первого импульса капля деформируется в «блин», а второй уже превращает её в плазму, это хорошо показано на втором ролике и другом рендере от ASML.
Было бы очень интересно почитать! Ждём с нетерпением.
Попутно вопрос — реально ли на ПЛИС перехватить и записать высокочастотный сигнал HDMI, скажем, для 1920x1080@60? Интересует запись потока бит «как есть», без искажений, то есть обычная HDMI capture карта тут не подойдёт. Интервал времени — на два-три фрейма. Подозреваю, что нет — из-за ограничений на частоту самой ПЛИС, но вдруг что-то упускаю?
Если нет, существует ли вообще способ сделать это относительно дешёвыми средствами?
Гугл очень любит экспериментировать с дизайном поисковой выдачи, так что при каждом открытии страницы с чистыми Cookies может показываться уникальное оформление. То есть ссылка особо ничего не даст, нужно N раз открыть страницу в инкогнито, пока не откроется нужная вариация.
Подозреваю, у них алгоритмы заточены на автоматическое изменение отдельных частей страницы и поиск корреляций между поведением пользователя и оформлением.
Видел эти заметки, спасибо. Однако Micro/MacroFusion появились ещё во времена Core 2, а описанная странность проявлялась только на P-ядрах i7-13700H и не давала эффекта, например, на относительно свежем i5-10400 (Comet Lake). Звучит как особенность конкретной микроархитектуры, хотя тут я точно не специалист.
Надо было расчехлить VTune и детальнее исследовать метрики — возможно, из-за отсутствия времени забил.
нечто, кажущееся невинным, например, структура программы, способно вызывать колебания результатов бенчмарков в пределах 40%
О да, не так давно обнаружилось, что на P-ядрах мобильных Raptor Lake вставка лишней (!) NOP-инструкции в выровненный на начало кеш-линии цикл может ускорить программу. То есть вот такое:
align 64
lp:
dec rcx
jnz lp
работало условно за 1.6 секунды без значительных колебаний, а вот такое:
align 64
lp:
dec rcx
nop
jnz lp
примерно за 0.95 — 1.25, каждый раз получалось случайное время в этом интервале (частота зафиксирована, Turbo Boost отключен). Может, я что-то сделал/понял не так — знающих прошу откликнуться.
Понятно, что пример синтетический, но всё же. Микроархитектура современных Intel — это вообще загадка, AMD в этом отношении более предсказуемы.
-O3 генерирует код, который гораздо быстрее кода с -O2
-O3 далеко не вершина эволюции, есть ещё более жёсткий -Ofast. Но и он не даёт гарантий, что будет быстрее, надо бенчмаркать. Однако тут тоже может выясниться, что вариант -Ofast на одном CPU работает быстрее, а на другом быстрее -O2 или даже -O0 (и такое бывает).
Встраивание в первую очередь полезно тем, что избавляет от команды вызова
Не только, ещё избавляет от кучи PUSH / POP перед входом и выходом из процедуры.
А статья и перевод замечательные, побольше бы таких.
...а потом вырастают и не могут ориентироваться в простейших 3D-уровнях, вроде пересадочного узла в метро.
По теме исследования — на мой неискушённый взгляд, лучше акцентировать внимание не только на том, сколько времени проведено в играх, но и на разнообразии самих игр. Если годами играть в одно и то же, это и близко не даст эффекта, каковой будет при диверсификации. Регулярная смена пластинки побуждает думать и разбираться, изучать, исследовать. Если зацикливаться на чём-то одном, это приведёт к стагнации.
Если не нужна большая точность, можно с помощью акселерометра и гироскопа в телефоне определять местоположение. Но для этого нужен трекинг пути с самого начала полёта и задание начальных координат.
Отличный проект, спасибо! В своё время впечатлил ещё whisper / whisper.cpp, у которого также есть веб-версия. Из предложений — вероятно, перед загрузкой стоит предупреждать о размере модели, т. к. не у всех безлимитный трафик.
Какая доля транзисторного бюджета расходуется на поддержку легаси инструкций и обеспечения совместимости с какими-то экзотическими древними системами?
В одной из статей серии «Made at Intel» упоминается такое:
С каждым shrink (переходом на более совершенный процесс изготовления чипов) площадь, необходимая для поддержки legacy инструкций, “сжимается” в два раза.
Intel уже работает над x86S — сокращённом варианте x86 без легаси.
Конечно, предельная оптимизация вообще должна подразумевать кучу аспектов:
Заточенность на определённую аппаратную платформу, причём именно платформу целиком, не только процессор — так как, например, разные планки памяти могут иметь разные характеристики, соответственно, оптимальный код может отличаться (пусть это и редкий случай). Ещё надо учитывать микроархитектуру ядра, на котором выполняется программа — особенно актуально на ARM и x86, начиная с Alder Lake
Заточенность на входные данные — если они не совсем случайные (а это большинство кейсов), то как правило, здесь тоже можно разгуляться — branch prediction, префетчи, оптимальная глубина разворачивания циклов, разные ветви кода для разных кейсов и так далее
Входные данные могут меняться со временем, и это тоже надо учитывать (нужен JIT?)
Как-то раз удалось, почти случайно, написать на Ассемблере код, который работал на E-ядрах (тех самых, которые так не любят) i7-13700H как минимум на 70% быстрее, чем любая вариация машинного кода, сгенерированная GCC / Clang / oneAPI DPC++ с различными сочетаниями оптимизирующих флагов и PGO (как компиляторным, так и с LLVM BOLT), причём работало на те же 70% быстрее даже чем при запуске на P-ядре при равной частоте.
Немного таблиц из других экспериментов, без оптимизации на Ассемблере
Числа в ячейках — время работы в секундах.
Программа на проверку гипотезы Коллатца до определённого N:
Сортировка пузырьком:
Кроме того, при ручном написании кода мы неизбежно играем в перебор, надеясь эмпирически найти оптимальный код (который совсем не факт что будет быстрым на другом железе). Когда речь заходит о брутфорсе, в это непременно должен вовлекаться компьютер, так как у него для этого существенно больше ресурсов. Выше Вы привели очень правильную мысль:
непосредственно машинный код можно написать любой, а компилятор в состоянии породить только ограниченное подмножество вариантов
Так почему бы не дать компиляторам возможность генерировать разные вариации машинного кода и тестировать их самостоятельно? Да, среди этих вариаций может не быть идеальной, но возложив перебор на компьютер, мы сможем подойти к ней существенно ближе, чем перебирая варианты вручную.
Возможности оптимизации во многом зависят от того, что знает о коде компилятор. Может оказаться так, что в Rust больше возможностей дать компилятору подсказку (либо же это получается косвенным образом, исходя из строгости языка), тем самым позволив ему создать более шустрый машинный код.
Но зачастую сделать такие подсказки без тщательного изучения алгоритма непросто.
В октябре 2008 года AMD объявила о планах создания совместного предприятия с Advanced Technology Investment, инвестиционной компанией, созданной правительством Абу-Даби. В это новое совместное предприятие, названное GlobalFoundries, было выделено производственное подразделение AMD — все фабрики и полупроводниковые производства компании. Это позволило AMD стать бесфабричной компанией и сконцентрироваться исключительно на проектировании и разработке микросхем.
Мы тоже не понимаем как у CPU на 96 ядер TDP больше, чем у 192 ядерного
У 96-ядерного предельная частота 3.7 ГГц против 3.2 ГГц у 192-ядерного, а мощность, как известно, зависит нелинейно:
,
где — ёмкостная нагрузка, — напряжение, — частота.
Производительность напрямую зависит от частоты, однако с частотой приходится повышать и напряжение — в противном случае процессор будет сбоить (подобная проблема также возникает при чрезмерном андервольтинге).
Справедливо, реальная скорость капли гораздо меньше:
Там есть как минимум ещё одна неточность — на самом деле после первого импульса капля деформируется в «блин», а второй уже превращает её в плазму, это хорошо показано на втором ролике и другом рендере от ASML.
На YouTube есть впечатляющие ролики с демонстрацией работы этих машин:
Работа лазера, генерирующего предварительный и основной импульс
Узнать больше можно на сайте TRUMPF, там есть это же видео, загруженное на другой хостинг.
High NA EUV
Было бы очень интересно почитать! Ждём с нетерпением.
Попутно вопрос — реально ли на ПЛИС перехватить и записать высокочастотный сигнал HDMI, скажем, для 1920x1080@60? Интересует запись потока бит «как есть», без искажений, то есть обычная HDMI capture карта тут не подойдёт. Интервал времени — на два-три фрейма. Подозреваю, что нет — из-за ограничений на частоту самой ПЛИС, но вдруг что-то упускаю?
Если нет, существует ли вообще способ сделать это относительно дешёвыми средствами?
Надо же, буквально на следующий день статья по теме. Благодарю!
UPD: выглядит очень похоже, особенно с учётом малых отличий Raptor Lake от Alder Lake.
Гугл очень любит экспериментировать с дизайном поисковой выдачи, так что при каждом открытии страницы с чистыми Cookies может показываться уникальное оформление. То есть ссылка особо ничего не даст, нужно N раз открыть страницу в инкогнито, пока не откроется нужная вариация.
Подозреваю, у них алгоритмы заточены на автоматическое изменение отдельных частей страницы и поиск корреляций между поведением пользователя и оформлением.
Видел эти заметки, спасибо. Однако Micro/MacroFusion появились ещё во времена Core 2, а описанная странность проявлялась только на P-ядрах i7-13700H и не давала эффекта, например, на относительно свежем i5-10400 (Comet Lake). Звучит как особенность конкретной микроархитектуры, хотя тут я точно не специалист.
Надо было расчехлить VTune и детальнее исследовать метрики — возможно, из-за отсутствия времени забил.
О да, не так давно обнаружилось, что на P-ядрах мобильных Raptor Lake вставка лишней (!) NOP-инструкции в выровненный на начало кеш-линии цикл может ускорить программу. То есть вот такое:
работало условно за 1.6 секунды без значительных колебаний, а вот такое:
примерно за 0.95 — 1.25, каждый раз получалось случайное время в этом интервале (частота зафиксирована, Turbo Boost отключен). Может, я что-то сделал/понял не так — знающих прошу откликнуться.
Понятно, что пример синтетический, но всё же. Микроархитектура современных Intel — это вообще загадка, AMD в этом отношении более предсказуемы.
-O3далеко не вершина эволюции, есть ещё более жёсткий-Ofast. Но и он не даёт гарантий, что будет быстрее, надо бенчмаркать. Однако тут тоже может выясниться, что вариант-Ofastна одном CPU работает быстрее, а на другом быстрее-O2или даже-O0(и такое бывает).Не только, ещё избавляет от кучи PUSH / POP перед входом и выходом из процедуры.
А статья и перевод замечательные, побольше бы таких.
Сначала они не играют в игры...
По теме исследования — на мой неискушённый взгляд, лучше акцентировать внимание не только на том, сколько времени проведено в играх, но и на разнообразии самих игр. Если годами играть в одно и то же, это и близко не даст эффекта, каковой будет при диверсификации. Регулярная смена пластинки побуждает думать и разбираться, изучать, исследовать. Если зацикливаться на чём-то одном, это приведёт к стагнации.
Настоящая буля из пустыни должна выглядеть так :)
Статья по теме
То есть телеметрию можно будет отключить?
Если не нужна большая точность, можно с помощью акселерометра и гироскопа в телефоне определять местоположение. Но для этого нужен трекинг пути с самого начала полёта и задание начальных координат.
Отличный проект, спасибо! В своё время впечатлил ещё whisper / whisper.cpp, у которого также есть веб-версия.
Из предложений — вероятно, перед загрузкой стоит предупреждать о размере модели, т. к. не у всех безлимитный трафик.
На такой случай можно сделать локальную синхронизацию колонок.
UPD: уже предложили.
А Вы не Keyu Tian, случаем? :)
В одной из статей серии «Made at Intel» упоминается такое:
Intel уже работает над x86S — сокращённом варианте x86 без легаси.
О да, HTTrack ещё пользовался
Конечно, предельная оптимизация вообще должна подразумевать кучу аспектов:
Заточенность на определённую аппаратную платформу, причём именно платформу целиком, не только процессор — так как, например, разные планки памяти могут иметь разные характеристики, соответственно, оптимальный код может отличаться (пусть это и редкий случай). Ещё надо учитывать микроархитектуру ядра, на котором выполняется программа — особенно актуально на ARM и x86, начиная с Alder Lake
Заточенность на входные данные — если они не совсем случайные (а это большинство кейсов), то как правило, здесь тоже можно разгуляться — branch prediction, префетчи, оптимальная глубина разворачивания циклов, разные ветви кода для разных кейсов и так далее
Входные данные могут меняться со временем, и это тоже надо учитывать (нужен JIT?)
Как-то раз удалось, почти случайно, написать на Ассемблере код, который работал на E-ядрах (тех самых, которые так не любят) i7-13700H как минимум на 70% быстрее, чем любая вариация машинного кода, сгенерированная GCC / Clang / oneAPI DPC++ с различными сочетаниями оптимизирующих флагов и PGO (как компиляторным, так и с LLVM BOLT), причём работало на те же 70% быстрее даже чем при запуске на P-ядре при равной частоте.
Немного таблиц из других экспериментов, без оптимизации на Ассемблере
Числа в ячейках — время работы в секундах.
Программа на проверку гипотезы Коллатца до определённого N:
Сортировка пузырьком:
Кроме того, при ручном написании кода мы неизбежно играем в перебор, надеясь эмпирически найти оптимальный код (который совсем не факт что будет быстрым на другом железе). Когда речь заходит о брутфорсе, в это непременно должен вовлекаться компьютер, так как у него для этого существенно больше ресурсов. Выше Вы привели очень правильную мысль:
Так почему бы не дать компиляторам возможность генерировать разные вариации машинного кода и тестировать их самостоятельно? Да, среди этих вариаций может не быть идеальной, но возложив перебор на компьютер, мы сможем подойти к ней существенно ближе, чем перебирая варианты вручную.
Возможности оптимизации во многом зависят от того, что знает о коде компилятор. Может оказаться так, что в Rust больше возможностей дать компилятору подсказку (либо же это получается косвенным образом, исходя из строгости языка), тем самым позволив ему создать более шустрый машинный код.
Но зачастую сделать такие подсказки без тщательного изучения алгоритма непросто.
Источник
У 96-ядерного предельная частота 3.7 ГГц против 3.2 ГГц у 192-ядерного, а мощность, как известно, зависит нелинейно:
где
— ёмкостная нагрузка, 
— напряжение, 
— частота.
Производительность напрямую зависит от частоты, однако с частотой приходится повышать и напряжение — в противном случае процессор будет сбоить (подобная проблема также возникает при чрезмерном андервольтинге).