2547. mrzet, 08.11.2024 19:57

144 метра кеша в десктопном консьюмерском проце, каково а? 5 лет назад синие бояре мне говорили: '1.5 метра LLC (L3) на ядро и баста!' Ну что, пришло время расплачиваться за свое высокомерие?!....

2557. mrzet, 09.11.2024 06:03

цитата: Так "повысила", что теперь 285K во многих рабочих задачах уступает 14700K и 13900K. Я уж молчу про игры, там у интела полный провал. Пришло время защищать чуть более слабого (а значит работать на конкуренцию что в итоге будет улучшать оба продукта). Он слабее потому что отбросил 'костыли' HT. Гиперпоточность, как показали прошедшие годы, немалое зло. Это с ее помощью в немалой степени стали возможны разные атаки на состояние проца. Гиперпоточность это ко всему прочему костыли для говнокода, потому как чем хуже код, тем большее преимущество он получает от гиперпоточности. Так что я согласный с таким решением (убрать оный срам из проца) Ну и это-выигрыш в секунду-две на компиляции в 42-44 секунды это притягивание за уши. Не уподобляйтесь бывшим синим боярам. Имхо Да и еще: будующие годы будут для Интел не из легких, но это неплохо, если посмотреть с другой стороны. В тучные годы Интел позволял себе такое... Я про начинания в разных сферах, которые с треском заканчивались не достигнув каких-то внутренних установок. Из недавнего-это фэкап с ИИ ускорителями, а из более старого - как Интел кинула поверивших в ее IOT решения. Вспоминаем фэкап с Октанами(чисто технически очень неплохой накопитель ведь был) . Очевидно подобные экзорсисы не будут возможны в период 'диеты' - что со всей очевидностью пойдет синим на пользу. Имхо

2560. mrzet, 09.11.2024 08:49

Я извиняюсь с Оптанами, опечатался в ночи

2576. mrzet, 09.11.2024 21:04

Ryzen 8845hs мобильный 45 ватт теплопакет. Проверка как выдерживает тяжелую нагрузку. 8 потоков кода с AVX-512 (черт бы его подрал, но уж есть, только на ядра без SMT). Турбины шелестят знатно. ~80°C. 4.4GHz проц идет...

2577. mrzet, 09.11.2024 21:10

+ вспоминаю как на форуме товарищ жаловался что на раннем серверном проце Интел у него частота на 1/3 упала и в результате от AVX-512 остался полный пшик ( даже если и был какой гешефт...) К сообщению приложены файлы: 1.jpg, 2482x1357, 727Кb

2579. mrzet, 09.11.2024 21:53

Давно слышим эти мантры, а эффекту - пшик. Но есть и обратная сторона медали:всеми этими мусорными расширениями ака AVX-512 так загадили кодовое пространство, что куда более разумному APX при EVEX-кодировании (инструкция со смещением и операндом константой) выходит ПРЕДЕЛЬНАЯ длина инструкции которую может взять декодер x86-x64(доп префиксы если что уже не лезут!) . Доигрались в маркетинг.... Готовьтесь к переделкам в декодере (не зря интел расширяет именно L1I, противу вроде как более подходящего случаю L1D). Говорил Фог:сперва крепко думать, и лишь подумавши, ставить расширения! Наляпали абы что.... Имхо

2632. mrzet, 16.11.2024 11:12

Вот вам технический анализ мертворожденного AVX-512. С ним и с AVX2(AVX-256). НИКАКОЙ разницы. Мертворожденное расширение - только зазря кушает кодовое пространство ( замусоривает). И главное даж Интел отказался от него ( но кодовое пространство не вернешь), и на тебе - та же дрянь теперь в райзенах... Слов нет ( не матерных) К сообщению приложены файлы: 1.jpg, 2560x1600, 650Кb, 2.jpg, 2560x1600, 671Кb

2635. mrzet, 16.11.2024 11:28

AlexKaz: 4 потока дал, потоку нужно 2MB L3 На CpuZ видно сколько у проца вообще L3 цитата: Почему не вернешь-то? Нет флага поддержки AVX-512 - используй как угодно. Я говорю о кодировании команд AVX-512. Для них новые опкоды были - и это отгрызает кодовое пространство у других расширений ( более продумчиво сконструированных). Очевидно пока в природе есть процы поддерживающие AVX-512, опкоды придется держать - их нельзя назначить другим командам. Так я хочу сказать что в планируемом APX длина опкодов для некоторых команд будет 15 байт - предельная для декодеров процов( а значит дальше - перепроектирование декодеров). Вот тебе бабушка и Юрьев День!

2637. mrzet, 16.11.2024 11:49

цитата: Объявляешь deprecated Очень смешно. Я объявляю deprecated? - со всей очевидностью такое г-но в продакшн выпускать нельзя. Но родят ли 2 крупные компании консенсунс по данному вопросу в ближайшее разумное время? - очевидно нет. Вы же видите - один отказался, второй лепит. Не в ближайшее разумное время - накушаться этих фекалиев все должны до рвоты - и может быть тогда.....

2650. mrzet, 16.11.2024 16:11

В сети есть забавный казус о том что Zen таки поддерживал FMA4 несмотря на отсутствие бита поддержки. О том как исторические наследия не отпускают своих обьятий. Поищите... https://en.wikichip.org/wiki/amd/microarchitectures/zen цитата: Note: WikiChip's testing shows FMA4 still works despite not being officially supported and not even reported by CPUID. This has also been confirmed by Agner here. Those tests were not exhaustive. Never use them in production.

2655. mrzet, 17.11.2024 08:30

цитата (SVG4K [source=8:26622:2653]): mrzet В сети есть забавный казус о том что Zen таки поддерживал FMA4 [source=8:26622:2650] Недокументированные команды, флаги и режимы ? Та нее, не может быть. Это неправда Флаги? Целый субсет оказался нетронутым хотя и deprecated и obsoleted и вообще его как бы нет. А из более старого история: LAHF SAHF и VMWare. Оптимистичны у нас товарищи....

2732. mrzet, 23.11.2024 12:26

цитата (Chudik [source=8:26622:2730]): цитата (https://www.ixbt.com/news/2024/11/22/ryzen-7-9800x3d-core-ultra-9-285k-cpu-amd-50-60.html): В среднем в 45 играх Ryzen был быстрее на внушительные 24%. А если отбросить десяток игр с минимальной разницей, то средний показатель вырастет более чем до 30%. В ряде игр разница достигает сумасшедших 40-50%, а в одной — 75%! Это, напомним, при сравнении игрового восьмиядерного CPU за 480 долларов с 24-ядерным флагманом за 630 долларов. По показателю 1% Low новинка AMD быстрее уже на 29% с пиковым преимуществом в 117%. Когда божественная интел убрала HT в новых процессорах, синие здесь орали, что это новое слово, "HT нинада!!!" Результат на лице. Поддерживаю Интел в данном начинании. HT - костыли. Мерзкие костыли для импотентов. Если не брать созданные по вине программеров фризы в играх (вот как то упоминаемые Victor91rus около 5 лет назад фризы в какой-то игре где взлетал вертолет-я запомнил! ), то HT дает иллюзию большей загрузки:то есть большая загрузка ядер, да, наличествует, но цена огромна-каждый поток кода начинает работать медленнее, чем без HT.

2740. mrzet, 23.11.2024 14:43

Да, интел пострадал, отбросив костыли, но в будующем это пойдет на пользу. HT/SMT имеет право на жизнь в процах до 4 ядер включительно. По идее процы с числом ядер менее 4 вообще не дожны быть в компах-их удел телевизоры/приставки/контроллеры и проч. Имхо

2751. mrzet, 23.11.2024 17:36

цитата: Это, прямо скажем, фигня. Недавно тестировали современные intel и amd, НТ\SMT приносит в среднем до 20% первым и до 25% вторым. Так что все эти вздохи непонятно о чем ничего не стоят. Проц используя HT/SMT правильно балансировать не может потоки кода(потому что они для него на одно лицо)*. И в результате зарядив два потока с качественным целочисленным кодом на одно ядро, получит снижение скорости обеих вдвое. Это проблема та же что стояла перед первым внедрением гетерогенной структуры. Что должно там грубо идти на e-ядра? Код что много считает, данных много не требует, может быть высоколатентным(какая нибудь заранее распаковка текстур если это игры) . При большом кол-ве ядер это уже не имеет значения, а показанные 20-25% общего прироста имеют высокую цену в виде снижения скорости в случае один поток кода/одно физ ядро. Если вам рендер-ферма или компилинг-ферма нужна вы же будете уповать именно на ядра, а не использовать низкоядерные процы с SMT/HT. В низкоядерных процах гиперпоточность-костыли что изначально скрывает их немощность. Скажем для обычной офисной машины 4ядра/8 потоков еще может иметь смысл, а 8-ядернику подобное не нужно. И да, гляньте там AMD для Asure делал-нафиг выбросили балласт SMT. *-фактически мы должны иметь метаописание потоков кода включенное в бинарник, и все это скармливаться планировщику. А иначе в пару на ядро может ставиться 'ка зна що'. То есть Thread Director это запоздалый жест, все должно было быть сильно раньше. Когда мы получали одновременные плохосовместимые (по использованию ресурсов) потоки HT/SMT-это еще ладно-технология виртуальная, затраты низкие-нет профита-пофиг, но когда пошел гетерогенный кремний-тут уж надо было костылям приделать еще костыли в виде оного Thread Director'а(иначе народ не поймет). Имхо

2754. mrzet, 23.11.2024 18:20

цитата: Не говоря уже о том, что программист с мозгами вполне может поручать второму потоку не такую же работу, как первому (это самый дурацкий вариант), а другую (в том числе служебную: подтаскивать данные, дальше обрабатывать результаты, и т.д.) цитата: Но здесь много проблем, и основная здесь добросовестность программистов. Есть 99,99999% уверенность, что многие этого делать не будут, даже если будет соответствующий инструментарий. Matik! Ну так всеж они с мозгами, или 'ленивые твари'? И ведь такой ваш дуализм в одном посте! Если два потока будут использовать одни и те же ресурсы ( оба использовать близко к пределу плавающую точку) - то они провалятся в HT/SMT вне зависимости какой бы работой по алгоритму не занимались. Потоки HT/ SMT дадут эффект когда они используют разные EU(хотя бы) проца.

2762. mrzet, 23.11.2024 19:03

цитата: А вот обыкновенный, рабоче-крестьянский код в обыкновенном ПО, как правило, далеко не оптимизирован до предела. Так что спокойно выигрывает от НТ\SMT. Плохо-оптимизированный код - это допинг*. А допинг разлагает. *-и ведь все знают что качественная оптимизация нужна только в 'горячих точках' а далеко не везде. Пофиг как написано 90%кода, но там где 10%кода считают 90-95% всего таймлайна-вот там надо покорпеть, и костыли не потребуются. Имхо 2Chudik: Везде HT/SMT отключается в BIOS/UEFI впрочем обычный пользователь о таких аббревиатурах ни сном ни духом.

2764. mrzet, 23.11.2024 19:09

цитата: В этом смысле удивляет то, что, в общем-то, давно знакомую технологию, которая никому не мешала, и даже чуть-чуть помогала, зачем-то убрали. Тренирующий момент для говнокодеров-одно это стоит приветствовать. Так на это посмотри....

2773. mrzet, 23.11.2024 19:37

цитата (matik [source=8:26622:2772]): VLev и больше не будет. [source=8:26622:2771] Не стал бы совершать ошибки, и загадывать наперед Интел в последнее время такой внезапный, противоречивый Может взять и вернуть полюбившуюся массам НТ Вот это да. Шокируют такие метания.

2801. mrzet, 24.11.2024 20:08

Вот вам три случая (для понимания) : 1) поток целочисленного кода 1 имеет в случае запуска на одном ядре моно IPC=2.7(допустим). Допустим он использует почти только ALU(%загрузок/сохранений относительно основного расчета малый/ничтожный). Что будет если два одинаковых таких потока будут запущены на одном ядре(HT/SMT) ? В ядре 4ALU и два потока такого кода смогут утилизировать ~3.8/3.9 ALU в идеале. Поток моно IPC=2.7, два потока в гипертрейдинге получат IPC=~1.95 (3.9/2)то есть производительность каждого потока упадет до~67% от номинала. 2) на одном физ ядре запускаются 2 потока кода. Один целочисленный из примера выше, другой молотит на 99% плавающую точку с IPC=2 и тож требует мало загрузок/сохранений. ЕU целочисленные и FP разные. У потоков почти не упадет IPC при запуске в HT/SMT но может быть перегрев ядра и троттлинг (хоть это и другая история) 3) на одном физядре запускаются два целочисленных потока имеющих один и тот же тип вычислений но в силу зависимостей в коде имеющие в запуске моно низкий IPC=0.95. Они практически не потеряют от своей скорости работая в гипертрейдинге /SMT, потому как даж оба параллельно не могут выжрать даже рядом ресурс физ ядра по исполнительным блокам. Из очевидных фактических примеров - архиваторы. Говоря совсем по простому:если код потока использует в среднем не более половины от трех сущностей (порты целочисленные они же ALU, порты работы с плавающей точкой FP, порты загрузки/сохранения Load/Store) то при запуске с подобным компаньоном-будет профит и не будет падения. Если же поток кода активно использует одну из 3 сущностей-то есть более чем наполовину от физ ядра-он может просесть и чем больше использует тем больше может просесть. То есть HT/SMT-костыли для кода с низким IPC('рабоче-крестьянский') , а код с высоким IPC(оптимизированный, 'хороший') они наоборот могут 'попортить'. Вот в чем основной сарказм...

