LINUX.ORG.RU

Intel выпустила C++ STM Compiler версии 3.0 Prototype Edition

 , ,


0

0

STM — Software Transactional Memory — один из перспективных методов повышения быстродействия программ за счет распараллеливания на современных (и будущих) многоядерных процессорах.

Несмотря на распостраненное мнение, что удобство реализации STM — это одно из преимуществ функциональных языков (таких, как Haskell), Intel продолжает совершенствовать поддержку STM в своем компиляторе C++, в том числе и для Linux.

Среди новых фич:

  • транзакционные new, delete, конструкторы и деструкторы
  • транзакционный вариант библиотеки STL
  • и многое другое (полный список по ссылке)

>>> cписок нового в версии 3, пример кода, ссылка на скачивание

RCU не из этой темы?

Чем RCU хуже/лучше STM?

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

>бинарники -xW (ia32 , pentium4, sse2) >патчила patch-AuthenticAMD, который меняет cpuid check с GenuineIntel на AuthenticAMD, таким образом интеловский процессор для него становится чужим (как бы АМДшным) >результат - отказ в запуске из за того что процессор не соответствует тому что ожидается получить в cpuid check Теперь понятно.

Я патчил *.so из комплекта icc, причём только те, которые устанавливаются на AMD-based машину, на Intel-based ставил непатченные. Компилирую софт с указанием -shared-intel, и он работает и там и там, потому как указанная вами проверка на GenuineIntel/AuthenticAMD находится в so'шках (скорее всего, только в libsvml.so)

$ icc -o hello hello.c

$ ldd hello

libm.so.6 => /lib64/libm.so.6 (0x00002ba412215000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ba412497000)

libc.so.6 => /lib64/libc.so.6 (0x00002ba4126ae000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002ba4129fb000)

/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

$ icc -shared-intel -o hello hello.c

$ ldd hello

libimf.so => /usr/lib64/libimf.so (0x00002b65eaf7b000)

libsvml.so => /usr/lib64/libsvml.so (0x00002b65eb2df000)

libm.so.6 => /lib64/libm.so.6 (0x00002b65eb46a000)

libintlc.so.5 => /usr/lib64/libintlc.so.5 (0x00002b65eb6ed000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b65eb82a000)

libc.so.6 => /lib64/libc.so.6 (0x00002b65eba41000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002b65ebd8e000)

/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

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

>10.1 - @ AMD
> если были зададаны флаги -xW и выше

... и учимся читать что там написано про выше
 
> Fatal Error: This program was not built to run on the processor in your system.
> The allowed processors are: Intel(R) Pentium(R) 4 and compatible Intel >processors. Enables new optimizations in addition to Intel processor-specific >optimizations.


 O  Intel(R) Core(TM) processor family.  Code is expected to run properly
       on _any_ processor that supports SSE3, SSE2 and SSE instruction sets


ss@hyperblade-master:~> icc -v
Version 10.1

ss@hyperblade-master:~> cat /proc/cpuinfo | grep AMD
vendor_id       : AuthenticAMD
model name      : Dual Core AMD Opteron(tm) Processor 285
vendor_id       : AuthenticAMD
model name      : Dual Core AMD Opteron(tm) Processor 285
vendor_id       : AuthenticAMD
model name      : Dual Core AMD Opteron(tm) Processor 285
vendor_id       : AuthenticAMD
model name      : Dual Core AMD Opteron(tm) Processor 285


-xO наше всё ;))

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

> что продукт выше предполагает использование только Intel решений, не так ли?

Не так :) icc - лучший компилятор для оптеронов ;)

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

> а обосновать ? :)

Дело в том, что для нашей целочисленной библиотеки (криптографической) код скомпилированный GCC 4.3 для AMD64 показывал _гораздо_ лучшие результаты чем код скомплированный ICC 10.1.

Сейчас у меня под рукой есть только Core 2 Duo, я могу провести сравнение производительности порядка 30-40-ка целочисленных алгоритмов при компиляции GCC 4.4 и ICC 11.0 для IA32 и AMD64, если интересно...

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

>Дело в том, что для нашей целочисленной библиотеки (криптографической) код скомпилированный GCC 4.3 для AMD64 показывал _гораздо_ лучшие результаты чем код скомплированный ICC 10.1.

Криптография использует многоядерность и SSE2/SSE3 ?

У меня на плавучке icc генерирует cущественно более быстрый (до 15%) код чем на gcc и PGI и чуть более быстрый чем PathScale

Код плотно использует SSE2/SSE3 и многоядерность естественно ...

По тестам pathcc быстрее разве что в многопоточном стриме на копейку

gcc там близко не валялся.

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

>У меня на плавучке icc генерирует cущественно более быстрый (до 15%) код чем на gcc

Знал бы ты на сколько он существенно менее точный и соответствующий стандартам.

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

> Криптография использует многоядерность и SSE2/SSE3 ?

Многоядерность - естественно, а SSE2, SSE3 - нет, конечно.

> У меня на плавучке icc генерирует cущественно более быстрый (до 15%) код чем на gcc и PGI и чуть более быстрый чем PathScale

А у меня на целочисленных задачах ICC и близко не стоит рядом с GCC 4.3, 4.4 на AMD64.

Поэтому утверждать, что ICC для оптеронов самый лучший - нельзя, всё зависит от задач и от набора инструкций тоже (AMD64/IA32).

GCC 4.4 пробовали? С оптимизациями graphite?

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

>Знал бы ты на сколько он существенно менее точный и соответствующий стандартам.

На жёстких задачах точность ничем не отличается от gcc. Может вы не умеете его готовить ;) ?

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

>всё зависит от задач и от набора инструкций тоже (AMD64/IA32).

Согласен. Я имел ввиду использование векторизации и многоядерности (x86_64 only)

Кстати для оптеронов от третьего поколения и выше gcc потенциально более интересен но у меня второе поколение и там icc вне конкуренции

>GCC 4.4 пробовали? С оптимизациями graphite?

Пока нет

sS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.