The OpenNET Project / Index page

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

Анализ влияния ключевого слова final на производительность программ C++

23.04.2024 14:03

Бенджамин Саммертон (Benjamin Summerton), автор системы трассировки лучей PSRayTracing, проанализировал влияние на производительность приложений использование в коде на языке С++ ключевого слова "final", появившегося в стандарте C++11. Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.

Проведённое Бенджамином тестирование показало, что производительность при использовании "final" сильно зависит от компилятора. При сборке в GCC действительно в заметном числе случаев производительность возрастала, но при сборке в Clang и MSVC производительность в большинстве случаев снижалась, причём более ощутимо. При этом большое влияние, кроме компилятора, имела платформа, например, проседание производительности больше проявлялись на системе с CPU AMD Ryzen 9 6900HX, чем на системе с CPU Apple M1.





Например, на системе AMD Ryzen 9 6900HX с Ubuntu 23.10 при сборке в Clang в 90% тестов при использовании "final" наблюдалось замедление работы как минимум на 5%, но в 2.5% случаев фиксировалось ускорение как минимум на 5%. Для GCC замедление на 5% фиксировалось в 0.9% случаев, а ускорение на 5% - в 15.8% случаев. В MSVC 5% замедление наблюдалось в 26.2% тестов, а 5% ускорение - 13.3%. Для себя автор исследования сделал вывод о необходимости избегать использования "final".

  1. Главная ссылка к новости (https://16bpp.net/blog/post/th...)
  2. OpenNews: Оценка изменения производительности СУБД PostgreSQL за последние 15 лет
  3. OpenNews: Mozilla, Google, Microsoft и Apple разработали тест производительности браузеров Speedometer 3.0
  4. OpenNews: Выпуск оптимизатора энергопотребления и производительности auto-cpufreq 2.2.0
  5. OpenNews: Для ядра Linux подготовлены оптимизации, повышающие производительность планировщиков ввода/вывода
  6. OpenNews: Новый JIT-компилятор Maglev позволил поднять производительность Chrome
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61051-cpp
Ключевые слова: cpp, benchmark, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (105) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:15, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А люди из интернета точно использовали final именно там, где нужно, а не везде его тыкали?
    Это нужно тестировать на виртуальных вызовах, а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
     
     
  • 2.2, Аноним (2), 14:24, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Это был финальный комментарий или компилятор заглючил?
     
  • 2.3, Аноним (3), 14:32, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".

    Вообще-то final именно для этого и придуман, причем, не только в C++.

     
  • 2.4, Аноним (4), 14:39, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И как я вызову виртуальный метод, если у меня final стоит на самом первом классе?
     
  • 2.8, Аноним (8), 14:43, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    final как раз нужен для класса с реализацией интерфейса. А числа автора показывают, что в основном ничего не меняется за искл забагованного clang-а
     

  • 1.5, Rev (?), 14:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Для себя автор исследования сделал вывод о необходимости избегать использованиЯ "final".

    А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)

     
     
  • 2.9, Аноним (8), 14:45, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +10 +/
    final это не метод оптимизации, а защита от гогнокода, особенно при работе в больших командах и в публичном коде
     
     
  • 3.56, Аноним (56), 20:49, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Большие команды это где?
    Средняя команда разарботчиков 8-12 челоек.
     
     
  • 4.92, Аноним (8), 12:53, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это там, где больше одного человека. За примерами команд >1K с общим кодом можешь, например, сходить в гугл или даже местный Яндекс.
     
  • 2.77, Аноним (77), 04:47, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)

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

     

  • 1.6, Sw00p aka Jerom (?), 14:41, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    в гцц ИИ еще не пихнули? :)
     
     
  • 2.57, Bottle (?), 20:53, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ещё бы не хватало, чтобы к коду с неопределённым и implementation-defined поведением добавились галлюцинации ИИ.
     
     
  • 3.72, Sw00p aka Jerom (?), 23:29, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Ещё бы не хватало

    лол, кек, компилятор ведь за меня лучше сгенерирует код машинный, и чем тут ЫЫ не помошник? ведь он тоже как и компилятор - "недочеловек".


     

  • 1.11, Аноним (11), 14:50, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А вообще каким боком final влияет на производительность кода? Он же нужен исключительно чтобы бить по рукам, не более того.
     
     
  • 2.16, Аноним (16), 15:25, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Поскольку нет наследников -> нет нужды смотреть в vtable -> можно дёргать методы напрямую, минуя виртуализаию
     
     
  • 3.24, Пряник (?), 16:22, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты умнее Бенджамина Саммертона.
     
     
  • 4.55, anonymous (??), 20:10, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не сложно.
     
  • 3.60, Аноним (60), 22:40, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то я не понял твою мысль.

    class base {
    public:
        virtual void f() = 0;
    };

    class derived1 : public base {
    public:
        virtual void f() {}
    };

    class derived2 final: public derived1 {
    public:
        virtual void f() {}
    };

    int main()
    {
        base *p = new derived2;

        p->f();  
        return 0;
    }


    По-твоему тут vtable не будет использоваться?

     
     
  • 4.75, Аноним (75), 00:37, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Даже с MSVC не будет.
    https://godbolt.org/z/aWGr639ej
     
     
  • 5.84, n00by (ok), 08:36, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Осталось ещё убрать final и посмотреть на листинг, для полного просветления.
     
     
  • 6.91, Аноним (91), 12:40, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тот пример действительно не покажет эффект от 'final', если компилятор умеет запоминать тип присвоенного ссылке или указателю объекта, а не ограничивается типом самой ссылки или указателя. Куда лучше тут подходит https://godbolt.org/z/aPKxEWMz5
     
     
  • 7.102, n00by (ok), 13:27, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Подходит лучше, пока нет определения функций-членов. При lto может быть проанализирован поток исполнения и разницы не окажется. Но даже если и окажется, то главный вопрос - почему вдруг с final медленнее, а не быстрее.
     
  • 4.89, siga (ok), 12:18, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    придумать такой сценарий, когда ключевое слово 'final' приводит к девиртуализации вызова, в принципе несложно https://godbolt.org/z/b9d7GhjxW

    а вот придумать ситуацию, когда оно сказывается негативно, уже сложнее. мне на ум пока приходит только невозможность применения EBCO https://godbolt.org/z/hE9aoc8Kc

     
     
  • 5.106, fuggy (ok), 17:48, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я пытался разобраться, но тут нет разницы в ассемблере между clang и gcc c final и без в первом случае. Откуда тогда разница в производительности берётся? Либо нужно более сложный кейс сравнивать.
     
     
  • 6.107, n00by (ok), 06:50, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мне тут другое непонятно. Автор тестов тестировал на своей библиотеке. Получил результат, вызывающий вопросы. Почему он не посмотрел асм и не нашёл ответ сам? Я в подобных случаях всегда смотрел и подчас открывал удивительные для себя вещи.
     
  • 3.81, bOOster (ok), 08:20, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хоть кто-то на опеннете знает как C++ работает.
     
  • 2.50, Аноним (50), 18:42, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Он же нужен исключительно чтобы бить по рукам

    ... тех недопрограммистов, кто его использует. Достало уже. То private/protected, которые через не особо надёжно работаюлие костыли обходить приходится, лишь бы форк фреймворка не компилировать, не поставлять и не сопровождать (а ведь один особо умный додумался задействовать доступ к защищённому члену класса и весь свой форк фреймворка в свой репозиторий скопировать, автоматически исключив возможность поставки этого хлама в каком-либо адекватном дистре, а PR, заменяющий протухший ненужный форк фреймворка на использование специально разработанного (не мной, очень популярная либа) и протестированного хака-костыля-обхода не принимает, видите-ли гарантий, что не поломают и что работать продолжит, тащи форк фреймворка и флатпак используй!).

     
     
  • 3.61, Ivan_83 (ok), 22:41, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Приватные/локальные патчи рулят, минус только в накоплении "техдолга".
    Но я думаю что при разумном использовании оно стабилизируется на каком то колличестве и дальше расти не будет.

    У меня примерно 15 патчей на фрю и 50-60 на порты, и дальше не растёт уже больше года.
    Что то приходит, что то уходит.

     
     
  • 4.76, Аноним (76), 02:31, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если эти патче не в апстриме - то твоя "FreeBSD" никакая не FreeBSD, а Ivan83BSD, которую будешь сопровождать сам, собирать сам, и использовать сам, потому что желающих ставить иваноподелки себе на комп даже в виртуалку нет.
     
     
  • 5.108, Аноним (108), 08:48, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Описал так, как будто это что-то плохое.
     
  • 3.94, Аноним (94), 14:50, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Privat и final действительно противоречат сути ООП т.к. мешают переиспользовать код, но с protected всё нормально.

    У любого объекта есть два интерфейса - один для использования через композицию (public) и один для использования через наследование (protected).

     
     
  • 4.117, Аноним (117), 02:36, 27/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ничему они не противоречат ООП - это не про наследование ООП - это про объекты... большой текст свёрнут, показать
     

  • 1.12, Аноним (12), 15:00, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что-то я не вижу AOCC и ICC в тестах. Именно они были бы актуальными для соответствующих процессоров.
     
     
  • 2.14, Ivan7 (ok), 15:10, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ICC давно уже сдох, вернее, его придушили.
    AOCC не интересно, т.к. это тот же Clang, причём только под Linux.
     
     
  • 3.105, Аноним (105), 16:52, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну С программистам виднее. Я к ним не отношусь, просто любитель.
     

  • 1.15, Бывалый Смузихлёб (ok), 15:23, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    > ключевого слова "final" [EN.cppreference.com/w/cpp/language/final]

    Это какой-то особенный вид чего-то, о чём стараются не говорить в приличном обществе. Надо обязательно в русскоязычной статье затолкать ссылку исключительно на англоязычную статью при наличии русскоязычной
    [RU.cppreference.com/w/cpp/language/final]

     
     
  • 2.18, Я (??), 15:41, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    какой плюсовик умеет читать документацию не на английском?
     
     
  • 3.41, Аноним (41), 17:54, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    КО: русскоязычный
     
     
  • 4.98, Aleksander256 (?), 09:58, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию на англицком языке
     
     
  • 5.99, Бывалый Смузихлёб (ok), 10:43, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию
    > на англицком языке

    Вопрос не в превозмогании( особенно на фоне обилия онлайн-переводчиков ), а в здравом смысле

     
     
  • 6.101, Aleksander256 (?), 12:55, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда пусть ссылаются только на статьи написаные на русском языке. Даже если она устарели и актуальна.
    Автор использует ресурс на котором будет 100% достоверная информация, и деллися этой ссылкой, потому что информация которую получаете по ней не введет читателя в заблуждение. Вот это здраво, а в каком состоянии информация на русском языке, это вопрос, полноценна она или нет, достоверна она или нет, отвечает критериям читателя или нет, итд. Если хотите можете взять на себя обязанность в поддержке русскоязычного ресурса, привести в порядок, но ссылаться на него или нет, это уже дело автора.
     
  • 5.103, n00by (ok), 13:29, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поставим вопрос иначе: какой % плюсовиков прочитал стандарт языка?
     
     
  • 6.109, Аноним (108), 08:53, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Звчем? Русский или английский?
     
     
  • 7.121, n00by (ok), 09:11, 28/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Звчем? Русский или английский?

    Вот этот - явно не читал стандарт.

     
  • 2.37, Аноним (37), 17:23, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Из любви к русскому языку - надо. Читать перевод на русский, чтобы в голове переводить обратно на английский, попутно избавляясь от затесавшихся гуртовщиков мышей - не любить русский язык.
     
  • 2.73, Аноним (73), 00:09, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Для упрощения процесса эта вики уже была переведена с помощью Google на ... и русский языки.

    не, пусть будет ссылка на англоязычную

     

  • 1.19, Швондик (?), 15:41, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    иногда можно повысить производительность до 70% если для выхода из сложных циклов использовать оператор goto
     
     
  • 2.20, Аноним (20), 16:00, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    а если использовать выход в первой строчке проги, производительность ещё сильнее повысится!
     
     
  • 3.21, Аноним (21), 16:18, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Нет, не повысится. Время исполнения уменьшится, но работа, выполненная за это время, будет равна нулю. Итого общая производительность тоже будет равна нулю — программа не делает ничего полезного для изначальной задачи, если только изначально не было цели сразу выходить.
     
     
  • 4.39, Аноним (20), 17:47, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Кто сказал, что в изначальной задаче надо было что-то делать? Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
     
     
  • 5.40, Аноним (21), 17:52, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто сказал, что в изначальной задаче надо было что-то делать?

    Если ничего делать не надо, то и задачи нет.

    > Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.

    Отлично, давайте уйдём глубже в философию и метафизику от точныз цифр.

     
  • 2.23, Аноним (-), 16:20, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > повысить производительность до 70%

    Одной функции или всей программы)?
    что-то мне подсказывает, что ты про первое

    > если для выхода из сложных циклов

    В плюсах этого можно достичь и другими способами, начиная от лямд, заканчивая просто return'ом.

    > использовать оператор goto

    Или превратить код в неподдерживаемые макароны, в которых потом еще много лет находить ошибки.

     
     
  • 3.27, Аноним (27), 16:26, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    спагетти*
     
  • 3.30, Швондик (?), 16:33, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    да я просто пошутил, у нас за goto сразу увольняют если увидят в коде
     
     
  • 4.38, Аноним (38), 17:44, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Значит вы в ядро не коммите
     
     
  • 5.86, n00by (ok), 08:43, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В ядре Си, а в теме - Си++.
     
  • 4.46, Ivan7 (ok), 18:04, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +10 +/
    За goto в C/C++ может уволить только абсолютно безграмотный чел, который никогда не кодил и не писал высокопроизводительные приложения. В некоторых случаях goto реально полезен, причём в этих случаях альтернатив ему особых нет, особенно это касается Си. А ассемблерный код вообще весь построен на тамошнем аналоге goto - jxx. Надеюсь, за jxx у вас никто никого не увольняет??? (А то тогда это совсем какая-то дикая дичайшая дичь.)
     
     
  • 5.85, n00by (ok), 08:42, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Некоторые и за "C/C++" увольняют, поскольку это маркер, что писавший не видит разницы. В С++ goto позволяет обойти конструкторы/деструкторы, что недопустимо.
     
     
  • 6.93, Аноним (93), 14:19, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    можно пример? Чтоб именно goto обошел конструктор/деструктор, а не какой-нить setjmp
     
     
  • 7.104, n00by (ok), 14:04, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > можно пример? Чтоб именно goto обошел конструктор/деструктор, а не какой-нить setjmp

    https://godbolt.org/z/KGaoGYq9W

    #include <iostream>

    struct S { S(); };

    int main()
    {
        goto uninit;
        int i(0);
        S s;
    uninit:
        std::cout << i;
    }

    example.cpp
    <source>(9): warning C4533: initialization of 's' is skipped by 'goto uninit'
    <source>(9): note: see declaration of 's'
    <source>(10): note: see declaration of 'uninit'
    <source>(11) : warning C4700: uninitialized local variable 'i' used
    Compiler returned: 0

    В GCC вам по умолчанию нужный ключик добавили, что бы это воспринималось как error.

    Стандарт явно запрещает лишь переходы в блоки try/catch (A goto or switch statement shall not be used to transfer control into a try block or into a handler).

     
     
  • 8.116, Ivan7 (ok), 16:12, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во-первых, в данном случае компилятор выдал кучу предупреждений Во-вторых, если... текст свёрнут, показать
     
     
  • 9.118, n00by (ok), 08:25, 28/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот именно, предупреждение По одному на каждый случай То есть куча -- ложно ... текст свёрнут, показать
     
  • 4.65, Аноним (60), 22:47, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    а за switch/case ? А за try/catch?
     
  • 2.42, Аноним (41), 17:56, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >если для выхода из сложных циклов использовать оператор goto

    Мы про ОО-язык говорим или где?

     
     
  • 3.48, Аноним (48), 18:24, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>если для выхода из сложных циклов использовать оператор goto
    > Мы про ОО-язык говорим или где?

    "Настоящий программист может писать Фортран^WСи-программы на любом языке!"

     
  • 3.53, Ivan7 (ok), 19:40, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А в ОО-языке циклы не нужны?
     
  • 2.63, Ivan_83 (ok), 22:44, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это тонкий троллинг :)

    goto полезен скорее для выхода по ошибке, к есдиному месту где очищаются ресурсы.
    Иногда там местки расставляют через строчку, чтобы разное колличество шаго деинициализации/освобождения ресурсов делать.

    А так, мне нравится режим фильтра, когда последовательно проверяются условия (не повышая вложенности) и стараются быстрее сделать break/continue/return.

     
     
  • 3.74, Швондик (?), 00:35, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    да я просто пошутил, я вообще никогда с программистами не работал
     
  • 3.87, n00by (ok), 08:46, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > goto полезен скорее для выхода по ошибке,
    > к единому месту где очищаются ресурсы.

    Это нормально в Си. В Си++ вместо этого используется RAII, и при наличии не POD типов goto опасен.

     
     
  • 4.110, Аноним (108), 09:00, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Использование RAII не освобождает от необходимости подчищать при выходе из цикла.
     
     
  • 5.119, n00by (ok), 08:30, 28/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Использование RAII не освобождает от необходимости подчищать при выходе из цикла.

    "можно пример?" (ц) Что и за кем необходимо подчищать.

     

  • 1.22, Пряник (?), 16:19, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.
     
     
  • 2.31, Sw00p aka Jerom (?), 16:35, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Требуется сравнительный анализ разработчиков всех этих компиляторов, стандарт языка вроде один, архитектура машинных команд вроде одна, оптимизации одни и те же, ток результирующий исполняемый код почему-то разный.
     
     
  • 3.36, Пряник (?), 17:20, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я это и сказал. Компилятор выдаёт на выходе код ассемблера сначала перед тем, как конвертировать в машинный. Код ассемблера и машинный равны примерно 1-к-1.
     
  • 3.44, Аноним (41), 17:59, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так повторямых сборок между Clang и g++ никто и не обещал.
     
     
  • 4.51, Sw00p aka Jerom (?), 18:56, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Так повторямых сборок между Clang и g++ никто и не обещал.

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

     
     
  • 5.64, Аноним (64), 22:44, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот это далеко не факт...
     
     
  • 6.67, Sw00p aka Jerom (?), 23:15, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Вот это далеко не факт...

    аргументы?

     
     
  • 7.111, Аноним (108), 09:02, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То что утверждается без аргументов опровергается также без аргументов.
     
     
  • 8.115, Sw00p aka Jerom (?), 12:37, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ок, далеко ходить не будем, возьмите абстрактную машину Тьюринга и опишите любой... текст свёрнут, показать
     
  • 3.66, Аноним (60), 23:06, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты объем кода шланга или гцц видел? Ну ок, покажи как надо делать. Потом сравнительный анализ тебя проведем
     
  • 2.78, Аноним (77), 04:52, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.

    Замер фактической производительность > чем гадание на ассемблере.

     

  • 1.25, Пряник (?), 16:24, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Впрочем тесты "с потолка" тоже полезны.
     
  • 1.26, Серб (ok), 16:26, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Для себя автор исследования сделал вывод о необходимости избегать использование "final".

    Вывод прямо противоположный результатам тестирования.

    Делаешь макрос который будет final для gcc и пустотой для MS и clang - профит.

     
  • 1.28, Аноним (28), 16:27, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Странный выбор у девелопера из опенсорса: промежуточный девелопмент релиз дистрибутива и MS компилятор.

    Люди в опенсорсе используют готовые релизы и другие компиляторы. Разве не...

     
     
  • 2.34, голос из леса (?), 16:48, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    стандартный "девелопер из опенсорс" с вероятностью 50% сидит на mac os, с вероятностью 40% на win. Остатки может и на linux.
     
     
  • 3.45, Аноним (41), 18:02, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Просмотрите исходники СПО-проектов. В подавляющем большинстве случаев там \0A-окончания строк. Сделайте вывод, кто на чём сидит.
     
     
  • 4.88, n00by (ok), 08:50, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну мы так на Венде делали. Специально, для повышения качества экспертизы.
     
  • 4.90, Аноним (90), 12:36, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Офигеть показатель. Наверное конец строки - это штука, которую принципиально невозможно настроить в редакторе или IDE? Надо будет глянуть как там у меня под виндой в Geany и Notepad++ сделано.
     
  • 4.96, Электрон (?), 07:46, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Показательнее пример Mozilla, разработчики Firefox пользуются Chrome в качестве основного браузера, везде Гуглосервисы.
     
  • 4.97, Электрон (?), 07:48, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Забыл еще написать про электронные адреса. Заглянуть в AUR - там повсеместно gmail указан.
     

  • 1.35, Аноним (35), 17:02, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.

    Ну да, не включали голову.

    > Для себя автор исследования сделал вывод о необходимости избегать использования "final".

    И этот не включал.

    Ну посмотри ты профайл, ассемблер, собери минимальный кейс на котором повторяется проблема, зашли в багзиллы. Это было бы исследование. А этот намерял неизвестно что, и ты поди - ключевого слова избегать будет. return'а ещё поизбегай.

     
     
  • 2.79, Аноним (77), 04:54, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вперед, Аноним.
     
     
  • 3.83, Аноним (83), 08:34, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    он Занят разработкой Важной Программы.
     
  • 3.112, Аноним (108), 09:06, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    "Сначала добейся"
     

  • 1.49, Аноним (49), 18:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Странно, в тех же исходниках clang часто используется прием:

    namespace {
    class Classname final : public Basename {
    void method() override {}
    };

    }

    Тогда выглядит глупо, что сами же разработчики компилятора это не оптимизировали

     
     
  • 2.62, Аноним (60), 22:44, 23/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    final может не только с классами использоваться (запрещая их наследовать), но и для методов-членов, запрещая дочерним классам их переопределять
     
  • 2.114, Пряник (?), 11:58, 26/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой же стрёмный синтаксис у плюсов... Обернули в какой-то namespace, два имени у класса, после функции какой-то override. Очень понятно.
     
     
  • 3.120, n00by (ok), 08:34, 28/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    namespace там скопировано от нечего делать.
     

  • 1.52, Аноним (52), 19:38, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Замедление при использовании final вызывает у меня культурный шок. Реализация виртуальных методов стандартна - в объекте хранится указатель на таблицу, в таблице указатель на код. final гарантирует, что наследники не переопределяли код, поэтому чтение таблицы компилятор может иногда выкинуть. Я просто не могу представить, что должен сделать компилятор, чтобы стандартный подход стал выполняться медленней. final и override - это в основном синтаксический сахар, чтобы бить по рукам тех, кто не синхронизирует изменения методов в предках и потомках, а также помощь читающим код, чтобы было видно виртуальные методы. Реально выкидывание чтения таблицы должно происходить крайне редко, обычно везде передаётся указатель на базовый класс с виртуальными методами без реализации.
    Из-за большой разницы в производительности, я склонен подозревать автора больше чем что-либо ещё.
     
  • 1.80, Аноним (-), 07:22, 24/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ко там хвалил шланг? Запомните, копилефтный GCC - это эталон качества.
     
     
  • 2.82, Аноним (82), 08:27, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Тормоза шлангового кода - это не баг, а фича. M$ не для того его спонсирует, чтобы тот обгонял их собственный, конкурирующий, закрытый продукт.
     
  • 2.95, Аноним (95), 22:04, 24/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gcc это вендорлок
     
     
  • 3.100, Аноним (100), 11:37, 25/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я считаю это позором
     

  • 1.113, Аноним (108), 09:13, 26/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >final was placed on just about EVERY interface.

    "Бездумное, механическое использование ключевого слова final в среднем понижает произодительность, поэтому лучше его избегать."

    Это точно ведущий разработчик, а не взятый по гендерной квоте?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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