2803. mrzet, 24.11.2024 20:54

цитата (bess_temporary [source=8:26622:2802]): mrzet > Говоря совсем по простому:если код потока использует в среднем не более половины от трех сущностей (порты целочисленные они же ALU, порты работы с плавающей точкой FP, порты загрузки/сохранения Load/Store) то при запуске с подобным компаньоном-будет профит и не будет падения. [source=8:26622:2801] То номинально (в идеале) он сможет добиться благодаря HT двукратного прироста производительности В идеале - да. Но где идеал? Для этого аналог Thread Director должен был появиться с выходом PIV который впервые имел гипертрейдинг (это более 20 лет назад, я даж не помню точный момент). Это также означало бы что при компиляции создавался сегмент метаописания потока кода, который бы должен был взаимодействовать - >Thread Director->планировщик ОС. Но этого не сделали и пустили все 'внавал'. Поскольку технология дешевая, огранить ее до состояния бриллианта никто не удосужился. Помощь в планировке потоков родилась только с появлением гетерогенного кремния (там подход 'внавал' был бы уже наглостью высшего порядка). Имхо

2806. mrzet, 24.11.2024 21:53

цитата: Да и не сможет. Как я уже сказал:никто не удосужился. Можно было бы даже обойтись без сохранения характеристик кода на этапе компиляции и 'Thread Director'. Но тогда вся нагрузка легла бы на ОС. Но все возможно: название процесса и адрес системного вызова создания потока дают хеш профилируемого поначалу потока кода. ОС в первые несколько запусков потока снимает основные метрики в режиме профилирования, а впоследствии уже куда как разумнее может ставить в пару то что программер не дотумкал назначать через аффинити. Вот вам и профит. Никогда не говори никогда....

2809. mrzet, 24.11.2024 22:28

Хеш-сделайте его 256 битным, это уникальный адрес потока для всего софта в системе, вангую будет уникальным. Это ключ массива профилировки для планировщика. К хешу клейте результаты профилировки: основные метрики там: тип команд (используемые порты), достигнутый IPC,..... Вот вам и инфа для того что можно параллелить а что-не стоит.

2811. mrzet, 24.11.2024 22:43

цитата (bess_temporary [source=8:26622:2810]): То есть несколько десятков мегабайт для начала? С чего бы? 'горячие точки' - первый проход. На второй проход снимаем используемые порты (что дает тип команд) и IPC в горячих точках. Там десяток-другой байт на метаописание горячих точек+ключ уникального потока в системе(64байта)*100000(допустим потоков вообще в системе, хотя кол-во такое скорее на порядок ниже) =~8.5 мбайт вся таблица в совершенно гипотетическом случае(100000 потоков это сюр) Дальнейшая оптимизация: по найденным оптимальным парам хранится возможные пары ключей оптимального запуска, здесь уже даже не нужно делать обработку, только поиск. И да, помним, что пара тысяч тактов (попервоначалу) для поиска оптимальных пар будут компенсированы увеличенной скоростью оптимально подобранных потоков. Все эти мысли смысла имеют мало:необласканное дитя (HT) уходит в историю со всей очевидностью....

2817. mrzet, 25.11.2024 05:30

цитата: Я не понял = вы, что, хотите потактово синхронизировать два потока на одном ядре в HT? Из каких моих слов это следует? В 20 байт инфу для этого никак не заложить. Хотспоты (горячие точки) - это там где 'мякотка' - малые по обьему куски кода что много считают. Пофиг абсолютно как написан код обвязки, что в таймлайне расчета занимает 1-5% при общей 'массе' 90-95%. А вот 5-10% горячих циклов (обычно) считает тот код что нас интересует. Допустим у профилируемого потока кода используются по этой профилировке на 'всю железку' порты Load/Store в горячих точках(ну он чего-то копирует) . На второй запуск мы это поняли-и отныне планировщик НИКОГДА не поставит на одно физядро данный поток с компаньоном у которого ресурс Load/Store используется так же активно. А в компаньоны будет подобран поток у которого наоборот Load/Store низкое. То есть планировщик отпрофилировав хотспоты, создал и наращивает 'карту' возможных потоков в системе. По этой карте он ищет оптимальных компаньонов для запуска на одном ядре-потоков кода с разноплановым (и возможно предельным) использованием тех или иных ресурсов, оптимизируя качество работы HT/SMT. И тут огромное поле для прочих оптимизаций этой карты (о которых нет смысла писать в коротком посте) Момент номер два:хеш (как идентификатор/ключ такого потока) в 256 бит избыточен, здесь достаточно и 128 битного хеша. Это так как надо было сделать сразу, 'огранить' технологию, получив 'бриллиант' из обычного алмаза. Так не сделали, обезличенные потоки 'внавал' (абы как, без учета их характеристик) кидаются на одно ядро. И в результате нет оптимального использования. А иногда и значимые просадки.

2819. mrzet, 25.11.2024 11:59

цитата: Простите, у вас в вычислительном коде все потоки РАЗНЫЕ? Мы не ваш кластер рассматриваем ( где один код на все ядра ), а обычную систему. И там да, каждый поток имеет свой 'рисунок' кода. Свои наиболее используемые ресурсы, свои узкие места -у каждого потока. А в именно вычислительном кластере - там это не нужно. Во первых код пишется оптимально ( надеюсь) и как следствие ему не найти пару ( все потоки одинаковы пока одна задача). Потому то HT/SMT и не востребован там изначально - все считается 'вчистую' на физядрах.

2821. mrzet, 25.11.2024 13:05

цитата: Вы в соседние HT-потоки на одном ядре запускаете разные задачи? Нахрена? Во первых не я так делаю а система. Вы пишете на своем десктопе код для кластера. Запустили в 4 потока ( к примеру) - на разных ядрах, тестируете. А система добавит системный поток кода еще одним HT-потоком на ядро на котором вы считаете и который там производит оптимизацию использования памяти к примеру. И это просто факт( не зависящий от желаний mrzet или bess_temporary). В вашем десктопе крутятся сотни потоков ( и системных в том числе) и они просыпаются по своим условиям и тоже считают ( это открытие для вас видно?). То что я описал выше - это как бы было идеально использовать HT/SMT с самого начала не допуская соседства на одном физядре потоков потребляющих одни и те же ресурсы ( чтобы не допустить просадок производительности в случае высокооптимизированных кодов)

2823. mrzet, 25.11.2024 13:23

цитата: Они не крутятся, они спокойно себе дрыхнут. Потребляя суммарно дай бог полпроцента. Ну вот сейчас фоновая загрузка у меня плавает от 13% до 18% на 4/8. Система 2-3% и остальное браузер ( который у каждого) потихоньку жрет. цитата: Но такого и не может случиться, ибо на практике в реальных задачах загрузка ФУ в разы ниже предельной. Все уже поменялось. HT уходит в историю. Костыли отброшены. Хочешь быстрый код - максимально полно утилизируй ФУ. цитата: Ну и, высокопроизводительные коды не запускают в одном ядре с каим-то соседским говном вот здесь согласен ( концептуально).

2824. mrzet, 25.11.2024 13:27

+. Фоновая загрузка системы. Не святым духом утилизируется же... К сообщению приложены файлы: 1.jpg, 1920x1080, 371Кb

2826. mrzet, 25.11.2024 14:17

цитата: Это у вас дерьмовые "Виндуза"? И вы собираетесь для них что-то оптимизировать... Были бы дерьмовые - стояло бы другое. Оптимизировал и не раз и удачно. Человека сперва руки красят а лишь потом инструмент....

2833. mrzet, 25.11.2024 15:16

цитата: привёл пример системных расходов более 9 процентов и этим мотивировал необходимость своих оптимизаций Человек в годах вроде, а как вывернул? Оказывается все это говорилось чтобы якобы ускорить полутруп* что не жалко и выбросить. Выхлоп в лужу короче. Я знал что с bess говорить - только время терять.... Впредь буду умнее. * - мне приходится кодить и интерфейсный код и вот пародоксально что лучше это делать не на быстрой машине. Да, сборка Webpack'ом занимает время но зато ты сразу тестируешь на медленной машине и если выходит быстро то на быстрой машине точно тормозов не будет. Потому у меня на вооружении старый ксеон.

2855. mrzet, 25.11.2024 21:02

цитата: Вот я и спрашиваю вас - критиковать Интел за это будете или одобряете. Ответьте просто и односложно, ничего не усложняя: Да, критикую или Нет, одобряю. Вот и всё. Забыл 3 вариант:работаю по методичке и как флюгер:куда ветер дует туда и верчу.

2910. mrzet, 26.11.2024 11:14

цитата: И да, и нет. Никогда не стояла задача "интегрировать самое производительное решение", именно по причине TDP и ПСП. Задача-минимум звучала так: дать решение, на минимальном уровне подходящее для бытовых задач. И в части случаев большего не надо. У меня встройка в 8845HS ( 780 ) выжирает весь оставшийся теплопакет при волосатом кубике. То есть одно CPU ядро загружает всю отрисовку, а оставшиеся ~40 ватт жрет встройка. И 30Гбайт/сек лимит полосы для GPU. Ни рыба/ни мясо. Вот оно мне зачем такое? Очевидно когда берут встройку нужно качественное 2D ( и мультимониторное) и простенькое 3D ( для браузера). Нужно серьезней - бери с дискреткой. А жрать 40 ватт для встройки -верх расточительства в ноуте. Пока не нашел как залочить для GPU лимит потребления....

3064. mrzet, 15.12.2024 23:49

У Zen5 меньшее потребление что позитиф сразу (и для кошелька). 'Удвоенный AVX512' что не раскроется при нашей жизни - с момента выхода оного мне в пример привели пока лишь цельных ДВА приложения что имеют от него профит( а вот многочисленные тесты не в счет - от них нет профита). И некоторые плюшки что будут полезны при усложнении кода впредь - а вот это может раскрыться и при нашей жизни ( aka двойной декодер). Имхо цитата: У 14500 их аж 14 штук, но разных 6P+8E. Польза от этих ядер может проявиться только в таких многопоточных приложениях, как рендеры, кодировщики видео. и при многопоточной компиляции крупных пакетов/исходников. Где частота не роляет сильно, а ядра роляют. Круг потребителей подобного узок и далек от львиной доли коньюмеров.

3067. mrzet, 16.12.2024 02:10

Компиляторы (в силу решаемых задач) относятся к коду где метрика кол-во условных переходов/к прочим командам однозначно высокая. Как следствие сброс конвеейра из-за неверного предсказания выше чем у более линейных кодов. Такой код хорошо идет под HT/SMT, да. цитата: а вот то, что это ни разу не Raptor Там вон до сих пор непонятно что творится:то ли деградация, то-ли загрязнение, то ли недопиленные BIOS/UEFI. Нет даже гарантий за камни без литеры K. Г-н Omega говорит что глючат/дохнут даже ноутбучные рапторы. Надо смотреть, как энтузиасты порешают вопрос, рекомендовать стремно. Пока. Имхо

3079. mrzet, 21.12.2024 21:28

цитата (Андрей Рем [source=8:26622:3078]): Ребят подскажите что сейчас из мобильных процов лучше 155H или 8845H? У меня ноут на 1145G7 был так вот он нормально на полную мощность никогда не работал, максимум что я видел это 3.4GHz Привет. Слушай за 155H сказать ничего не смогу, а 8845H-звереныш. Плотный AVX2 код молотит на 4.4Ghz(на всех ядрах сразу). 780 встройка 8845H избыточно мощна для обычных применений, но не дискретка для игр(тут ее мало). У себя не нашел где зажать на нее мощу (что недостаток!)- потому как волосатый кубик сожрал 1 ядро для подачи команд на отрисовку а ВЕСЬ остальной теплопакет сожрала встройка. Вот я и думаю - будешь смотреть какой сайт - там убогонькое 3D, и тут твой проц внезапно сжирает все 45 ватт. На практике еще не было, но вдруг? Интеловские ириски в этом смысле несколько лучше (хоть и менее производительны, так и не настолько прожорливы) Имхо

3083. mrzet, 21.12.2024 23:13

2Андрей Рем: Ninkear A16Pro

3086. mrzet, 22.12.2024 11:47

