The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опубликована техника скрытия вредоносного кода в анклавах In..., opennews (?), 12-Фев-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


37. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +1 +/
Сообщение от YetAnotherOnanym (ok), 12-Фев-19, 21:12 
> нет потоков

Вот и хорошо. Когда тебе продают проц АМД и говорят, что там 4 ядра - значит там 4 ядра, а не 2, которые притворяются четырьмя.

Ответить | Правка | Наверх | Cообщить модератору

45. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +7 +/
Сообщение от Stax (ok), 13-Фев-19, 00:30 
>> нет потоков
> Вот и хорошо. Когда тебе продают проц АМД и говорят, что там
> 4 ядра - значит там 4 ядра, а не 2, которые
> притворяются четырьмя.

Да?..

То-то купив APU A10-7800 за $200 (пишу по памяти, может чуть другая модель была, но один из старших Kaveri) с 4 заявленными ядрами и увидев производительность при загрузке всех 4 на уровне где-то 2.5 - 3 ядер, покопался и узнал, что на самом деле там всего два полноценных "вычислительных модуля" и почти все блоки, кроме базового целочисленного (т.е. FPU, SSE, AVX, ну и MMX заодно) существуют только в одном экземпляре для каждой пары ядер. Вот такие вот дутые ядра. И это еще мне повезло, в предыдущих Bulldozer и Piledriver даже декодер инструкций был общий на каждые два ядра. Т.е. вот это https://en.wikipedia.org/wiki/File:AMD_Bulldozer_block_diagr... гордо называлось "парой ядер" и в (якобы) 4-х ядерном процессоре только два таких блока.

Вы знаете какого-либо другого производителя x86 процессоров, который так же мухлевал с ядрами?

На AMD даже в суд за это подавали, между прочим: https://www.extremetech.com/extreme/217672-analysis-amd-laws...

Ответить | Правка | Наверх | Cообщить модератору

46. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +/
Сообщение от Аноним (46), 13-Фев-19, 00:36 
Ну фиг знает, что у вас то по производительности, но подход и правда хитрый. Другой вопрос, что много ли у вас в стандартном коде ОСи задействован fpu? (и тогда вопрос - на кой?)
Ответить | Правка | Наверх | Cообщить модератору

47. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +/
Сообщение от Stax (ok), 13-Фев-19, 00:41 
> Ну фиг знает, что у вас то по производительности, но подход и
> правда хитрый. Другой вопрос, что много ли у вас в стандартном
> коде ОСи задействован fpu? (и тогда вопрос - на кой?)

Поправил пост. Там не только FPU, но и SSE и AVX тоже общие! И целочисленный MMX. Все общее, кроме базового целочисленного модуля - хоть этот они поставили свой на каждое ядро. Если бы не сделали даже этого, оставались только бы раздельные регистры и это бы назвалось HT или SMT :) Но AMD называла это полноценными "ядрами".

А что касается "много ли где используются инструкции"... Тут ситуация такая, что обычно там, где не используются ни FPU, ни SSE, ни MMX, ни AVX производительность обычно-то и не нужна. Но замечу что даже memcpy() в glibc давно уже переписан на AVX, а при его отсутствии будет стараться брать SSE-версию. Даже куски памяти перемещать намного эффективнее блоками по 256 бит (или хотя бы по 128), чем по 64. Ну и вся криптография и распространенные хэш-функции (в т.ч. даже такие базовые вещи, как CRC32 - нужен, между прочим, очень много где даже в ядре) быстрее с этими инструкциями. Про мультимедию даже не заикаюсь.
На голом ALU быстро работать будут разве что вещи типа раздачи веб-контента. И то, memcpy/memmove/memset на AVX или SSE не помешают даже им. Вот эти функции https://github.molgen.mpg.de/git-mirror/glibc/tree/master/sy... с использованием SIMD в 2-3 раза быстрее, чем на ALU..

Кстати, по последним новостям (долго, однако, такие дела в суде идут, 4 года прошло) это дело таки признают, т.к. возражения AMD отвергли, и им придется серьезно заплатить за свои фейковые ядра: https://www.theregister.co.uk/2019/01/22/judge_green_lights_.../

Ответить | Правка | Наверх | Cообщить модератору

53. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +1 +/
Сообщение от Аноним (53), 13-Фев-19, 11:37 
Хороший будет прецедент, жирнота дезы ибо запредельная.
Ответить | Правка | Наверх | Cообщить модератору

64. "Опубликована техника скрытия вредоносного кода в анклавах In..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 13-Фев-19, 22:10 
Как хорошо, что на e2k ядра и впрямь полноценные.
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

70. "Опубликована техника скрытия вредоносного кода в анклавах In..."  –1 +/
Сообщение от Аноним (68), 14-Фев-19, 08:45 
Вот только его пользователи неполноценные. :)))
Ответить | Правка | Наверх | Cообщить модератору

79. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +/
Сообщение от пох (?), 15-Фев-19, 13:14 
> Ну фиг знает, что у вас то по производительности, но подход и правда хитрый. Другой вопрос, что
> много ли у вас в стандартном коде ОСи задействован fpu?

много. Я в отличие от вас помню времена, когда эмуляцию еще можно было выключить (а железный в моей 386 ни разу предусмотрен не был). Ну я был молодой и глупый, а вы уже можете просто подумать головой и угадать, что именно у вас произошло бы если бы по сей день так можно было сделать, без необходимости в натурном эксперименте?

> (и тогда вопрос - на кой?)

подумайте, если есть, чем ;-)

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

56. "Опубликована техника скрытия вредоносного кода в анклавах In..."  –3 +/
Сообщение от Аноним (56), 13-Фев-19, 13:39 
Ты ARM от AMD вообще отличаешь?
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

59. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +/
Сообщение от pavlinux (ok), 13-Фев-19, 14:53 
> Ты ARM от AMD вообще отличаешь?

Лошок, расскажи подробно отличия работы функции strncasecmp() на ARM и AMD?

Ответить | Правка | Наверх | Cообщить модератору

58. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +1 +/
Сообщение от pavlinux (ok), 13-Фев-19, 14:39 
> Вы знаете какого-либо другого производителя x86 процессоров, который так же мухлевал с ядрами?

Все ARM big.LITTLE

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

60. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +1 +/
Сообщение от Stax (ok), 13-Фев-19, 14:57 
>> Вы знаете какого-либо другого производителя x86 процессоров, который так же мухлевал с ядрами?
> Qualcomm, у всех ведь смарты 8-ядерные? :D

Но я про x86... *Вне* x86 такое бывало. Например в тех же Niagara (UltraSPARC T1) у 8 ядер было 8 целочисленных блоков и один FPU. Но там во-первых производитель про это явно заявлял и не предлагал брать во все задачи, а только в те, где FPU был не особенно нужен (веб-серверы, серверы БД, ERP, CRM - традиционно в серверах БД и финансовой сфере не используют FPU-вычисления с погрешностью, а считают на больших целых). А во-вторых, на SPARC FPU это всего лишь FPU, а тут AMD в общий блок с FPU поставила все SIMD, в т.ч. целочисленные типа MMX. А они на x86 очень важны. И возможностью перемалывать 128-и и 256-и битные операции за раз, и дополнительными регистрами, которых в x86 вечно не хватает.

Ответить | Правка | Наверх | Cообщить модератору

62. "Опубликована техника скрытия вредоносного кода в анклавах In..."  +1 +/
Сообщение от pavlinux (ok), 13-Фев-19, 20:27 
> Например в тех же

IBM Cell BE, одно ядро Power отрезано под внутренние нужды.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру