LINUX.ORG.RU

ОБНОВЛЕНО: Intel убрала запрет на публикацию бэнчмарков для обновлений микрокода

 , ,

ОБНОВЛЕНО: Intel убрала запрет на публикацию бэнчмарков для обновлений микрокода

7

7

Компания Intel обновила условия лицензии на микрокод исправляющий уязвимость L1TF и запретила тем самым публикацию результатов тестирования и сравнения производительности процессоров.

You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results.

UPD: После негативной реакции пользователей на новость о запрете публикации результатов бэнчмарков, в Intel всё же решили убрать даное ограничение из текста лицензионного соглашения:

Copyright (c) 2018 Intel Corporation.
All rights reserved.

Redistribution.

Redistribution and use in binary form, without modification, are permitted, provided that the following conditions are met:

  • Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission.
  • No reverse engineering, decompilation, or disassembly of this software is permitted. “Binary form” includes any format that is commonly used for electronic conveyance that is a reversible, bit-exact translation of binary representation to ASCII or ISO text, for example “uuencode.”

Всем кто ранее загружал код патчей микроядра рекомендуется скачать обновлённые архивы с исходным кодом и пакеты (не забудьте удалить предыдущие архивы с кодом и пакеты!).

>>> Обсуждение на Slashdot

>>> Подробности

☆☆

Проверено: Shaman007 ()
Последнее исправление: atsym (всего исправлений: 6)

Ответ на: комментарий от Quasar

Но 83xx не вдвое быстрее 6300. Что-то ты сам себя полил из дуршлага.

anonymous
()
Ответ на: комментарий от Quasar

Уже нет. У меня теперь Ryzen.

А чё так, если кукуруза тащет?

anonymous
()
Ответ на: комментарий от Igron

Мой компьютер

Компьютер

Этот компьютер

Наш компьютер

* вы находитесь здесь*

Нах компьютер

Open Source Computer

FiXer ★★☆☆☆
()
Ответ на: комментарий от templarrr

и что?

Работает как абакус, а не как процессор.

anonymous
()
Ответ на: комментарий от SakuraKun

AMD-шное мелкозернистое можно и глиной залепить

В фортунки. Это просто сферическое амуде в вакууме.

anonymous
()
Ответ на: комментарий от anonymous

Такое выкидывание ничего не даст, тк основные их покупатели это сервера и оемы.

anonymous
()

кстати, каким пакетом (командами) лучше всего адекватно делать сравнительные бенчи, или просто emerge www-client/chromium или time grep -ERl «80286» /usr/src/linux ?

anonymous
()

Краткое содержание:

Компания Intel обновила условия лицензии на микрокод исправляющий уязвимость L1TF и запретила тем самым публикацию результатов тестирования и сравнения производительности процессоров.

Пользователи: — Да вы там совсем охуели, что ли?!!!

После негативной реакции пользователей на новость о запрете публикации результатов бэнчмарков, в Intel всё же решили убрать даное ограничение из текста лицензионного соглашения.

anonymous
()
Ответ на: комментарий от Ramil

Покупать процессор за 50 тыщ ради игрулек или многоядер на ПК, ты точно прав что это нужно?

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

FiXer ★★☆☆☆
()
Ответ на: комментарий от FiXer

Чем производительнее компонент, тем хуже у него соотношение производительность / цена. Так даже у амуды.

anonymous
()
Ответ на: комментарий от anonymous

Каким программами пользуешься, те и тестируй. Только все опции и внешние факторы влияющие на производительность вкури предварительно.

anonymous
()
Ответ на: комментарий от Ramil

Ты мне лучше вот что скажи, зачем на ПК 16 ядер и для чего конкретно это 100 % нужно?

Людям, которые занимаются вычислениями, рендерингом, виртуалками, разработкой...

FiXer ★★☆☆☆
()
Ответ на: комментарий от FiXer

Людям, которые занимаются вычислениями, рендерингом, виртуалками, разработкой...

сразу видно - специалист - профессионал ...

superuser ★★★★☆
()
Ответ на: комментарий от FiXer

Людям, которые занимаются вычислениями, рендерингом, виртуалками, разработкой...

Для этого есть специальные ПК на базе зеонов и оптеронов. i9 и тридрипер того не стоят. Даже заморачиваться с ними.

Ramil ★★★★
()

Intel убрала запрет на публикацию бэнчмарков для обновлений микрокода

Похоже интел знает секрет счастья, ну тот самый про «отнять все, затем вернуть половину.»

Aber ★★★★★
()
Ответ на: комментарий от WitcherGeralt

На своем домашнем компе ты тоже цомпелять будешь через отдельный сервер?

И отладочные билды через CI наверное прогоняешь, вместо того чтоб тест запустить локально?

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

На своем домашнем компе

На моём домашнем компе компиляется только няшный Go, за доли секунды. Но вообще, когда надо чего-то сишного/плюсого покомпилять, то это в любом случае не занимает какого-то эпического времени даже на ноутбуке. Я мб и уловил бы ещё смысл, будь я гентушником, но не.

И отладочные билды через CI наверное прогоняешь, вместо того чтоб тест запустить локально?

Если у тебя проекты такого объёма, что у тебя свеженький i7 не справляется, то вероятно таки да, тебе так и так придётся всё собирать на билдике. Если же нет, то и без тредрипперов ок.

WitcherGeralt ★★
()
Ответ на: комментарий от Ford_Focus

Две кукурузины заняты одной инструкцией, когда (не будем показывать пальцем где) одно ядро может выполнять несколько разных инструкций одновременно.

anonymous
()
Ответ на: комментарий от targitaj

Надо быть сильно больным чтобы своими деньгами платить за vendor lock.

Большинству хватает быть просто недостаточно информированными, чтобы своими деньгами платить за vendor lock. К сожалению, далеко не все читают перед сном Столлмана и прочих апологетов информационной свободы. Большинство даже о самой возможности такой свободы просто не в курсе.

anonymous
()
Ответ на: комментарий от Vigi

получается, он готов распрощаться со своим макбуком, где амд проца нет и не будет

anonymous
()
Ответ на: комментарий от anonymous

всё слишком сложно. наращивать производительность напрямую поднимая частоту нельзя ибо размеры кристалла таковы что в ассинхроне будут работать края. + тепло от частоты не хилое. Придумать что-то лучшее в архитектуре впринципе как-то уже и нельзя, акромя что-то вроде sse, тобишь встраивая в комбаин определённую функцию, умеющие делать это быстро и эффективно. у более тонкого техпроцесса уже сказывается и диффузия и электросопротивление и уже в свои права начинают вступать квантовые эффекты вроде туннелирования электронов.

anonymous
()
Ответ на: комментарий от anonymous

Мне казалось уже сделали, лет 20 назад. CISC на VLIW тоже уже попробовали и получилось вообще-то не плохо, только публика энтузиазма не проявила.

anonymous
()
Ответ на: комментарий от anonymous

Имел в виду не x86 со всратыми инструкциями, а вроде aes, аппаратного рандома и тд.

anonymous
()
Ответ на: комментарий от WitcherGeralt

когда надо чего-то сишного/плюсого покомпилять, то это в любом случае не занимает какого-то эпического времени даже на ноутбуке

По мне так между 5 минутами и минутой разница существенная

mersinvald ★★★★★
()
Ответ на: комментарий от anonymous

Перепаковываешь исходники линукс в squashfs. Монтируешь через squashfuse, дада именно FUSE. Его монтируешь в union-fuse, тут тоже fuse. И замеряешь время сборки, например defconfig, хотя лучше allnoconfig, вдруг не дождешься.

anonymous
()
Ответ на: комментарий от Ramil

Числодробильни, производство видеоконтента, например.

templarrr ★★★★★
()
Ответ на: комментарий от mx__

Почему на 63 ? i7 порядка 30 тысяч, р7 2700 порядка 25 тысяч.

Брал цены с того сайта, возможно они были некорректны, тогда та, райзен чуток отстает, но не сильно... прогресс на лицо, да и с нормальной видяхой оба дадут 60+ фпс.

FiXer ★★☆☆☆
()
Ответ на: комментарий от anonymous

В эльбрусах тоже заявляют 20 ipc. А попугаев как у атома.

Так «может» не значит что он их получает.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от SakuraKun

После исправления интелоспецифичных уязвимостей вроде Meltdown и вариантов Spectre которым AMD не подвержена - у Штеуда действительно больше нет преимущества в опенсорсе. syslog_ng на интеле без применённого анти-Meltdown патча компилируется 4 минуты, а с патчем - 21 минуту (система: свежий i5-7440HQ с Fedora 27) и это не единичный пример! (пусть и один из самых ярких, а в среднем замедление 5%-30% от одного только патчинга мельдауна)

Спасибо за сведения, Сакура-парень, пошел проверять на своем i7-3770.

Deleted
()
Ответ на: комментарий от SakuraKun

UPD: Действо происходило на 8 потоках — MAKEOPTS="--quiet -j8"

Sat Aug 25 12:10:19 2018 >>> app-admin/syslog-ng-3.13.2
merge time: 1 minute and 7 seconds.

real    1m23,795s
user    2m23,204s
sys     0m38,269s
#uname -ra
Linux gentoo 4.17.10-gentoo #1 SMP Sat Jul 28 03:01:08 +06 2018 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux

#grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" || echo "unpatched :("
patched :)

#cd /tmp
#wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
#sh /tmp/spectre-meltdown-checker.sh

***

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm64):  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Minimal generic ASM retpoline)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES 
    * IBRS enabled and active:  NO 
  * Kernel is compiled with IBPB support:  YES 
    * IBPB enabled and active:  NO 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
    * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports minimal retpoline compilation)
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES 
  * PTI enabled and active:  YES 
  * Reduced performance impact of PTI:  YES  (CPU supports PCID, performance impact of PTI will be reduced)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
> STATUS:  VULNERABLE  (your CPU is known to be vulnerable, and your kernel doesn't report that it mitigates the issue, but more thorough mitigation checking by this script is being worked on (check often for new versions!))

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

Есть такая строка: bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.