Интел (до этих Лунар Лейков и то поглядеть надо) не умеет в энергоэффективность глядя на мобильные алдеры (и рапторы видно очень похоже будут). Ноут жены:12450h расчет неудобного AVX2 кода:4 ядра*, теплопакет 24 ватта:ядра идут 2.8-2.9GHz. Результат 2400 сол/сек. Верхняя температура 85°C Прям тут же ноут на 5800U(Cezanne) : теплопакет 15 ватт: 8 ядер идут 2.75GHz. Результат: 4000 сол/сек. Верхняя температура 82°С В десктопе, где потребление разжато-они могут, где на голодном пайке - алдеры (и рапторы) не айс. P. S. Ядро Gracemont(E-ядро) в алдере жрет ~1 ватт, сезанн (полноценное ядро Zen2 мобильное) ~1.4 ватта. Это хеадшот для интела. В прежних архитектурах. И в основном это из-за толстого техпроцесса. Имхо *-P-ядро мобильного алдера жрет ~4.5 ватта, при увеличении потоков расчета E-ядра отбирают свое и расчет НЕ УСКОРЯЕТСЯ(на теплопакете 24ватт для 12450H), поскольку частоты P-ядер еще падают. Вообще, жесть. В мобильных алдерах да рапторах считать/компилить/рендрить надо на P-ядрах(т.е. инверсия). Благо E-ядер с остатками теплопакета хватает на интерфейс вполне. Вообще более одного кластера E-ядер в них (4 штуки) - чистый маркетинг. Имхо 12450H нужно полноценные 45-50 ватт исходя из виденного. Из рапторов видно не маркетинг 13620H (6+4) и им нужно ~80ватт. Ну вот какая тут энергоэффективность. Только на лунар лейки и надежа.....

3088. mrzet, 22.12.2024 13:15

Тестировать надо в самых зверских(неудобных) кейсах. Буде в них неплохо-уж в штатном коде будет замечательно. Подумайте над этим.

3090. mrzet, 22.12.2024 18:08

цитата: Для этого туда положили 8E ядер, которые вы, в своей бесконечной мудрости, не желаете задействовать. На скриншоте расчет только на E-ядрах 12450H. Если считать только на P-ядрах 12450H будет 2400сол/сек. Итого эффективность E-ядра падает до 40.6% от P-cоre. E-ядра особенно в большом кол-ве - не для счета. Потому они и не нужны в большом кол-ве. Их нужно 4 штуки (1 кластер) на проц, пока считается чего/компилируется ,у тебя инет читается, авер в фоне арбайтен, система пыхтит - но на расчете это почти не сказывается. А выше - чистый маркетинг К сообщению приложены файлы: 1.png, 2160x1440, 698Кb

3092. mrzet, 22.12.2024 18:23

цитата: А вот в синьке Е-ядра позволяют интелам обгонять амд. Или там не счет? это бенч, в бенче и подождать можно, не правда ли? подождите 5 часовой рендринг считаемый на P-ядрах перенеся их на E, и цифры из бенча будут вам припаркой на больное место. Монеро- очень чувствительный алгоритм. Вот для примера расчет в 8 потоков на 5800U - расчет в фоне и на переднем плане. 3.8% разницы за счет увеличенного (для процессов переднего плана) кванта времени( что уменьшает вымывание кеша). Мышью шевелишь- расчет просаживается. К чести алдера - на нем ниже - польза от 'простаивающих' E-ядер (что подхватывают интерфейс) К сообщению приложены файлы: 1.png, 1116x1068, 155Кb, 2.png, 1920x1200, 387Кb

3094. mrzet, 22.12.2024 19:09

цитата (Saturn [source=8:26622:3093]): mrzet Вот для примера расчет в 8 потоков на 5800U - расчет в фоне и на переднем плане. 3.8% разницы за счет увеличенного (для процессов переднего плана) кванта времени [source=8:26622:3092] у кучи другого счета тоже foreground process выигрывает у background process, прям как будто это что-то новое Здесь важно понимать что чем больше разница - тем больше влияние кешей ( обычно более объемных) на скорость кода. А другой куче алгоритмов на это пох. Разницу объясняю. Здесь же видишь моментально.

3097. mrzet, 22.12.2024 21:21

Ноут на 12450H - Chuwi CorebookX 14''. Что для жены. Вставил в него еще одну SO-DIMM 1-rank 16Gb на чипах Micron на 3200. Встала как влитая, SPD идентична(угадал, пришлось повыбирать) как в уже распаянной. Тормоза в изначально небыстрой графике GT2(встройка 12450H) подрассосались.Всего то нужно изредка популярные видеоформаты играть да в инете не тормозить-вполне достаточно, хотя, обьективно, ириски лучше. Памяти за глаза для Word, Excel, ведения домашней бухгалтерии,RDP,инет-32Гбайт. Твердотельник гут-map1202+B58R. Некоторый минус-слабоватая система охлада. 20 ватт-тихо, 24 ватта - приемлимо еще, выше-ж...па честно говоря. Экран отличный - 14'' полные 2K, звук средний. Всех затрат-41k рублей(400 бакинских) . Портативен, дешев, можно мотылять как хошь-нестрашно, ибо дешев. Ну проц конечно между 3+ и 4-,но хоть не маркетинговые экзорсисы как то 12700H, 13650HX и т. д. Имхо P. S. Жене ноут, мне же убежденному 'красному', поле для эксперимента над оптимизацией, которую обнаружил г-н Фог: Intel представила APX - расширение архитектуры x86-64, #184 (https://forum.ixbt.com/topic.cgi?id=8:26497:184#184)

3132. mrzet, 28.12.2024 21:28

цитата (BlazeBlaze [source=8:26622:3110]): и что самое интересное - искажение не в ту сторону. типа амд чаще берут для апгрейда - но тут что-то другое и че тут непонятного? 1/10* интеловских чипов 'окислится' и пойдет в мусорку - потому mobo меньше чем процов. *- цитата: CPU: Intel 45% vs цитата: Intel Chipset 40% пропорции указуют

3167. mrzet, 30.12.2024 13:58

В семействах AlderLake, RaptorLake, RaptorLake Refresh латентность L3 лежит средневзвешенно как ~60 тактов от частоты P-ядра. Девиация 54-80 тактов ( последняя цифра - предельный разгон). Для E-ядер латентность ~50-70 тактов что дает те же 60 тактов

3169. mrzet, 30.12.2024 14:14

Для кода с детерминированным (по времени) доступом к случайно извлекаемым данным, знание латенси кеша L3 (могущего единственно-однообразно обеспечить хранение массива таких данных) очень важно - позволяет прицелиться заранее. По E-ядрам данных очень мало (но есть слава богу). P. S. Самый высоколатентный кеш L3, в TigerLake медиана была 44 такта

3171. mrzet, 30.12.2024 14:38

цитата: Кстати, почему вы думаете, что латентность в вашем коде будет именно такой, какую показывает AIDA ?? Сотни мух (утрированно, но репрезентативность обеспечена таки) не могут ошибаться. Очевидно придется взять максимальную оценку в 80 тактов( при темпе IPC=~3.5 это ~280 команд)

3173. mrzet, 30.12.2024 15:05

цитата (bess_temporary [source=8:26622:3172]): mrzet > Сотни мух (утрированно, но репрезентативность обеспечена таки) не могут ошибаться [source=8:26622:3171] Сотни мух используют примерно одну и ту же методику для измерения латентности (я и сам её использвал). А реальные условия на фоне расчёта и других обращений в кэши/память могут давать отличия. Другие варианты есть? Нет. Для пристрелки хватит. Недолет, перелет, а затем ~1-тонная болванка бьет в стык бронеплит, и вуаля Худ санк.... Здесь ключевой момент:должно хватить сверхоперативных локальных переменных для опережающей загрузки*(лишь тут может быть 'недолет', 'перелет' не так страшен-фактически будет запас для ArrowLake где латенси именно LLC еще выше) . Кол-во команд в каждой итерации цикла определяет за сколько итераций цикла надо начинать предзагружать. Соответственно расчитанный интервал загрузки определяет и кол-во 'нанонитей' в самом цикле и итераций цикла до поступления данных в максимальную локальную близость к вычислителям (это связанные параметры и для этого и нужны сверхоперативные локальные переменные, кои мы обсуждали в теме 'расширение APX'). Там на весь код-один условный переход что предсказывается на 99.9%, все остальное масками и CMOV'ами (цена миспредикшена для такого кода безумна). *-чем выше латенси хранения массива случайных чисел (выборка их тоже может быть случайной) тем больше (при прочих равных) требуется сверхоперативных локальных переменных.

3175. mrzet, 30.12.2024 17:06

цитата: mov dword [rsi], eax add dword [rsi], 5 mov ebx, dword [rsi] Слушайте это уже не смешно. Это выполняется за 2 такта на зен2 -это факт/постулат. Данные уходят в память (но по факту в L1, и когда-то достигнут памяти, хотя именно этот последний аспект нам не интересен).Цена этому 4 такта. Следующая команда самая сложная в рамках x86-x64 - load-modify-store. Я даже не помню навскидку ее латенси- но в лучшем случае(!) это 8 тактов ( 4 загрузка из L1 и 4 сохранение обратно, модификацию я не считал - а по идее это еще 1 такт) - итого 8/9. 3 командой мы вновь загружаем только что сохраненное значение - еще 4 такта. Итого, не будь MemoryMirrorOperand вышло бы 16 тактов как по мне. Фог говорит: 15 clock on Zen 1 и на интеле ( до IceLake?/TigerLake) А в результате всего 2( Zen2,Zen4 и выше, интелы от IceLake?/TigerLake) . Очевидно это невозможно не оставайся это значение ( что сохраняют,считывают-изменяют-сохраняют и вновь считывают) в максимальной локальной близости. А значит это может быть только теневой регистр - и пока неважно идет чтение из элемента store-buffer (как считаете вы) или из теневого регистра PRF сопоставляемого для данного store-buffer ( как считает Фог). Для чего эта команда: add dword [rsi], 5 - вот ваш сакральный вопрос? Поясняю, хотя и говорил ранее - она максимально рельефно подчеркивает преимущества технологии MemoryMirrorOperand. Потому что 2 такта к 8 это неплохо, а 2 такта к 15 -это БИЛИССИМО. Но конечно он мог бы и так: цитата: mov dword [rsi], eax mov ebx, dword [rsi] 2 такта c технологией MemoryMirrorOperend, 8 тактов без нее. По факту если вдруг этих рамках действует идиома элиминации копирования регистров то формально это могло быть и 0 тактов ( для значения в EBX, а когда то потом через 2 с лишним сотни тактов данные окажутся и в памяти - что нас мало интересует) Пока эта технология лишь немного ускоряет работу внутри функций/процедур/методов. Но чем больше обращений к локальным переменным- тем больше ускорение. И чего можно добиться с ее помощью стыкуя ее к технологии кода с предельным IPC

3177. mrzet, 30.12.2024 18:00

цитата: то есть имеем mov ecx, eax; add ecx, 5*. Вот только незадача - РОН всего 15 ( в x86-x64 и не использовать RSP, а иначе - все 16 РОН- заставляет на время в принципе терять доступ к стеку). И если вы ставите цель - предельный IPC ( и не отступаете от нее!) то вам чтобы рисовать вашу картину/алгоритм- всего 15/16 кистей. Потому так важно иметь большое кол-во сверхоперативных локальных переменных, потому что значимые фактические алгоритмы вы 16 кистями не нарисуете. Для этого( из-за малого кол-ва архитектурных РОН) приходится сохранять/а потом и извлекать значение РОН в/из локальную переменную и раньше это было дорого ( для кода с предельным IPC), а с помощью MemoryMirrorOperand ( так ее назвал Фог)это будет сильно дешевле. Собственно еще и APX расширит кол-во архитектурных РОН до 31/32, вкупе c хранением в XMM-векторах и собственно самой MemoryMirrorOperand - будет отличный( и давно востребованный) инструментарий. Имхо * - сохранять РОН в другом РОН - транжирство чистой воды ( или академический код). Для реальных алгоритмов каждый РОН- бесценен! цитата: А я спрашивал? да раньше в теме про APX ( у нас все ходы записаны)

3179. mrzet, 30.12.2024 18:43

цитата: Это вы к чему? Собственно ВСЕ ( поскольку архитектурных мало) РОН хранят свои значения необходимые для алгоритма( потому просто нет свободных куда можно на время закинуть значение другого), и да, со времен i860 мало что изменилось в планировании: цитата: разрисовывать потактовую диаграмму использования этих регистров, когда ничего никуда не лезет, а время выполнения не хочется увеличивать ни на один такт потому РОН приходится сохранять на короткое время и тут же назад извлекать( потому что в промежутке между этими операциями он потребен в другом расчете). Потому и нужны места хранения ( сверхоперативные переменные)со скоростью физических регистров ( ака PFR). Только вот со времен i860 добавилась одна гиперцель - считать на предельно возможных скоростях с максимально доступной параллельностью - и не отступать от этой цели. И это таки возможно.

3181. mrzet, 30.12.2024 18:57

цитата: там, где дают (типа перемножения матриц), не упираются в регистровые и тому подобные ограничения. газодинамика, моделирование формирования вселенной и подобные расчеты ( на FP ) - не моя зона интересов.

3184. mrzet, 30.12.2024 23:19

2Reasonable Так, не вешать нос, скоро новый год! Если брать что-то чтобы не вляпаться в свежие косяки ( еще не вскрытые) берете ноут с процом ~двухлетней давности - все они за исключением младших моделей процов достаточно производительны ( для 90% применений). Два года - другие обкатали и не вляпались.

3187. mrzet, 30.12.2024 23:34

Omega ( а это весьма продвинутый участник форума ) говорил что рапторы и раптор рефреши глючат/дохнут и в ноутах. Так что если вам максимально безопасно - то обошел бы мимо ( береженого бог бережет). И да, для человека вынужденного 'экономить на спичках' вы что-то шибко круто замахнулись на 14900HX? цитата: Ну, а i9-14900HX подходящий или нет? Вам Ferrari или таки ездить?

3189. mrzet, 30.12.2024 23:45

Опять вы соврамши. Плохо и нехорошо! Я помню и это главное, а вот и 'пруфъ' ( поиск в этой конфе еще хуже чем ее адм....) Процессоры Raptor Lake LGA1700 (на архитектурах Raptor Cove / Gracemont) (часть 2), #6149 (https://forum.ixbt.com/topic.cgi?id=8:26624:6149#6149)

3192. mrzet, 31.12.2024 00:22

Значит запомните все эти 'тормоза' на гетерогенном железе-это проблема Интел потому что никто кроме нее такой кремний не делает(в x86) . Причем как утверждают другие весьма продвинутые участники форума (конкретно упоминать не буду чтобы меня тут не 'лечили' ) именно на раптор/раптор рефреш эта проблема минимизировалась настолько что они не замечают влияния Е-ядер (которые в рапторах подтянули по производительности). Таким образом выбирая интел есть дилемма:алдер но недохнущий но возможно с подтормаживаниями(или надо тюнить) , или раптор где шанс сдохнуть выше но не тормозящий. У амд такой дилеммы нет. И хочу заметить что выбирая ноут с дискреткой вы рассчитываете видно играть-а вот тут я вам не советчик (бо не проф игрок-а здесь важнее их слово). Если для работы то остановился бы на варианте AMD R5-8645HS (чисто по процу). Игровые ноуты не мой конек-вам надо просить совета у 'игроков' Имхо

3206. mrzet, 31.12.2024 08:47

цитата: ну часто лептоп кончает свою жизнь от кофе или чая Это у вас в америгах они сгниют на помойках (а ведь зачастую вы свой мусор еще и Африку отвезете чтоб у самих почище было). В этом году принесла такой Macbook сотрудница, ее богатый родственник 'накормил' макбук кофием через клавиатуру, ну и отдал просто так родне победнее. Конфигура там для инета/пишмаша была еще ничего по текущим меркам(i7) , так что получил бедняга замену клавы, поновление софта и извольте трудиться. А в америгах точно бы уже гнил в помойке, хотя еще рано... цитата: ещё ставят ноут на одеяло и т.п. И так было-видео смотрели по выходным ставя на мягкий диван (хотя предупреждали что нефиг перекрывать вентотверстия). В результате недешевый реболлинг(к аппарату привыкли как к старым тапочкам) .... Сообщение назвали неудачным: clawbug, Yahman

3208. mrzet, 31.12.2024 12:11

Из пародоксальных случаев помню разряд в ноль аккумулятора (лайт бизнес 14'' Asus на i3) купленный внуку одной из сотрудниц для удаленки на ковидлу. Первая часть ковидлы закончилась и его в ящик стола кинули, а акк подразряжается потихоньку. Не юзаешь - достань раз в месяц, кинь на зарядку на пару часов. Этот лежал более 9 месяцев. Тут вторая ковидла, а акк не заряжается, потому что контроллер заряда не стартует, потому что акк в ноль-замкнутый круг. В обычном сервисе говорят-сделать не можем, он свежий/нераскопанный. В фирменном сказали полцены, а когда подобрели и заявили 1/4 цены, согласовал без заказчицы. И крестник мой (студент) попалил ноут на 5700u-ну с морозу слишком быстро включил(хотя предупреждали) . Обошлось заменой цепей питания и умеренной ценой, а в фирменном сервисе сразу мамко предложили сменить(с соответствующими издержками). Говорю чтобы товарищи покупатели мотали на ус-где грабли лежат....

3264. mrzet, 02.01.2025 12:34

Вероятно разумным пределом для ноутов на интеле служит 13620H. 14900HX-сильное баловство, если его раскрывать не потянет ни одна система охлада(в ноутах) . Но конечно если все проблемы по глючилову/сдыханию для раптопов будут решены. Имхо 6P-ядер и приличная ириска (для всего кроме игор). Считать тяжелое нужно на P-core, а 1 кластер E-ядер даст возможность обслуживать интерфейс системы (работать в инете, фоновая активность системы и обслуживающих задач) не мешая расчету. Эффективность E-ядер в наихудшем случае ~40% от P-core, и таким образом кластер эквивалентен 1.6P-core. В идеале этому кластеру бы 4Mb L2 (как в 14 семействе то есть некий условный 14620H) и это было бы наилучше сбалансированный проц интела для ноутов(из текущего). Имхо

3481. mrzet, 21.01.2025 07:08

Латентность LLC и памяти в Arrow не дают интелу возможность удолетворить игроков. И это мимокодами не исправить. И если с латентностью памяти в тайловом процессоре было ясно что относительно монолитов лучше не будет, то с кешом LLC (L3) Интел 'заигрался' до невозможности. Латенси (средняя) до L3 у Zen5 - 48 тактов, у интелов ровно наоборот-84 такта. Я не говорю о том что делать предвыборку программерам за кол-во тактов вплотную приближающихся к 100 просто неудобно, достаточно что это говорит софт (с его результатами). При том Zen5 может предложиь метрику в 12Мбайт L3/ядро для 8 ядер сразу(X3D) , на что интел не способен. Просто когда некоторые заявляют:'госпаде, что там +лишних 10ns к латенси L3-фигня какая' , помните что они врут. Нагло и беспардонно. Помнится один оборзевший персонаж бил себя пяткой в грудь и кричал:'для игор нужны туевахучагерцы и ничего другого!'. Жизнь показала что игоры любят кеш и не любят оборзевших))) И главное, выпуская патч Интел говорит:' для повышения производительности в играх'. Но специальный игровой процессор им сделать видите ли сложно. Двоемыслие в чистом виде. Как надо игрокам: 8 ядерник, выбросив E-агенты (и сами E-ядра)-сузив кольцо, подтянув ему 'булки' , латенси LLC 48-52(последнее максимум!) такта, метрика LLC 8Mbytes/core. Вот что нужно игрокам от Интел, а не мимокоды....

3485. mrzet, 21.01.2025 11:48

цитата: если игроки забыли купить RTX 4090 - то их ничем не удовледотворить скорее всего для удовледотворения у них "нет деньгов" Я же не игрок - мне просто их 'вой' 5-летней давности до сих пор в ушах стоит. По первому пункту ты прав, по второму - им самим решать ( в чужой карман глядеть грешно). По крайней мере то что сказано про этот 'гипотетический' игровой 8-ядерник - это квинтэссенция их пожеланий. А Интелу надо смотреть на продажи и помнить что решают потребители а не свой маркетинговый отдел*. Имхо * - задача маркетингового отдела брать пожелания потребителей и облекать их в восхитительную 'упаковку', а не пытаться придумать свою реальность и 'вариться' в ней. Как видим интеловский супец берут не очень.... Когда мы слышим два заявления: 'LunarLake продали больше чем ожидалось' и 'мы не будем впредь делать такую упаковку' - рождается вопрос: 'вы идиоты или как?' Пытаться отлить против ветра никогда до добра не доводило. Имхо название придумал такого гипотетического 8-ядерника для игроков - Intel One© . Помощь импотентам из маркетингового отделу.... За это сообщение сказали спасибо [2]: Mim0kr0k0dil, zepp111

3487. mrzet, 21.01.2025 12:26

цитата: и сверху полирнуть hmb памятью К этому промышленность ПОКА не готова ( как и бюджеты игроков) цитата: Эмейзинг же (с) Вся паства уже у Аппла. 2Saturn: А вот когда на презентации оного игрового проца Интел возникнет вопрос: 'а почему такое пафосное название Intel One©?' - то отвечать надо так: 'название взято таким потому что мы первый раз наиболее полно учитываем пожелание такой важной части аудитории - игроков ( и обворожительно улыбнуться)' И именно так а не по другому.

3491. mrzet, 21.01.2025 17:34

2Saturn: Надо ли говорить что тайл iGPU и NPU из SOC в минус в таком гипотетическом проце? Думаю не надо. Весь балласт - за борт!

3674. mrzet, 09.02.2025 17:53

IrfanViewer-77метров(с плагинами) , открывает все, кое чего из этого 'все' не открывает даже фотошоп. Давно уже мой стандарт.

3755. mrzet, 14.02.2025 23:21

цитата (matik [source=8:26622:3754]): Intel собралась разрушить господство AMD на рынке чипов для карманных игровых консолей (https://3dnews.ru/1118306/intel-sobralas-ustranit-dominatsiyu-amd-na-rinke-chipov-dlya-karmannih-igrovih-konsoley) Каждый должен выбирать задачу себе по силам, чисто чтобы пупок не развязался....

3774. mrzet, 15.02.2025 22:07

2Chudik: Не мытьем так катаньем ограбят тайваньцев в результате. Это как с Гренландией-сперва базы, а потом подавай им всю 'Кемска Волость' Второй путь тож озвучен - это пошлины на кремний от TSMC

3819. mrzet, 21.02.2025 05:59

2Чатланин: Это декодеры такие у старых процессоров, у ArrowLake уже 6-путный декодер, у Zen5 два параллельных 4-путных. У стрелы декодер очень сложный - 6 команд одновоеменно при переменной длине оных в x86-садо-мазо то еще. Схема в Zen5 хоть и кажется проще способна на более гибкие конфигурации как - то: Работа разных декодеров на разные SMT потоки (отсюда следует что от SMT АМД отказываться не планирует) Работа второго декодера 'вперед' по цели предсказанного/или даже непредсказанного перехода Вероятно в Zen6 концепция 'с двух рук одновременно' будет доведена до логического завершения.

3821. mrzet, 21.02.2025 07:12

цитата (bess_temporary [source=8:26622:3820]): mrzet Про работу декодера ‘вперёд’ вы загнули Как раз здесь видится замечательное поле для оптимизаций: Увидев значимые отклонения для предсказателя переходов внутри горячего кода (цикл) можно будет запускать оба декодера по разным ветвям кода. Одновременно. К моменту как будет понятно куда пошел переход, в кеше uop'ов будут обе ветки(не зря же кеш uop'ов растет от поколения к поколению) . Здесь гибкость техники 'с двух рук одновременно' будет очень востребована. Имхо

4020. mrzet, 06.03.2025 05:01

цитата: А у вас "все просто", как у зрителей телевизора Там каждый первый лучше политиков знает, как надо было сделать Со времен Рима, да, мало что изменилось, трибуны Колизея заменил диван, арену сменили на ящик с экраном, но зрители остались прежние. 'Хлеба и зрелищ' "Человечество любит деньги, из чего бы те ни были сделаны, из кожи ли, из бумаги ли, из бронзы или из золота. Ну, легкомысленны… ну, что ж… и милосердие иногда стучится в их сердца… обыкновенные люди… в общем, напоминают прежних… квартирный вопрос только испортил их…"©

4032. mrzet, 06.03.2025 12:42

Г-да, я просто прошу помнить несколько моментов: 1) просранное десятилетие когда АМД клепало 'бракованную' стройтехнику и конкуренцию составить не могло - оттого мы давились интелом который почти не прибавлял в производительности 2) уже хорошо то что маркетинг у АМД только в ценах а не в железе ( живительная конкуренция сделает свое дело - надо только чтобы был сильный конкурент) 3) проблема интела в том что у них маркетинг не только в ценах но и в железо прокрался 4) господи, спаси Интел, вразуми и наставь на путь истинный!, иначе зеркальное десятилетие повторится ( а никому из присутствующих это не нужно) Имхо

4034. mrzet, 06.03.2025 16:01

2HeinzGrenze уходим в офисе на Zen4 - приняли решение. с 5600G до 8500G = дает прирост от 14% до 15.7% ( в спектре наших задач) Алдер 12400 ( рассматривался тем не менее) проигрывает ~3% 8500G в однопотоке сборка на 5600G =45.5 тыс руб сборка на 8500G=50.5 тыс руб ( и кстати на один проточник меньше - всего два вентиля: кулер и в БП) p.s. Это вспоминая наш спор в другой теме где вы советовали обратить внимание на NUC-подобные машины. Мы сочли их малопригодными к ремонту - то есть они уступают десктопу. Имхо

