• Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Да, весьма интересно. Начиная с версии компилятора 14.0 (то есть не так уж и давно, точно позднее 2010 года, когда была написана та статья), был изменён диспатчинг. Теперь проверяется не сам процессор, а набор фич, которые процессор поддерживает.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Собственно, подобное и делает gcc, и кэширует часть вычислений. Возможно, что в 18 версии (не Бета) на этом примере мы тоже сделаем подобное, ведь не просто так я копался сидел.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    icc делает всё «в лоб», то есть
    a0 = fib(43);
    a1 = fib(42);
    a2 = fib(43);
    a3 = fib(44);
    a4 = fib(45);
    А можно было бы оптимизировать так:
    a0 = fib(43);
    a1 = fib(42);
    a2 = a0
    a3 = a2 + a1;
    a4 = fib(45);
    a4 = a3 + a0
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Ну дизассемблер нам не нужен, раз у нас в руках компилятор есть. Можно сразу посмотреть ассемблер. Быстро глянул, и заметил, что в случае с дефолтными опциями оба компилятора генерят примерно одинаковый код для main, вызывая fib. А вот c O3 gcc придумал что-то поинтереснее — он там организовал цикл для вызова fib:
    main:
    .LFB12:
    subq $8, %rsp
    .LCFI15:
    movl $45, %esi
    xorl %r8d, %r8d
    .p2align 4,,10
    .p2align 3
    .L46:
    cmpq $1, %rsi
    jbe .L47
    leaq -2(%rsi), %rdx
    xorl %ecx, %ecx
    .p2align 4,,10
    .p2align 3
    .L45:
    movq %rdx, %rdi
    call fib
    subq $1, %rdx
    addq %rax, %rcx
    cmpq $-1, %rdx
    jne .L45
    addq $1, %rcx
    .L44:
    subq $1, %rsi
    addq %rcx, %r8
    cmpq $-1, %rsi
    jne .L46
    leaq 1(%r8), %rsi
    movl $.LC0, %edi
    xorl %eax, %eax
    call printf
    xorl %eax, %eax
    addq $8, %rsp
    .LCFI16:
    ret

    А по дефолту это выглядело так:
    main:
    .LFB1:
    pushq %rbp
    .LCFI4:
    movq %rsp, %rbp
    .LCFI5:
    subq $16, %rsp
    movl %edi, -4(%rbp)
    movq %rsi, -16(%rbp)
    movl $47, %edi
    call fib
    movq %rax, %rsi
    movl $.LC0, %edi
    movl $0, %eax
    call printf
    movl $0, %eax
    leave
    .LCFI6:
    ret

    В icc похожее на дефолтное у gcc. Нужно взять VTune и посмотреть более детально, могу даже пост про это написать. Но мне думается, что мы просто похуже работаем с рекурсиями, потому что они не очень то востребованы — только в образовательных целях.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Магия опций!
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Да, с О3 интеловский компилятор уже медленнее. Нужно посмотреть, что делал gcc с O3.
    Но опять таки — без векторизации не стоит ожидать чудес от компилятора.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Ну и стоит сказать, что на таких тестах не стоит ожидать большей производительности, векторизации здесь нет.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Только что протестировал:
    $ gcc --version
    gcc (GCC) 6.2.0
    Copyright © 2016 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ gcc test.c
    $ time ./a.out
    4807526976

    real 0m15.512s
    user 0m15.465s
    sys 0m0.000s

    $ icc -V
    Intel® C Intel® 64 Compiler for applications running on Intel® 64, Version 17.0.4.196 Build 20170411
    Copyright © 1985-2017 Intel Corporation. All rights reserved.

    $ icc test.c
    $ time ./a.out
    4807526976

    real 0m10.567s
    user 0m10.529s
    sys 0m0.000s
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Компилятор просто делает ряд оптимизаций лучше, в частности, максимальный прирост даёт векторизация. Если её отключать в нашем компиляторе, то это большой вопрос, будет ли прирост (даже если отключить её для сравнения и в других компиляторах). Векторизатор умеет распознавать достаточно сложные конструкции, и на выходе мы имеем большее число циклов, которые используют регистры по «максимуму», и при этом с использованием последних инструкций. Конечно, и другие оптимизации могут «додавать» производительности, но это ключевая.
    Безусловно, у компиляторов Intel есть опции для оптимизации под конкретную микроархитектуру, и здесь мы тоже получим дополнительное преимущество. Тем не менее, возможность сгенерировать код под другие процессоры тоже есть. Возможно, где-то выложены сравнения компиляторов и на других процессорах, мы это не отслеживаем.
    В целом, высокая производительность получаемого кода всегда была и остается основным преимуществом Интеловских компиляторов, поэтому сюда и инвестируется много ресурсов/времени.
    У gcc есть ряд своих преимуществ, например доступность, открытость кода, поддержка языковых стандартов (появляется чуть раньше, чем у нас).
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    +1
    И ещё одно замечание «вдогонку». В вопросе так же был интерес в самом времени компиляции, а не только выполнении. И вот тут у нас должен быть ощутимый прогресс в 18 версии, поскольку было пофикшено несколько подобных проблем (как в сравнении с gcc, так и с Visual C++, когда мы существенно дольше собирали код).

    Но это всегда оборотная сторона медали — если хочешь, чтобы компилятор хорошо (читай как дольше) оптимизировал код, а приложение потом хорошо (читай как быстро) исполнялось — придётся где-то тратить больше времени (или на этапе компиляции, или выполнения).
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    +2
    Пардон за много букв. Более короткий ответ — обычно мы не хуже gcc, а если ваш тест покажет обратное — вам точно нужно связаться с нами, и, очень вероятно, это будет исправлено. В поддержке кроется весомое преимущество.
  • Новые «плюшки» компилятора – безопасней, быстрее, совершеннее
    0
    Да, это конечно важный вопрос. Показывать насколько хорош в плане производительности компилятор принято на общеизвестных тестах/бенчмарках. Так принято в индустрии. Эти тесты могут быть как «идеальными конями в вакууме», так и более сложными, приближенными к реальной жизни (они разные). Для С++ мы часто ориентируемся на SPEC, и в посте про прошлую версию 17.0 я давал данные по производительности на этой бенчмарке:
    image
    На конкретном железе и с данными версиям компилятора выигрыш был ощутимый (порядка 60% с Microsoft и 50 с GNU).
    Для 18 версии данные тоже будут подготовлены позднее и, думается, сравнивать будем уже с 2017 версией.
    Но если есть желание понять, какой будет прирост на именно вашем приложении (а это то, что обычно интересует разработчиков, а не цифры про «вакуум»), то имеет смысл просто качнуть тестовую бесплатную версию (для этого она у нас и есть) и посмотреть своими глазами. Обычно, поиграв с опциями из этого поста, можно весьма неплохо разогнаться.

  • Неинициализированные переменные: ищем ошибки
    0
    Такого рода опции используются в целях отладки и нахождения ошибок в коде, поэтому их overhead не критичен.
    Но посмотреть возможные исключения через fpe0 можно и с release билдом, чтобы убедиться, что компиляторные оптимизации не приводят к проблемам в вычислениях. Для финального билда их нужно отключать.
  • Прогресс не стоит на месте: OpenMP 4.5
    0
    Да, функциональность растёт, но всё же с windows API или pthreads сложно сравнивать, потому как концепция другая.
  • Intel® Parallel Studio XE 2017: «Python к нам приходит» и другие новинки
    0
    Идея отличная, и лично я двумя руками за неё, но пока этого нет. На данный момент есть такие варианты получить лицензию: https://software.intel.com/en-us/qualify-for-free-software
    Отмечу, что её можно получить (для Linux) активным участникам Open Source проектов, а так же студентам и преподавателям в образовательных целях (уже без ограничений на ОС).
  • Intel® Parallel Studio XE 2017: «Python к нам приходит» и другие новинки
    0
    У Intel несколько поменялась концепция установщика. Теперь доступны не 3 разных версии для скачивания, а можно выбирать компоненты. В результате сгенериться установщик, содержащий только необходимые вам части, который и нужно скачать. Так вот в рамках этой концепции, триал на Professional не очень и нужен. Просто получаем триал на Cluster (он содержит в себе все компоненты Pro), и выбираем что будем качать.
  • Intel® Parallel Studio XE 2017: «Python к нам приходит» и другие новинки
    0
    Это не совсем правда. Все библиотеки доступны по Community лицензии здесь. Пакет с Python так же бесплатен, а вот за компиляторы придётся платить денежку. Но имеется большое разнообразие лицензий, в том числе и бесплатных. Так что это всё же не для тех, у кого много денег, а для тех, кто заинтересован в более высокой производительности.
  • Intel® Parallel Studio XE 2017: «Python к нам приходит» и другие новинки
    0
    В самом начале поста я рассказываю о том, что входит в Parallel Studio. Это и компиляторы, и библиотеки, различные средства динамического анализа. В целом, «эта штука» для разработчиков, которые заботятся о производительности своего кода.
  • Intel Parallel Studio XE 2016: новые возможности компилятора C/C++
    +3
    Я бы не сказал, что компилятор от Интел в плане поддержки стандартов проигрывает. Скажем, тот же С++11 полностью поддерживается у Microsoft только с VS2015, а в Интеловском с прошлой версии 15.0, что даже чуть раньше. На Windows для Интела ориентир в сторону Visual C++, на Линуксе gcc. GNUшному конечно, проигрывает в каких то фичах, но зато OpenMP лучше поддерживает(4.0 раньше всех поддерживался). В целом не всё так однозначно.
  • Intel Parallel Studio XE 2016: новые возможности компилятора C/C++
    0
    Если пробовать новые фичи С++ -то да, будут вылазить проблемы, как и с любым новым кодом — багфикс ещё никто не отменял.
  • Intel Parallel Studio XE 2016: новые возможности компилятора C/C++
    +3
    В первую очередь тем, кто заботится о производительности своего приложения и хочет использовать максимум от своего «железа».
    В частности, в HPC он очень востребован. А ещё тем, кто хочет получить хорошую поддержку, ибо баги есть в любом компиляторе, весь вопрос как быстро их решат для вас.
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    0
    Я скоро напишу подробный пост про всё «новое» в лицензиях
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +2
    Согласен, поправил поэтому.
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +2
    Выделили бы жирным, как про «скриптовый» язык. Вы правы, фреймворками являются Spark и Hadoop. Cassandra попала для «кучности», но не вижу в этом проблемы. Да, можно дописать и MySQL, MSSQL и прочее.
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +4
    А что сколько злости? Всё я осилил, я подумал, что акцент на Scala. То, что он скриптовый — не совсем верно, лучше поставить это в кавычки.
    «To some, Scala feels like a scripting language» — я эти some.
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +4
    MySQL, MSSQL прочее- это просто базы данных. В том же Spark'е кроме SQL имеется ряд библиотек и средств (MLLib, GraphX, Spark Streaming).
    Это больше, чем просто СУБД. Аналогично с Hadoop'ом.
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +1
    А в чем WTF? Spark разработан с помощью Scala и он является основным языком.
    Кроме того поддерживаются Python и Java, R. Можно почитать подробнее здесь:

    www.scala-lang.org/what-is-scala.html
    www.quora.com/Why-is-the-default-language-for-Spark-MlLib-Scala-and-not-Python-or-Java
    spark.apache.org/docs/1.2.1/mllib-guide.html
  • Новая бесплатная библиотека для аналитики данных Intel® DAAL
    +3
    Всё поправили
  • Оптимизация циклов: нужны блоки
    0
    Не смотрел статью Криса, но общая идея — не доводить до использования DDR, потому как медленная она. Желательно, чтобы доступ был последовательный и данные были в кэше.
  • Когда размер имеет значение
    0
    Интересная задача, вполне выполнимая. Вот только нас интересует правильный баланс, а его скрипту понять сложно. Но облегчить жизнь такой скрипт мог бы.
  • Когда размер имеет значение
    0
    Не совсем перевод, но этот документ моих коллег по команде я использовал как базу.
  • Когда размер имеет значение
    0
    Я конечно игрался на примерах со всеми этими опциями, но не стал включать результаты. Дело в том, что они очень зависят от самого кода. Скажем у меня опция, отключающая передачу аргументов через регистры уменьшала размер даже больше, чем векторизация. Всё очень индивидуально, и нужно смотреть на код, чтобы делать выводы.
  • «Ра-а-авняйсь, смирно!». Выравниваем данные
    +1
    Ну, в таком случае, если верить приведенной вами инфографике и этой статье MSDN, как минимум 41% (36% VS и 5 % Intel) поддерживают alignas только в последних релизах (VS2015, Intel Compiler 15.0). Вряд ли все уже поставили себе VS2015, не правда ли? На gcc даже не смотрел к какой версии стали поддерживать, её попроще достать.
    А вообще, учитывая «небесплатность» некоторых компиляторов (в частности от Intel), разработчики далеко не всегда спешат ставить самую последнюю версию, предпочитая оставаться на какой-то одной по 2-3 года. Я к тому, что ещё не у всех стоят версии компиляторов, поддерживающие alignment фичи из С++11. Не вижу в этом ничего удивительного.
  • «Ра-а-авняйсь, смирно!». Выравниваем данные
    0
    Компилятор часто делает несколько веток или пытается выравнять через peel loop в случаях, когда ничего не знает о выравнивании.
    Ну и как я говорил, он не стесняется использовать невыравненные инструкции, потому что по скорости они на современных процессорах не проигрывают выравненным (при условии выравненных данных).
  • «Ра-а-авняйсь, смирно!». Выравниваем данные
    0
    Можно тоже почитать мою статью про векторизацию в Интеловском компиляторе здесь.
  • «Ра-а-авняйсь, смирно!». Выравниваем данные
    0
    Да, векторизует, и да, вполне вероятно, что этого будет достаточно, нужно только ещё перед циклом сказать компилятору через директиву, что данные выравнены.
  • «Ра-а-авняйсь, смирно!». Выравниваем данные
    0
    Спасибо, очень дельное замечание. Стоит только отметить, что поддержка C++11 тоже весьма ограничена в компиляторах, поэтому проблема при переходе на другой компилятор тоже возникнет, но в будущем более правильное решение для С++. Скажем, alignas начали поддерживать в Intel C++ только с версии 15.0 (aka Intel Parallel Studio XE 2015 Composer Edition for C++).
  • Сказ о том, как «цифирь» не сошлась
    0
    Алгоритм «урезания» заложен в стандарте IEEE 754, и компилятор его поддерживает. Но если вы посмотрите пост, на который я ссылался в самом начале, то увидите пример, когда всё в соответствии с стандартом, а результат зависит от порядка суммирования, потому что критичны случаи, когда складывается большое и очень маленькое число.
  • Сказ о том, как «цифирь» не сошлась
    +1
    В самом начале я давал ссылку на статью, где проблема описана намного шире и детальнее. Здесь речь в основном о частном случае, а именно использовании OpenMP и возможностей по контролю воспроизводимости там.
  • Сказ о том, как «цифирь» не сошлась
    0
    Всё просто — так быстрее!