4048. mrzet, 08.03.2025 14:19

2bess_temporary: Как то вы говорили( в этом смысле):'госпаде, да что там улучшилось то за счет архитектурных улучшений - слезы' Посчитал: 2012 IvyBridge --> 2022 Zen4. Взял лучшие тесты для Ивиков, минимально зависящие от L3, уравнял частоты в расчете и сообщаю: преимущество архитектуры 2022 года над 2012 годом - ~45% ( вместо Zen4 можно ставить AlderLake и будут минимальные расхождения в расчетах, Zen5 и Раптор увеличат эту планку - но у меня их нет). 4.5% в год Если же взять рост частот то преимущество возрастает до 2X (рост частот дает еще 1.38x).Срез взят по применяемому в офисе. Современные офисные процессоры двухкратно производительней i7 3770 (того же 'офисного'* ;) проца из 2012 года) *-вероятно применимость i7 3770 в офисе в совершенно лучшем гипотетическом случае была до 10-15%(больше не могу дать при всем желании, оставаясь обьективным) P. S. Это именно вычислительные мощности в однопотоке и напрямую в ускорение программ не переводятся. К примеру основная наша прога- CRM ускорилась на 29% несмотря на то что ускорение счета ~100%(2x ускорение расчета, 8500G играет против i7 3770)

4050. mrzet, 08.03.2025 15:34

цитата (bess_temporary [source=8:26622:4049]): mrzet > Как то вы говорили [source=8:26622:4048] Я этого не говорил. К тому же я не изъясняюсь ломаным языком :) > 4.5% в год [source=8:26622:4048] Это хорошо или плохо? :rolleyes: > Современные офисные процессоры двухкратно производительней [source=8:26622:4048] А им надо быть двукратно производительнее? Говорили и я найду (мерзкий поиск форума вываливает 24 сообщения по тем критериям что помню из вашего поста-я отсмотрю их и найду искомое-в крайний раз, впередь подобного делать не буду, у меня нет склероза).. НУЖНО. Чтобы впредь не было уродцев ака G4560(гиперпень Kabylake 2/4)в природе*-вспоминаю это г-но с содраганием, и ведь некоторые на нем работают до сих пор:down: Но мы вынуждены были его ставить тогда, выбора не было.... *-кастрат по L3-Каби не выигрывал у Core2 4 ядерника с 12Мб L2 кеша- а многие считали работу на Core2 более комфортной. Мерзкий обрубок.... Совершенный современный минимум работы в офисе это проц 4/4 с частотой от 3.6GHz (4/8,6/6,6/12 возможны, выше-избыточно) с метрикой 2Мб L3/ядро, это должны быть ядра архитектуры с производительностью равной (или выше) P-ядер TigerLake/AlderLake - Zen3/Zen4c, снабженный минимальной графической частью в эквиваленте 64EU как у ноутбучных ирисок Интела (или лучше) - и никто не скажет что плохо. Имхо

4221. mrzet, 06.04.2025 23:39

Задачи упирающиеся в ПСП памяти для обычного пользователя редки. На APU Ryzen Zen4(то есть где в силу обьективных причин требования к ПСП выше потому как проц+видимокарта как ~простая десктопная) зарядив волосатый кубик в высоком разрешении с 8 кратным оверсемплингом и дав 7zip на все потоки выбрал в пике 34Гбайт/сек. Для топовых интелов это ~1/3 их ПСП на лучшей DDR5. Если вдуматься то эту полосу может долгосрочно обеспечить RAID из 6 топовых(на текущий момент) NVME SSD- у вас нет такого массива? - зачем вам ПСП в десктопе выше 100Гбайт/сек?. А так лучший обьем памяти что может быть у вас в компе-хватает чтобы проц обсчитал/прожевал его за чуть более чем 1 секунду. То есть в десктопе просто почти нет задач где вся полоса может быть востребована. Потому именно в десктопе пофиг что у рязаней чуть ниже чем у интелов-все равно задачи смогущие использовать всю ПСП(особенно продолжительное время) в возможном домашнем применении--по пальцам считаны. Имхо

4223. mrzet, 07.04.2025 05:40

цитата (sberk [source=8:26622:4222]): То есть по вашим расчетам выходит что переход на ddr5 ничего не дает, так 34Гб/сек со свистом помещается в псп ddr4. И уж тем более маячащий где-то там переход на ddr6 тоже нафиг не нужон То что вы не сможете использовать в известных задачах всю полосу это факт, однако подумайте чем еще обладают более высокочастотные/современные комплекты памяти. Намекну у DDR5 организация фактически 4*32бит, а у более высокочастотной DDR4 можно поиграясь снизить латенси. Быстрее попасть в ядро каждому кусочку данных-вот квинтэссенция. То есть латенси в результате-вот основной смысл Но общая ПСП-вы ее не выберете никак дома, а вы почему то смотрите именно на этот параметр**. В профилировке обычно программы что плотно работают с памятью на процах а-ля CoffeLake жрут 4-5Гб/сек/ядро. Добавьте до 6Гб/сек/ядро для процов посвежее. 16*6=96 Гб/сек/весь 16 ядерный проц. - и это вопрос можете ли вы его на полную загрузить такими прогами. Реальная потребность в ПСП-это расчетные кластеры*, но там хоть есть носители/массивы которые могут обеспечить бесшовность для такой потребности в ПСП. *-то есть запуск задач подобного рода в десктопе скорее всего доли процента. И еще:если вы начнете на широких векторах например только суммировать(вырожденный элементарный случай) , то современный проц любой Интел или АМД выберет всю полосу в 2 потока/ядра. ;) менее чем за 1.5 сек просчитает вам весь предельный обьем памяти вашего десктопа-и что далее? **-резюмирую:при выборе памяти для домашнего компа исходить при достаточной полосе 6Гб/сек/ P-ядро и минимальной возможной латености оной. То есть для 'народного' 8 ядерника 50Гбайт/сек - за глаза. Поскольку между фактической потребностью и пиковой лежит 20x разница-то достаточно очевидно что данные в фактических алгоритмах используются многократно-и отсюда вывод N2-нужно брать процы имеющие максимальную метрику L3/ядро, потому как кеш еще в 5-6 раз сократит латентность в доступе к этим данным;)

4226. mrzet, 07.04.2025 09:37

Вы помните, главное, что не так давно а лимит ПСП (на низкочастотной DDR4) какой-нибудь Zen 1800 мог упираться. Собственно, фактические алгоритмы, лишь отображают зеркально все 'несовершенство' мира, потому обозначенный лимит в 6Гб/сек/ядро вполне обьективен. Двухканал DDR5 5600 и выше полностью снимает текущие потребности на 8-ядерник и еще смотрит вперед на 5-летку(если программеры будут рачительны и не начнется гонка кто больше даст/сожрет). В десктопе с выходом DDR5 задачи по ПСП перестали быть актуальными для чистых процов, имхо* *-потребности APU могут быть значимо выше. Собственно Strix Halo это показывает.....

4230. mrzet, 07.04.2025 10:49

цитата (KKV [source=8:26622:4228]): Сергей Не будет. Он почти не чувствителен к памяти. По крайней мере, 9800х3д точно. С 9950х3д не знаю, т.к. на него не так много обзоров было и у него 3д только в одном чиплете, а второй как в обычном 9950х. Скорее всего, если данные будут обрабатываться на чиплете без 3д, быстрая память сыграет роль в некоторых кейсах. mrzet А снижение задержек Вы принципиально игнорируете? Объективно, а главное значимо снижение задержек только из-за больших размеров кешей ( и умения программеров это использовать)

4237. mrzet, 07.04.2025 22:28

цитата: Уровень своих 8.5 ГБ/с я наблюдаю и в вдругом CAE-софте. Маловато будет 6 ГБ/c. это не совсем 'домашний/офисный', а именно инженерный софт

4244. mrzet, 09.04.2025 13:02

цитата (KKV [source=8:26622:4243]): ... Я бы посмотрел, как там Интел выкрутилась в новых процессорах, но они вышли настолько ужасными, что информация вроде бы есть, но её не то чтобы много. Не прям ужастными( если про ArrowLake), но явно два блока плохо реализованы: L3 - увеличенная латенси и кол-во слайсов кеша L3/LLC не кратное степени двойки - делают LLC кеш Стрел высоколатентным и главное: его почти невозможно использовать в полном объеме в малопоточных приложениях*. Ну и высоколатентный контроллер памяти - это уже всем известно. А вот от самх ядер до L2 ( включительно) - они сделаны очень хорошо. Имхо * - объем кеша который невозможно использовать ( латенси в такую локальность выше 120 тактов от ядра) колеблется от 10-до ~33%. Зависит сильно от адресов страниц что выданы под рабочий сет которому требуется кеширование - то есть объем этой высоколатентной части вариативен!. Грубо говоря, вместо витринных 36Мб L3 вы получите доступными от 24Мб до ~32Мб ( в ряде прог - и игоры в их числе раз 9800X3D - доказал свою востребованность в оных) - и это фактически рандом: какие адреса физ страниц выдаст ОС - такой объем кеша и будет доступным. Микроархитектура Lion Cove. Мобильные процессоры Intel Lunar Lake / десктопные LGA 1851 Arrow Lake , #2587 (https://forum.ixbt.com/topic.cgi?id=8:26600:2587#2587) Для ArrowLake 265K при низкоуровневом тестировании видно что до 20ns ( это уже безумно но можно как-то достать) лежит ~24Мб локальности кеша L3. Из 30Мб - для этой модели.

4248. mrzet, 11.04.2025 10:52

цитата: ...вранье... 2KKV Вот результат сделанный немедленно. 9600K - 6 ядерник поколения CoffeeLake c 6 слайсами кеша L3 по 1.5Мб. Два теста: первый - многопоточный и даже привлечена виртуальная машина. В хосте идут 4 потока расчета монеро. Как известно каждому потоку нужна локальность L3 по 2Мб=8Мб. Тест латентности 'сырников' запущен в виртуальной машине. Адреса страниц что должны кешироваться очевидно не рядом. И все предсказуемо: тест показывает что свободно 1Мб кеша L3 из 9Мб, потому как 8Мб откушиваются майнером в хостовой машине. Второй тест: Выгружена виртуалка, остановлен майнер, запущен тест 'сырников' - и вуаля от кеша всего 5.5Мб. Казалось бы парадокс - некому отжирать кеш, но результаты хуже. И если обратить внимание я не останавливал никакой софт а-ля антивирусы и прочее в обеих тестах. Но в первом все отлично, во втором - ка зна що. Ошибка кроется у Интела когда он в ответ на выход Zen1 стал клепать 6 ядерные процы. АМД делая 6-ядерники не отключала сегменты L3 и делает так и поныне - и у нее все отлично. Можно запустить тест 'сырников' практически без подготовки - и получить предсказуемые результаты: четкий перелом на границе локальности L3/память. То же самое на процессорах Интел с кол-вом слайсов кеша L3 кратное степени 2*. Но там где у Интела кол-во сегментов кеша L3 не кратно степени двойки наблюдается проблема использования кеша L3 в полном объеме однопоточными приложениями. Я не буду объяснять почему - halt сделал это всяко лучше ( ссылку на обсуждение я приводил выше - там много страниц) Проблема будет на любых интелах где кол-во сегментов кеша L3 не кратно степени двойки, на стрелах это усугубляется низкой частотой кольца ( и разгон кольца там затруднен, да и достигнуть частот кольца что возможны в рапторах/алдерах/ранее судя по всему невозможно). И потери в размере доступного L3 оцениваются как 10-33% - и будет это в основном в однопоточном/один процесс режиме. И главный цимес тут в том что от этого постадают игры - именно у них скорость ( кол-во кадров/сек) зависит от главного потока, если в этом потоке большая локальность данных с доминирующим не линейным доступом - будет попа. Имхо Собственно начиналось по факту все с кофейника 8700K, но уже с кофейника рефреш игроманы пересели на 8 ядерные интелы ( а там проблем нет), начиная с алдера проблема 'камуфлировалась' возросшей производительностью на ядро, но изначально заложенная червоточина должна была вылезти - и на стрелах где кеш L3 в принципе более высоколатентный чем в предыдущих поколениях , мы, устав от голой цифры AIDA64 применили тест 'сырников'( который показывает полный график латентности всей подсистемы кеши-память) - тут проблема и вскрылась в полной красе .... Главная фишка этого 'бага' - хеш-функция по 'размазыванию' данных между слайсами L3 и усугубляется физическими адресами страниц выдаваемых для запрошенного блока памяти. Адреса этих страниц и формируют 'удачность/неудачность' в размере доступного ( низколатентного) доступа в L3. * - иногда когда в системе много софта работающего в фоне идет 'загрязнение' кеша работающим софтом и очевидно его надо выгружать. В проведенном тесте я специально ничего не выгружал - ибо стоит софт проверенный годами. В Windows 11 HOME EDITION штатного мусору много. p.s. Для сравнения дан 6 ядерный Ryzen 5600G - несмотря на 6 ядер он имеет 8 слайсов кеша L3 по 2Мб. И все отлично. Добавление от 11.04.2025 10:52: вот вам два проца одинаковые по архитектуре с одинаковым кешом ( кроме ways - но большая ассоциативность именно у 8700K) L3 только у 8700K 6 слайсов кеша а у 9700K их 8. В разности результатов в игорах есть и толика влияния доступности кеша для движка игры. https://technical.city/ru/cpu/Core-i7-9700K-protiv-Core-i7-8700K К сообщению приложены файлы: 1.jpg, 1920x1080, 435Кb, 2.jpg, 1920x1080, 329Кb, 3.jpg, 1920x1080, 366Кb, 4.jpg, 1440x900, 267Кb

4250. mrzet, 11.04.2025 11:17

некий персонаж что пытался нам помешать намеренно жонглирует несравнимым: в тесте ПСП доступ ПОСЛЕДОВАТЕЛЬНЫЙ, в тесте латентности доступ СЛУЧАЙНЫЙ сообщу так же заинтересованным что оный персонаж даже не удосужившись ознакомится с исходниками теста сходу заявил что автор теста дурак*. когда данному персонажу объяснили что код теста не просто верный, а и написан оптимально, он стал спрашивать знакомы ли участвующие в обсуждении c базовыми алгоритмами - налицо все попытки девальвировать результаты. * - автором теста является программист сотрудничающий с сайтом chipsandcheese.com - это всем известный ресурс которому доверяют. Но у нас как известно лишь один Д'Артаньян, а все остальные ( особенно не согласные с его мнением) гвардейцы кардинала

4253. mrzet, 11.04.2025 11:38

Разница между последовательным и случайным доступом: 1) последовательный ( или шаблонизированный доступ). Аппаратные префетчеры обнаруживают шаблон ( в общем случае) при доступе к данным и автоматически параллельно вычислениям производят предвыборку данных. Как следствие большинство проблем будут скрыты их работой как и дефекты распределения по слайсам кеша. 2) в случае случайного ( не попадающего под шаблон в общем случае) доступа, аппаратный префетчер бессилен. И потому любой дефект кеша высокого уровня считается во времени прохождения теста. И если дефект будет - его не скрыть. Тот кто сказал что 'Тесты пропускной способности показывают, что с кэшем всё в порядке' пытается манипулировать вами - самым наглым и бесстыжим образом. Потому что сам он эту разницу прекрасно понимает. Учтите это. И обратите внимание как только ему нечего сказать - он немедленно пытается перевести все на личности и устроить свару. Не прокатит!

4255. mrzet, 11.04.2025 12:37

Желающие могут попробовать потестировать свое хозяйство сами и вынести собственное суждение: https://disk.yandex.com/d/-RPeZFzjic-Ltg

4260. mrzet, 12.04.2025 05:02

цитата (Saturn [source=8:26622:4259]): KKV Расскажите, как это оправдывает провалы Интел в течении 8 лет? [source=8:26622:4258] ну у меня на столе с каждым годом все больше ядер Intel, для кого-то это видно провал Количество и какчество как бы не одно и тоже. ;Может и стол уже пора менять на более просторный.... ) https://3dnews.ru/1121160/kitay-osvobodil-nvidia-i-a…shlin-a-intel-net Мало Лабутен вложился в китайские предприятия связанные с производством полупроводников и НОАК (заодно). Импорт продукции Интел в Китай будет облагаться 125% пошлиной. А вот продукция АМД нет (заодно квалком и нвидиа). К сожалению также под раздачу попали 'гендерно-нейтральные*' TI и Analog Devices. Ну значит их продукцию будем брать через других нейтралов. Ищо один удар по синим..... Веселый нонча мир, вчера пошлины Китая на продукцию Америги были 84%,с пятницы ужой 125%.Я прям не успеваю следить за этим калейдоскопом. Производители сои (как самые пострадавшие) небось волосы рвут на попе..... :laugh: и не исключено что рыжий хитрожопик вместо 'сделки с Китаем' получит шах и мат от своего ядреного электората... Надеюсь игра стоила свеч, мой милый Донни:gigi: *-заокромя жестких ограничений на доступ к документации через сайт(которые все равно обходятся) , введенных по указанию администрации Бидона, оные не были замечены в каких-либо политически окрашенных сентенциях

4265. mrzet, 12.04.2025 11:43

А мы в силу санкций (хучь и не китайцы) берем/брали у китайцев. Пока трампу не развальцуют интимное - об этом со всей очевидностью придется забыть. Продукция фирм выведенных из под пошлин подорожать (значимо) не должна. Заказал два крупных твердотельника-здесь возможна ценовая катавасия. 2KKV: В принципе могут, только учитывая грабли Интела с кешом L3, Лизе надо будет согласиться делать так: 12 ядер, 16(!)слайсов кеша L3-значит 4 слайса не будут иметь коррелирующих ядер. 4Мб на слайс(как уже давно повелось у красных) =64Мб на CCX. 16 путей и крайне желательно не выше 80 тактов от ядер в худшей ситуации(!) . Итого 12 ядерный CCX с 64Мб L3 16ways. Имхо

4269. mrzet, 12.04.2025 16:59

цитата (Mel79 [source=8:26622:4267]): Какой вообще смысл сравнивать железки в синтетике, и пытаться определять меру удачности инженерных решений компании красные и компании синие, если повлиять на то что они делают в общем то невозможно ? А можно лишь выбрать из буквально 3-5 вариантов под конкретную задачу в рамках конкретного бюджета ? Повлиять невозможно на конкретную железку, но можно зная результаты купить другую. Если вы не знаете результаты этой 'проклятой синтетики' ваш выбор будет основываться на редуцированном кол-ве известных данных, а значит может быть неоптимальным в вашем случае. И это так просто понять.... :)

4372. mrzet, 23.04.2025 22:11

цитата: Да если б на первые Celeron и Pentium можно было воткнуть 32-64-128 ГБ RAM - эти динозавры и сейчас бы жили местами. А вот и нет. Недавно я вычислил порог когда работа ЕЩЕ комфортна а когда уже не всегда, и чем ниже тем резче увеличивается некомфортность. Порог проходит по SkyLake 6600K если бы он был включен на 3.8GHz. Для этого проца 3.8GHz это были семочки и так никто не делал (а гнали его больше). При этом скай 6700 (без литеры K) безусловно комфортен. G4560 (первый гиперпень) некомфортен в части случаев (какая-нибудь 1С это для него тяжело ибо кеша с.... нецензурно). А это для Saturn: https://www.cnews.ru/news/top/2025-04-10_naselenie_ogromnoj_strany И я помню товарищ Grin жаловался что не может никуда пристроить комп 2 летней давности ибо купил новый. Ребята отправляйте в Мумбаи в мастерскую для изготовления франкенштейнов с припиской: продать за 20 бакинских самому бедному студенту....

4469. mrzet, 07.05.2025 21:54

Интел дешевка? А бояре поиздержались? Причем наука не идет впрок: Эта Хольтаус чего-то лопочет про хеджирование оценивая продажи рапторов/против стрел. Вот что бывает когда прежде инновационной и технологической компанией командуют маркетологи..... Жестокая профдеформация мозга :down:

4472. mrzet, 07.05.2025 23:20

цитата (KKV [source=8:26622:4471]): mrzet Не зря же токсичная братия перешла на Рапторы. Одни сразу взяли, другие по дисконту, а ультрачи не пошли брать. Слишком инновационно получилось. :laugh: 'инновационно' (с негативным оттенком) вышло: 1)кеш LLC особенно где кол-во слайсов не кратно степени 2. Это модели 265K и 285K. Кеш LLC в полном обьеме недоступен однопоточным приложениям. 245K благодаря 8 слайсовой структуре кеша этой проблемы не имеет. И вышло так:топовые модели имеют структурный дефект, а младшенький 245K правильный. Общая проблема:низкая частота RING для ядер чей буст достигает (и даже слегка превосходит) 5.5GHz. Разгон кольца до частот рапторных уровней (4.4-4.5GHz)требует напряжения, чей уровнь квалифицируется как небезопасный для долгосрочного использования. 2) контроллер памяти вышел факапный. Чтобы латенси вываливалась за 100ns (без тюнинга, а лучший тюнинг ~70ns у нас на форуме фиксировался) - это конечно катастрофа во всех смыслах. Инновационно(с позитивным оттенком) вышло: 1) архитектура как P так и E-ядер. Отныне (вместе с Zen5) пиковый IPC=6.Новый стандарт, коего достигнуть нелегко 2)Превосходная система кешей L1D-L1. 5-L2 3)за бортом старые костыли HT(что в будующем даст пользу) Что сказал бы инженер: Мы старались, и достигли многого, к сожалению ряд досадных промахов не позволил нам достигнуть идеала, что несомненно мы исправим в следующем поколении. Желаете поддержать нас на этом этапе-извольте, вот скидка.... Что мычит маркетолог: Кельме-бельме...макроэкономическая ситуация, э-э-э-э-э, хеджирование,....... сгорел наш дом с конюшней вместе, но в остальном прекрасная маркиза, все хорошо, все хорошо...... Тьфу.

4513. mrzet, 12.05.2025 23:27

Г-да, хочу напомнить что в копоративной среде процы с литерой K в парке техники весьма нечасты, значит они не пострадали, ну или значимо меньше пострадали чем энтузиасты сидящие на оверклокеской технике. Имхо Вспомните сколько пилили защиту от Spectre, никто и не жужжал особо (ее пилили и в красном и синем лагере). Пусть полируют, главное я так понимаю за кормой. Всегда смотри отзывы-я этому правилу безукоризненно следую. Волна негатива схлынула-значит основное решено, а там пусть полируют, не вопрос. Имхо :beer: Но вот интересное следствие из всей этой бывшей деградации рапторов проистекает и оно весьма существенно. Раньше как мы помним синие 'бояре' любили пару лет потискать свежак интела, а после его продать, освежив платформу. С рапторами эта схема ломается - сложно будет продать старое, кому как докажешь на каком микрокоде сидел.... Так что продажа рапторов на вторичке, тот еще квест будет. Имхо ;)

4551. mrzet, 21.05.2025 20:28

2VLev: ПСП нужен для HPC-задач ( и ряда инженерных расчетов приближенных к оным задачам по сложности(и потреблению полосы)). Толку в HOME/SOHO ноль от этих потуг. Для большинства задач подобных сегментов -6-6.5Гбайт/сек на ядро на чтение и это верх*. * - выше 8Гбайт/сек уже по идее область HPC. Имхо

4553. mrzet, 21.05.2025 20:49

2VLev: Это ты 'умеешь его готовить', а как показывает практика еще десяток кодеров могут получить от него профит ( при ручной оптимизации и видно в доминирующем кол-ве случаев на асме). Компиляторы киксуют на этом сете. Уже то что в MPEG-кодировании ( не во всех случаях) пришлось ждать более чем десятилетие пока руками на асме получили от AVX-512 какой-либо профит - говорит сама за себя. На пальцах одной руки ( для HOME/SOHO) можно пересчитать проги что используют этот сет... более 10 лет, Карл, более 10 лет. Мертворожденное. Имхо И еще: чем более широкие вектора тем менее гибкие методы работы с ними. 512 битные вектора - это хождение строем под конвоем. Шаг вправо/влево - попытка побега и она карается. Гибкости - никакой. Имхо

4555. mrzet, 21.05.2025 21:12

цитата: Не, асм как раз не нужен. Векторные типы данных в C++ рулят. Важно не закодировать ( что по силам и компиляторам) а именно получить профит в скорости алго.И не единицы процентов ( ибо это на уровне погрешности измерений). А вот это уже камень преткновения. И пример MPEG - тому подтверждение. Десятилетие ( и более) пыжились с автовекторизацией и выхлоп ноль. Потом сел кодер вдумчивый и заточил руками приличный профит. Руками и головой. цитата: тоже нет, исторически, гибкость в общем и целом растёт с шириной вектора. гибкость команд работающих с целым вектором - возможно ( но это не моя зона интересов). А вот гибкость другого рода отсутствует совершенно. И мы это обсуждали в теме APX. Мне бы пофиг команды AVX-512, но вот регистры векторов - это то на что я облизываюсь. Однако нет возможностей быстро на лету собрать/разобрать длинный вектор из экстентов. И это отсутствие гибкости. Гибко можно работать с битами, байтами,.. 64-битными словами и даже ( более-менее) с короткими векторами - они же SSE. Но вот выше - хождение строем и под конвоем.

4558. mrzet, 22.05.2025 08:28

2Усталый Путник: Свою позицию я выработал давно, еще в те времена когда AVX-512 на интеле было, а на амд не было. Сейчас (в десктопе) все наоборот, но я отнюдь не рукоплещу Лизе, а корю ее за этот выбор, ибо она должна хучь и копейку но синим платить за лицензирование. Проблемы длинного вектора (усугубляющиеся с ростом разрядности) : 1) потеря в гибкости сборки/разборки особенно высокоскоростной/на лету. ЭТО ГЛАВНОЕ! ДО 256-битного вектора, в архитектуре x86-x64 не было в целом проблем в сборке/разборке разрядностей данных. В AVX2(я подчеркиваю именно целочисленные 256-битные вектора, потому что в плавающей точке это не так важно) мы поимели неприятный факт что проще подготовительные операции с вектором делать в памяти, а лишь потом грузить и считать. А с какого спрашивается мне такой медленный посредник как память??? Дальше-хуже. 2)Особенно первые реализации были через 'жо.. у'. Интел как известно закипал и на 256-битных векторах, куда тут 512-битные? По большому счету, работать на приличной частоте, а не жалких ниже 3GHz интела могли лишь при иммерсионном охладе. У АМД реализация была лучше-т. е. не отличалась таким необузданным жором. 3)вспоминаем как шел оный сет в массы. Там десятки субсетов. Целостной реализации нет. Тут рыбу режем, тут заворачиваем. Удобно для маркетологов, чтобы дозировать по грамму за сотку бакинских, но неудобно для программиста. 4) пока все пилили, это компромисс на компромиссе. В результате реальной поддержкой обладают лишь зены 5, поскольку у них честный 512 битный path, а не два обрубка по 256-бит. 5)времяприменительная практика. Которая показала:если в серверном сегменте AVX-512 может быть нужен. Там считать расширение Вселенной и подобные задачи. То в SOHO/HOME он не нужен. Потому что использовать его почти не под что, а чтобы поиметь профит надо жестко поиметься (а компиляторы мало что могут). 6) гибкость вы говорите? А могу я 4 64-разрядные части вектора просуммировать, а другие 4 части вектора вычесть одной операцией над векторами? Нет. Чем шире вектор, тем в реальности ему нужен более тяжелый фарш операций/обработки/обслуживания. Особенно если нет возможностей быстро собирать/разбирать вектор на лету. Вот так на мой взгляд выглядит этот гомункулус AVX-512

4560. mrzet, 22.05.2025 08:43

-То есть тебе, дружочек, не подходят и 256-битные вектора (старый добрый AVX/AVX2)? -Да, мне не подходят. Мне неудобно в них работать. Однако, отдавая дань применительной практике, я не могу отрицать что профит от 256-битных векторов ЕСТЬ и он достаточно частое явление. И потому AVX/AVX2 заслужили свое место под солнцем, а вот AVX-512 нет.

4562. mrzet, 22.05.2025 10:35

цитата: У AMD и Intel кросс-лицензирование, никто никому не платит пока есть разделение платформ Это неправильно. Интел должен платить за лицензию на AMD64, АМД должна платить за AVX/AVX2 и уж раз так повелось за AVX-512. Платежи должны быть неограничивающими и разумными*. Однако без них есть соблазн не делать инноваций и получать на халяву чужие разработки. Нужных инноваций *- хоть там 10 центов за экземпляр процессора с нужной технологией. Тут дело не в прибыли даже а в порядке.

4565. mrzet, 22.05.2025 10:44

цитата: инновации в первую очередь для себя делают, а не чтобы конкуренты на чужой лицензии наваривались .. Может раньше и такие оттенки были, однако создав общий консорциум по развитию архитектуры, они приняли то соломоново решение, которое раньше принял судья который и создал дуополию и собственно само кросс-лицензирование для обеих компаний.Он был умнее обеих по которым принял решение.

4569. mrzet, 22.05.2025 19:07

2matik: А исчо Marvell, Realtek,..... Не интеломь единым живы сети

4578. mrzet, 28.05.2025 07:54

цитата (KKV [source=8:26622:4577]): ultrasilent Только вот PBO это не про напряжение. :eek: это какь? Интересно на сколько они превысили на SoC?Именно 'смертельную дельту' , чтобы понимать, так сказать, границы девиаций для 4nm кремния.....

4580. mrzet, 28.05.2025 13:29

2ultrasilent: цитата: похоже что минимально это минимально - такое себе. Я на своем рабочем 9600 Vcore offset -0.07V легко поставил( просто поставил и прошло как показали все тесты и ужой работа). И ранее что попадало в мои руки и если горячее, почти в 100% ( ну 95% ) можно -0.1V сделать практически всему. Так что штатные напруги оно такое себе. Задрано часто и по дефолту*. А тут еще поддали. Надо бы вот знать точно смертельную границу. Имхо * - производитель нормирует вольтажи для самых хреновых кристаллов, но у тебя обычно оказывается не самое 'дно', потому обычно есть запас по даунвольту.

4584. mrzet, 28.05.2025 18:35

цитата: первый раз про такое слышу Процы заказывают вольтаж. НО. Проц не может заказать вольтаж под свой кремний ( его качество очевидно разнится). В PBO он закажет допустим 1.32V но вполне работоспособен и при 1.25V. Потому что невозможно прописывать диапазон нагрузок и вольтажи для них под каждый кристалл - это было бы банально дорого ( ведь для этой кривой на каждый уже упакованный кристалл нужны заводские тесты). Потому он закажет 1.32V* - и это так для худшего кремния из возможных. Но ваш скорее всего не будет дном и потому заработает стабильно при 1.25V. 65 ваттные рязани в PBO будут уходить в 88ватт мощности, а -0.07V экономит 4.5ватта или при -0.1V уже 6.6ватта что для 10 литровых корпусов значимо( ибо туда не поставить 'тяжелые' башни). * - еще и качество VRM не учесть бо неизвестно в какую мать встанет, так что там берутся наихудшие варианты отчего даунвольт и возможен За это сообщение сказали спасибо: blomma

4586. mrzet, 28.05.2025 18:48

цитата: 700Вт... Лабутена посадим попой на проц - пусть охлаждает

4588. mrzet, 28.05.2025 18:56

цитата: разве что, оно автоматически проставляется ну именно. Автоматически и не оптимально для конкретной пары mobo/CPU. Делаешь даунвольт и добираешь буста под свою пару ( или охлад)

4591. mrzet, 28.05.2025 20:12

Процессоры AMD RYZEN - возникающие проблемы и их решения. Техподдержка (old) (часть 2), #11984 (https://forum.ixbt.com/topic.cgi?id=8:26351:11984#11984) Даже если экстраполировать известную статистику и учесть что далеко не все случаи в нее попали то вроде как бы не набирается и на пластину?

4597. mrzet, 29.05.2025 13:28

цитата: а с чего ты решил, что при 1.25в он сохранит работоспособность во всем диапазоне всех своих возможных состояний? цитата: ( просто поставил и прошло как показали все тесты и ужой работа) И кстати прайм я тож прогнал - но не целый день конечно. цитата: так и не нашел нигде, везде пишут, для каждого кремния индивидуально. возможно кривую напруга-нагрузка зашивают по-партии. А может ( и это не исключено) ставят кривую вообще одну для худшего найденного кремния ( но считающегося рабочим). Надо еще помнить что скажем зен 2 мог попасть в Asrock Taichi X570 и в какой-нибудь A320 голимый от MSI( в текущих условиях есть свои агнцы и козлищи). А это два разных VRM - и работать он должен в обеих случаях. Потому в стоке напруги обычно завышены - для наихудшего случая соблюдая стабильность в обеих исходах. Индивидуально быть не может. Индивидуальный подбор делает пользователь у себя на плате ( кто умеет). вот что осталось из того на что опасно ставить даже какой-нибудь 3600: https://www.regard.ru/product/733178/materinskaia-plata-cbr-a320

4602. mrzet, 29.05.2025 19:34

Не думаю что ставили как хотели. Глянул на ассортимент AM5 плат асрока - бюджетных решений 5 плат из 28. Остальное дорого богато. И вот какой момент - асрок в среднебюджетных и выше решениях использует качественные компоненты VRM. Очень качественные. Это у них еще с AM4 платформы повелось где Pro4 ( во всех ипостасях) долго была среднебюджетным эталоном разумного. И они всегда ставили в цепи очень качественные дроссели. Вот тут может причина и порылась. При снятии напруги вследствие снятия нагрузки как известно возникает овершот. Это дроссель сбрасывает энергию. Если асрок ставил максимум рекомендованного на Vsoc, то возможно овершоты и убивали часть процов которые 'послабже' оказались. Вот такая у меня версия.

4604. mrzet, 29.05.2025 19:51

В целом проблема не думаю что критичная - нагорело по всему миру кристаллов на 1 ( максимум 2 пластины). Биос'ом поправили PBO , снизив мальца напругу - чтобы уровень овершота ( в худшем случае) не превышал верхнего допустимого порога - и будет норм. Обратите внимание: доминирующее кол-во случаев на асроке именно. Это 'детские' болячки. Главное чтобы пострадавшим все заменили - бо тут не волосы (грязь/пыль) в сокете - как была первоначальная версия.

4606. mrzet, 29.05.2025 19:56

цитата: смотря с какой стороны смотреть. вот представьте вас на пару месяцев да я изредка несколько каток в WoT - и все мои игоры. А лишить меня компа ну никак не можно. Два компа на работе и дома 5 штук. Ну вот как???

4608. mrzet, 29.05.2025 20:18

цитата: как то проблематично накосячить. Да ну, проблематично?! История из прошлого: 9 мин 45 сек. 35 град разницы в VRM. https://www.youtube.com/watch?v=EqQcgwz1hYA

4610. mrzet, 29.05.2025 20:44

Не, божий промысел. p.s. Я тут раньше говорил и повторюсь: 'никогда не говори никогда' К сообщению приложены файлы: 1.jpg, 138x300, 14Кb

4611. mrzet, 29.05.2025 21:11

заодно стоит оценить как VRM делает асрок. Такая конструкция спалит два проца и не поперхнется( если чуть ошибиться). Имхо К сообщению приложены файлы: 1.jpg, 2000x1285, 476Кb

4613. mrzet, 30.05.2025 00:02

Принципы построения нормального компа просты: Нельзя экономить на: 1)питаниии. Хреновый БП, грязное питание-первоисточник проблем. Возможно и в побитом файле. ;) 2)доске она же mobo. Умершая по тем или иным причинам доска-в 90% случаев==замена компа со всеми вытекающими. Брать мать по цене сдачи с продуктового магаза-себя не уважать. И, да, сверхбюджетки плохи у всех производителей. Важно лишь как хорош среднебюджетный (и в части случаев премиальный) класс. И когда Gigabyte B450 Aourus лажал с дросселями-это УЖЕ недопустимо для среднебюджетных решений. А с показанного мусора какой вообще спрос? 3)накопители. Ибо данные и система их хранения и резервирования и избыточности-главное для чего существует комп. Процы:на 'вырост' не бери (исключения редки но бывают). Не бери самые топы, замучаешься с охладом, при прочих равных выбирай с меньшим потреблением, дольше проживет весь комп. Вода не есть надежно, воздух чинибелен(иногда нужны всего спичечная головка литола, жидкое маш. масло, зубочистка, нож). Память не обязательно сверхдорогую, бери надежную. Чистить комп раз в год, при наличии животных 2 раза в год. Чего я еще забыл? ;)

4671. mrzet, 06.06.2025 22:42

2matik: У меня смутное чувство, что ряду форумных 'квакеров', топивших за интел теперь тоже не платят:lol:

4673. mrzet, 06.06.2025 23:57

Неделю работаю на новом компе Zen5 9600X. Все стайбл. Но вот какой момент: он настолько резкий как понос, что даже чуть неприятно. Да, это несколько пародоксально-его скорость вызывает некоторое раздражение. Попробую мыши понизить чувствительность как вариант.:insane:.... А у вас такое было? Или привыкну? * Мой старый рабочий комп был 1230V2-и не сказать что он тормозил, но уж порты USB3 отваливаются через раз и видеокарта подглючивает легко (мамко сгнила думаю). *- 'старые' кофейники под 5GHz для меня в интерфейсе очень быстры, но неприятных чувств нет. Zen2-'основательный'. Скорость в интерфейсе приятная. Zen3- скорость в интерфейсе ~как у оверклокнутых кофейников, Zen4 - очень быстры, но еще нет негативного ощущения, а вот Zen5 как будто бежит впереди твоей мысли (вот такая аналогия приходит на ум) и это раздражает несколько.... Как будто каплю ртути пытаешься пальцами ухватить, или ловишь мелкую косточку от лимона выжатого в чай-а она никак в ложечку не ловится.

4730. mrzet, 11.07.2025 07:24

цитата (TurboUSB [source=8:26622:4729]): sse2 соотвественно 13000рублей. чет как то подозрительно? что с ними не так? [source=8:26622:4722] Все так.... и может avx512.... Подчеркнутое-не достижение, а лишь малонужная (особенно с учетом сегмента куда ориентирован проц*) фича. Если вдуматься то даже EU=6 куда полезней для сохраняющегося SMT, чем той AVX512. *-станция разработки для тех кто умеет в avx512 (как то VLev) - одно из редчайших но фактических применений где таки востребовано.

4863. mrzet, 05.08.2025 07:16

2HeinzGrenze: Ryzen Z2 Extreme сделан на Zen5 (с миксом Zen5C). И более новой архитектуры ядер у АМД пока нет. За ИИ вообще пофиг с учетом мизерной фактической применимости локально. Так что это свежий проц во всех смыслах, ибо 'свежее' нету.... ;)

4955. mrzet, 15.08.2025 14:50

цитата: они их купили ... и сейчас сливают.... так правильнее За это сообщение сказали спасибо: KKV

5032. mrzet, 28.08.2025 06:16

цитата: разогреть 15 ваттами на 71-73 это значит что система охлаждения просто из фольги. Не обязательно, это может означать консервативный/поздний подхват буста системы охлаждения, хотя 71-73°С это поздновато....

5076. mrzet, 31.08.2025 15:09

Готов послушать сказки для чего в десктопе 52 ядра*. С учетом что и 16-то нужны 5% юзверей реально (а не на вырост/чтобы було)... *-очень хочется узнать тезисы новой синей методички. Как синие фанаты будут кульбиты через голову делать... :laugh:

5078. mrzet, 31.08.2025 15:16

Тама скорее DT==R, тогда понимаю, ya-a!!! 52 ядра кормить с двухканала в HE... , оно внушаеть!!! Рукоплещу и ржу.:up: Ну главное, Зинснеру вроде заходит (входит и выходит!? :gigi:)

5082. mrzet, 31.08.2025 20:11

У 9950X заявлен TDP=170ватт. Давно уже пересчитываю заявленный TDP кулеров как 0.67 (2/3 от заявленного). Значит нужна башня что может отводить 253 ватта или выше. Юзать такой проц на 90 ваттном кулере-еще повезло что процы по полгода потели перед смертью. Я б ему ничего нового не высылал, он сам такую уродскую сборку сделал... Вот первый попавшийся воздух что впритык: https://www.regard.ru/product/419005/kuler-deepcool-ak620-zero-dark

5084. mrzet, 31.08.2025 20:21

У меня друг давно еще включал эфир на 290X. Когда я ему говорил что температура мосфетов в VRM как ~105°С это путь в Вальгаллу,он отвечал :'по спецификации они на 110°С' Мое пророчество сбылось через неделю экзорсисов... Абсолютно нормальная температура кремния при которой он живет долго:до 80 °С включительно. Имхо

5086. mrzet, 31.08.2025 20:28

Потому что в этой точке начинаются те процессы что могут привести к лавинному тепловому пробою И если в проце еще какие датчики встроены, просто потому что он шибко дорогой, то силовой мосфет один на один с внешними факторами. Относитесь к элетронике бережно-и она ответит долгой безглючной работой. Будете насильничать-ждите близкой беды. За это сообщение сказали спасибо: XAA

5094. mrzet, 31.08.2025 20:46

2XAA: Во первых есть переходные процессы. Они всегда идут волнами. Что в технике что в биологии, да и вообще в жизни. Подайте на ваш проц все 32 потока плотного AVX2 и инерционность датчиков не успеет раскрутить кулера, как 9950X будет в 90 °С. ДА, потом вентили взвоют, и темпа упадет ниже верхнего порога, и в несколько осцилляций достигнет равновесия. Коэфф 0.67 к заявленному TDP кулеров я применяю многие годы, и если он не выдерживается-значит кулер г...но. Мракетологи, мать их....

5099. mrzet, 31.08.2025 20:56

цитата: Из кулеров я уже лет 15 использую Noctua И именно потому я никогда не применяю Noctua. Когда весь мир (ну вдруг) будет ходить с IPhone, у меня останется мой старый боевой андроид. Не люблю я этот пафос свердорогих побрякушек. Есть не сильно хуже.... Это строго imho

5103. mrzet, 31.08.2025 21:33

Расскажу я вам, господа, историю из моей практики, чтобы вы прониклись тем чувством что регуляция всегда идет волнами. А некоторая волна ведь может и убить. Так что 'девятый вал' нам совершенно не нужен. На работе у нас была сотрудница, худуща не только до миниатюрности, а прям и больше. И вот она забеременела. Муж то там тож худой. И так вышло что в третьем триместе вышел у нее гестанционный СД (сахарный диабет). Гестанционный он транзиторный (временный) обычно. И здесь было такое же. Родилась девочка, и родилась она не пухлой, а прямо толстенькой (сейчас по истечении лет все пришло в норму). И вот как то у девочки че-то там с дыхательными путями аллергенного характера. Поела токмо по утру. Приехал доктор и дал ей 5x физиологическую дозу метипреда. При том это 5x доза она под взрослого человека. Доктор все правильно сделал, но предисторию не знал. Поутру - реанимация, поскольку у ребенка гипогликемическая кома. 2 моль/литр сахар. Ну откачали, хотя пузыри из носа и в отключке была. В момент когда у матери в 3 триместре был гестанционный СД, ПЖ (поджелудочнвя железа) плода работала за двоих. Отчего девочка не просто пухлая родилась, а жирненькая (у худых то родителей! ). И за время пока ей пришлось пыхтеть за двоих-в утробе то есть, натренировалась рубать сахар со страшной силой. Когда доктор дал 5х физ дозу антагониста инсулина, сахар как следствие стал повышаться и тут то сверхтренированная ПЖ выдала на гора уравновешивающий фактор. А к утру еще не затормозила и пробила в гипогликемическую кому. Вся регуляция идет волнами-вы это учтите. И чем больше волна, тем больше могут быть последствия.

5105. mrzet, 31.08.2025 21:50

Правила сбора производительных систем просты: 1)собирать лучше летом, потому что нагрузочное тестирование пойдет в самых жестких условиях. 2)не экономь на термопасте. Кулер бери с запасом как 0.67 к TDP проца 3)обязательно провести нагрузочное тестирование в самых жестких условиях из возможных. 4)раз в год тщательная уборка внутри компа. При наличии длинношерстных животных - раз в полгода. Имхо

5202. mrzet, 05.09.2025 14:58

цитата (bess [source=8:26622:5200]): Omega > LPE работают в idle для сервисов и пр. фоновых нагрузок, а при нормальной нагрузке, и в интерактиве они отключаются... [source=8:26622:5194] И поэтому глупо включать их в общее число ядер при суммировании. Их и в кремний включать не стоило....

5333. mrzet, 27.09.2025 18:05

цитата (Omega [source=8:26640:1268]): провал AMD скорее в 2006-2007 начался, а причиной была покупка ATi. Не согласен. Для 'перспективного'* ИИ у AMD хучь инстинкты есть. Были бы они, будь не куплен ATI? А что может предложить здесь Интел не купивший в данном сегменте ничего, и как следствие развивавший свое посконное(которое известно в каком месте находится-прювет Гауди;)) ? *-взято в кавычки потому как этот тренд в вечности не устоялся. Будет ли знамя ИИ реять через 3-4 года-никто не знает и уверенности нет.

5364. mrzet, 08.10.2025 11:30

цитата: Если бы не было 14600кф, то 250 долларов за данный камень вполне неплохое предложение. Если бы не было 14600кф то и предложения в 250 бакинских за 9700x бы не было. Молитесь за братьев наших синих!* Имхо * - да избегут они ересей непонятного процессоростроения, да выгорит у них наконец то нормальный прибыльный техпроцесс. Имхо

5400. mrzet, 12.10.2025 10:33

Я напомню как обстоит дело: AVX-512 специфический и очень энергетически прожорливый дополнительный* набор команд позволяющий оперировать вектором длиной 512 бит, в коий вектор горизонтально упакованы меньшие размерности операндов как то 8 64-битных слов, 16 32-битных и т.д. Прожорливость это ладно, может быть побеждено тонким техпроцессом, другой компоновкой кристалла, в конце-концов, но есть в оном AVX-512 структурные дефекты которые не обойти не обьехать. x86 изначально был 16-разрядным, позже стал 32-разрядным и сейчас 64-разрядным (то что называем x84-x64) и ВСЕГДА на протяжении всей эволюции у программиста не было сложностей в доступе к составным экстентам регистров/значений большей разрядности. Даже с появлением первых 128-битных векторов (SSE) можно было приемлимо быстро оперировать частями вектора(хотя замедление было и есть). Но уже в AVX-256 собрать/разобрать вектор 'на лету' быстро (в самом коде, без промежуточного сохранения/загрузки) стало невозможно. И ладно, но AVX-256, всеж давал прирост производительности. Но еще более монструозный AVX-512 уже не давал роста (за редкими исключениями). Примеров тому вагон, в mpeg-кодировании прирост получили более чем через 10 лет, ручной оптимизацией кода(компилятор в пролете как фанера над Парижем) , и то в узком ряде случаев. Чем длиннее вектор, тем более узка область его применения, тем сложннее его применимость, отсутствие быстрой сборки/разборки вектора еще более затрудняет его применимость. *-не является необходимым, все что он может сделать можно повторить в скалярном коде. Процессор с AVX-512 это как корабль с избыточно загруженным балластом-преимуществ нет (за очень редким исключением). И что смешно, раньше сторонники синего лагеря талдычили про AVX-512, не могли предьвить ничего стоящего (потребного в быту) кроме синтетики с вращающимися шариками, и теперь подобный скользкий критерий берется на 'вооружение' сторонниками красного лагеря. Куча копий сломано вокруг мусорного набора команд. Тьфу.... Добавление от 12.10.2025 10:33: И еще: AVX-256 и AVX-512 были бы куда более востребованы/гибкие в применении, будь инструкции VPINSRQ ( загрузить в произвольный экстент вектора 64-битное значение из РОН)/VPEXTRQ (выгрузить из вектора произвольный 64-битный экстент в РОН) имели бы латентность =1. Именно эти инструкции отвечают за сборку/разборку вектора. Но они очень медленные. За это сообщение сказали спасибо: Makc1968UA

5408. mrzet, 12.10.2025 12:39

цитата: А вот AVX (Advanced Vector Extensions) предполагает по умолчанию сборку/разборку векторов из раскиданных по памяти данных VGATHERxxxx-это вообще инструкции которые не должны были появиться как и их разработчик (окончивши жизнь спермотазоидом в презервативе самое верное) - измеренная латентность подобных инструкций выходит за 20+ тактов. Это в видеопроцессорах подобное возможно но не в CPU. И опять же:операнды из памяти! Спрашивается зачем? Максимально быстрая сборка вектора идет из РОН, и уж как загружать тот РОН из памяти-опытный программер сделает куда быстрее неконвейризируемой уродской инструкции.

5410. mrzet, 12.10.2025 12:57

Самый сравнимый принцип работы современного проца: это работа ГШ-30, или Вулкан, только сразу стреляют все стволы. А обьемный кеш-это ленты боепитания до каждого ствола. И в современных процах уже 6 стволов (как то в ArrowLake, Zen5 - вот почему тут стоит задуматься об апгрейде). Самые быстрые (желательно с латенси не выше 1 такта, чтобы 'ствол' стрелял без задержек) команды чье расположение настолько удобно что весь независимый сикстет может 'вылететь через 6 стволов' одновременно и то же самое в дальнейшем. Вот это и есть современный проц общего назначения. Каждая команда может обработать любой экстент информации:от бита до 64 бит без затруднений и тормозов/экзорсисов(в отличие от векторных команд).

5425. mrzet, 12.10.2025 16:34

Основное где хоть как может использоваться AVX-512 у вас дома - транскодирование видео. Но именно в Preset Slow эту оптимизацию не завезли. А там где не Preset Slow там транскодировать можно в разы быстрее на видюхе. Вывод: для обычного пользователя AVX-512 крайне узкая ниша применения ( где можно поиметь хоть какой гешефт) Если бы потраченный на AVX-512 транзисторный бюджет пустить в увеличение L3 - и то значимо больший профит бы вышел.

5427. mrzet, 12.10.2025 16:56

цитата (slasla [source=8:26622:5426]): mrzet А сколько мегабайт добавилось бы у Zen5? Я вот не знаю сколько бы добавилось, но скажу так: на работе у меня 9600X - и он резкий как понос ( я даж мышь затормозил). И брал я его не за этот уродский AVX-512. а дома у меня 1285v4 ( на стенде с которого и пишу этот пост)- 'старпер' Броадвелл на котором 3 студии (Visual Studio) поставились менее чем за день ( распаковка, апгрейд, дальнейшее сжатие малонужных либ). И он до сих пор кроет как бык овцу даже куда как более свежий Алдер в сжатии/декомпрессии. Кеш куда большая сила чем этот ваш мерзкий AVX-512. Имхо