URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 133489
[ Назад ]
Исходное сообщение
"Анализ влияния ключевого слова final на производительность программ C++"
Отправлено opennews , 23-Апр-24 14:15 
Бенджамин Саммертон (Benjamin Summerton), автор системы трассировки лучей PSRayTracing, проанализировал влияние на производительность приложений использование в коде на языке С++ ключевого слова "final", появившегося в стандарте C++11. Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61051

Содержание
Сообщения в этом обсуждении
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:15 
А люди из интернета точно использовали final именно там, где нужно, а не везде его тыкали?
Это нужно тестировать на виртуальных вызовах, а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:24 
Это был финальный комментарий или компилятор заглючил?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:32 
> а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:39 
И как я вызову виртуальный метод, если у меня final стоит на самом первом классе?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:43 
final как раз нужен для класса с реализацией интерфейса. А числа автора показывают, что в основном ничего не меняется за искл забагованного clang-а
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Rev , 23-Апр-24 14:39 
> Для себя автор исследования сделал вывод о необходимости избегать использованиЯ "final".

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:45 
final это не метод оптимизации, а защита от гогнокода, особенно при работе в больших командах и в публичном коде
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 20:49 
Большие команды это где?
Средняя команда разарботчиков 8-12 челоек.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 12:53 
Это там, где больше одного человека. За примерами команд >1K с общим кодом можешь, например, сходить в гугл или даже местный Яндекс.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 04:47 
> А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 23-Апр-24 14:41 
в гцц ИИ еще не пихнули? :)
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Bottle , 23-Апр-24 20:53 
Ещё бы не хватало, чтобы к коду с неопределённым и implementation-defined поведением добавились галлюцинации ИИ.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 23-Апр-24 23:29 
> Ещё бы не хватало

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


"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 14:50 
А вообще каким боком final влияет на производительность кода? Он же нужен исключительно чтобы бить по рукам, не более того.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 15:25 
Поскольку нет наследников -> нет нужды смотреть в vtable -> можно дёргать методы напрямую, минуя виртуализаию
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Пряник , 23-Апр-24 16:22 
Ты умнее Бенджамина Саммертона.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено anonymous , 23-Апр-24 20:10 
Это не сложно.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 22:40 
Что-то я не понял твою мысль.

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 не будет использоваться?

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 00:37 
Даже с MSVC не будет.
https://godbolt.org/z/aWGr639ej
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 24-Апр-24 08:36 
Осталось ещё убрать final и посмотреть на листинг, для полного просветления.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 12:40 
Тот пример действительно не покажет эффект от `final`, если компилятор умеет запоминать тип присвоенного ссылке или указателю объекта, а не ограничивается типом самой ссылки или указателя. Куда лучше тут подходит https://godbolt.org/z/aPKxEWMz5
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 25-Апр-24 13:27 
Подходит лучше, пока нет определения функций-членов. При lto может быть проанализирован поток исполнения и разницы не окажется. Но даже если и окажется, то главный вопрос - почему вдруг с final медленнее, а не быстрее.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено siga , 24-Апр-24 12:18 
придумать такой сценарий, когда ключевое слово `final` приводит к девиртуализации вызова, в принципе несложно https://godbolt.org/z/b9d7GhjxW

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено fuggy , 25-Апр-24 17:48 
Я пытался разобраться, но тут нет разницы в ассемблере между clang и gcc c final и без в первом случае. Откуда тогда разница в производительности берётся? Либо нужно более сложный кейс сравнивать.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 26-Апр-24 06:50 
Мне тут другое непонятно. Автор тестов тестировал на своей библиотеке. Получил результат, вызывающий вопросы. Почему он не посмотрел асм и не нашёл ответ сам? Я в подобных случаях всегда смотрел и подчас открывал удивительные для себя вещи.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено bOOster , 24-Апр-24 08:20 
Хоть кто-то на опеннете знает как C++ работает.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 18:42 
> Он же нужен исключительно чтобы бить по рукам

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan_83 , 23-Апр-24 22:41 
Приватные/локальные патчи рулят, минус только в накоплении "техдолга".
Но я думаю что при разумном использовании оно стабилизируется на каком то колличестве и дальше расти не будет.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 02:31 
Если эти патче не в апстриме - то твоя "FreeBSD" никакая не FreeBSD, а Ivan83BSD, которую будешь сопровождать сам, собирать сам, и использовать сам, потому что желающих ставить иваноподелки себе на комп даже в виртуалку нет.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 08:48 
Описал так, как будто это что-то плохое.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 14:50 
Privat и final действительно противоречат сути ООП т.к. мешают переиспользовать код, но с protected всё нормально.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 27-Апр-24 02:36 
Ничему они не противоречат. ООП - это не про наследование. ООП - это про объекты как "черные ящики", скрывающие детали реализации и работающие по контрактам. Контракт может быть как формальным (через interface в java), так и фактическим, это без разницы.

Private - это та самая инкапсуляция. Приватный метод от приватного свойства в этом смысла ничем не отличается - это внутрянка, о которой снаружи не надо ничего знать.

Final - это означает, что наследоваться надо не от конечной реализации, а от абстрактного класса, от которого унаследован финальный (или реализовывать интерфейс. Например, внутри в результате оптимизаций всё так тесно связано, что переопределение одного метода без понимания внутренностей приведет к фатальным последствиям. Разработчик этим прямо говорит - не надо от этого наследоваться. Или наследуйся дальше по иерархии, или используй делегирование.

Наследование вообще необязательно и заменяется делегированием всегда. То, что в конкретных C++ или Java для делегирования надо много копипастить - это особенности этих языков. Есть и другие.

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 15:00 
Что-то я не вижу AOCC и ICC в тестах. Именно они были бы актуальными для соответствующих процессоров.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan7 , 23-Апр-24 15:10 
ICC давно уже сдох, вернее, его придушили.
AOCC не интересно, т.к. это тот же Clang, причём только под Linux.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 25-Апр-24 16:52 
Ну С программистам виднее. Я к ним не отношусь, просто любитель.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Бывалый Смузихлёб , 23-Апр-24 15:23 
> ключевого слова "final" [EN.cppreference.com/w/cpp/language/final]

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Я , 23-Апр-24 15:41 
какой плюсовик умеет читать документацию не на английском?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:54 
КО: русскоязычный
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Aleksander256 , 25-Апр-24 09:58 
Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию на англицком языке
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Бывалый Смузихлёб , 25-Апр-24 10:43 
> Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию
> на англицком языке

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Aleksander256 , 25-Апр-24 12:55 
Тогда пусть ссылаются только на статьи написаные на русском языке. Даже если она устарели и актуальна.
Автор использует ресурс на котором будет 100% достоверная информация, и деллися этой ссылкой, потому что информация которую получаете по ней не введет читателя в заблуждение. Вот это здраво, а в каком состоянии информация на русском языке, это вопрос, полноценна она или нет, достоверна она или нет, отвечает критериям читателя или нет, итд. Если хотите можете взять на себя обязанность в поддержке русскоязычного ресурса, привести в порядок, но ссылаться на него или нет, это уже дело автора.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 25-Апр-24 13:29 
Поставим вопрос иначе: какой % плюсовиков прочитал стандарт языка?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 08:53 
Звчем? Русский или английский?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 28-Апр-24 09:11 
> Звчем? Русский или английский?

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:23 
Из любви к русскому языку - надо. Читать перевод на русский, чтобы в голове переводить обратно на английский, попутно избавляясь от затесавшихся гуртовщиков мышей - не любить русский язык.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 00:09 
> Для упрощения процесса эта вики уже была переведена с помощью Google на ... и русский языки.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Швондик , 23-Апр-24 15:41 
иногда можно повысить производительность до 70% если для выхода из сложных циклов использовать оператор goto
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 16:00 
а если использовать выход в первой строчке проги, производительность ещё сильнее повысится!
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 16:18 
Нет, не повысится. Время исполнения уменьшится, но работа, выполненная за это время, будет равна нулю. Итого общая производительность тоже будет равна нулю — программа не делает ничего полезного для изначальной задачи, если только изначально не было цели сразу выходить.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:47 
Кто сказал, что в изначальной задаче надо было что-то делать? Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:52 
> Кто сказал, что в изначальной задаче надо было что-то делать?

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

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

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 16:20 
> повысить производительность до 70%

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

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

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

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

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 16:26 
спагетти*
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Швондик , 23-Апр-24 16:33 
да я просто пошутил, у нас за goto сразу увольняют если увидят в коде
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:44 
Значит вы в ядро не коммите
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 24-Апр-24 08:43 
В ядре Си, а в теме - Си++.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan7 , 23-Апр-24 18:04 
За goto в C/C++ может уволить только абсолютно безграмотный чел, который никогда не кодил и не писал высокопроизводительные приложения. В некоторых случаях goto реально полезен, причём в этих случаях альтернатив ему особых нет, особенно это касается Си. А ассемблерный код вообще весь построен на тамошнем аналоге goto - jxx. Надеюсь, за jxx у вас никто никого не увольняет??? (А то тогда это совсем какая-то дикая дичайшая дичь.)
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 24-Апр-24 08:42 
Некоторые и за "C/C++" увольняют, поскольку это маркер, что писавший не видит разницы. В С++ goto позволяет обойти конструкторы/деструкторы, что недопустимо.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 14:19 
можно пример? Чтоб именно goto обошел конструктор/деструктор, а не какой-нить setjmp
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 25-Апр-24 14:04 
> можно пример? Чтоб именно 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).

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan7 , 26-Апр-24 16:12 
Во-первых, в данном случае компилятор выдал кучу предупреждений.
Во-вторых, если у человека вместо головы котелок, то ему ничто не поможет, и его ничего не спасёт.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 28-Апр-24 08:25 
> Во-первых, в данном случае компилятор выдал кучу предупреждений.

Вот именно, предупреждение. По одному на каждый случай. То есть "куча" -- ложно. Моё заявление "В С++ goto позволяет обойти конструкторы" подтверждено практикой.

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

> Во-вторых, если у человека вместо головы котелок, то ему ничто не поможет,
> и его ничего не спасёт.

Угу. А ведь можно было бы прицепиться к "деструкторы" в моей формулировке. И даже привести цитату стандарта. Но это ведь требует чтения стандарта, да?

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 22:47 
а за switch/case ? А за try/catch?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:56 
>если для выхода из сложных циклов использовать оператор goto

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 18:24 
>>если для выхода из сложных циклов использовать оператор goto
> Мы про ОО-язык говорим или где?

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan7 , 23-Апр-24 19:40 
А в ОО-языке циклы не нужны?
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Ivan_83 , 23-Апр-24 22:44 
Это тонкий троллинг :)

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

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Швондик , 24-Апр-24 00:35 
да я просто пошутил, я вообще никогда с программистами не работал
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 24-Апр-24 08:46 
> goto полезен скорее для выхода по ошибке,
> к единому месту где очищаются ресурсы.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 09:00 
Использование RAII не освобождает от необходимости подчищать при выходе из цикла.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 28-Апр-24 08:30 
> Использование RAII не освобождает от необходимости подчищать при выходе из цикла.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Пряник , 23-Апр-24 16:19 
Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 23-Апр-24 16:35 
Требуется сравнительный анализ разработчиков всех этих компиляторов, стандарт языка вроде один, архитектура машинных команд вроде одна, оптимизации одни и те же, ток результирующий исполняемый код почему-то разный.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Пряник , 23-Апр-24 17:20 
Я это и сказал. Компилятор выдаёт на выходе код ассемблера сначала перед тем, как конвертировать в машинный. Код ассемблера и машинный равны примерно 1-к-1.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:59 
Так повторямых сборок между Clang и g++ никто и не обещал.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 23-Апр-24 18:56 
> Так повторямых сборок между Clang и g++ никто и не обещал.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 22:44 
Вот это далеко не факт...
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 23-Апр-24 23:15 
> Вот это далеко не факт...

аргументы?

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 09:02 
То что утверждается без аргументов опровергается также без аргументов.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Sw00p aka Jerom , 26-Апр-24 12:37 
> То что утверждается без аргументов опровергается также без аргументов.

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

пс: https://ru.wikipedia.org/wiki/%D0%9C%D0%...


"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 23:06 
Ты объем кода шланга или гцц видел? Ну ок, покажи как надо делать. Потом сравнительный анализ тебя проведем
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 04:52 
> Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Пряник , 23-Апр-24 16:24 
Впрочем тесты "с потолка" тоже полезны.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Серб , 23-Апр-24 16:26 
> Для себя автор исследования сделал вывод о необходимости избегать использование "final".

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

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 16:27 
Странный выбор у девелопера из опенсорса: промежуточный девелопмент релиз дистрибутива и MS компилятор.

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено голос из леса , 23-Апр-24 16:48 
стандартный "девелопер из опенсорс" с вероятностью 50% сидит на mac os, с вероятностью 40% на win. Остатки может и на linux.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 18:02 
Просмотрите исходники СПО-проектов. В подавляющем большинстве случаев там \0A-окончания строк. Сделайте вывод, кто на чём сидит.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 24-Апр-24 08:50 
Ну мы так на Венде делали. Специально, для повышения качества экспертизы.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 12:36 
Офигеть показатель. Наверное конец строки - это штука, которую принципиально невозможно настроить в редакторе или IDE? Надо будет глянуть как там у меня под виндой в Geany и Notepad++ сделано.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Электрон , 25-Апр-24 07:46 
Показательнее пример Mozilla, разработчики Firefox пользуются Chrome в качестве основного браузера, везде Гуглосервисы.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Электрон , 25-Апр-24 07:48 
Забыл еще написать про электронные адреса. Заглянуть в AUR - там повсеместно gmail указан.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 17:02 
> Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.

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

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

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

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 04:54 
Вперед, Аноним.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 08:34 
он Занят разработкой Важной Программы.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 09:06 
"Сначала добейся"
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 18:39 
Странно, в тех же исходниках clang часто используется прием:

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

}

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

"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 22:44 
final может не только с классами использоваться (запрещая их наследовать), но и для методов-членов, запрещая дочерним классам их переопределять
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Пряник , 26-Апр-24 11:58 
Какой же стрёмный синтаксис у плюсов... Обернули в какой-то namespace, два имени у класса, после функции какой-то override. Очень понятно.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено n00by , 28-Апр-24 08:34 
namespace там скопировано от нечего делать.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 23-Апр-24 19:38 
Замедление при использовании final вызывает у меня культурный шок. Реализация виртуальных методов стандартна - в объекте хранится указатель на таблицу, в таблице указатель на код. final гарантирует, что наследники не переопределяли код, поэтому чтение таблицы компилятор может иногда выкинуть. Я просто не могу представить, что должен сделать компилятор, чтобы стандартный подход стал выполняться медленней. final и override - это в основном синтаксический сахар, чтобы бить по рукам тех, кто не синхронизирует изменения методов в предках и потомках, а также помощь читающим код, чтобы было видно виртуальные методы. Реально выкидывание чтения таблицы должно происходить крайне редко, обычно везде передаётся указатель на базовый класс с виртуальными методами без реализации.
Из-за большой разницы в производительности, я склонен подозревать автора больше чем что-либо ещё.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 07:22 
Ко там хвалил шланг? Запомните, копилефтный GCC - это эталон качества.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 08:27 
Тормоза шлангового кода - это не баг, а фича. M$ не для того его спонсирует, чтобы тот обгонял их собственный, конкурирующий, закрытый продукт.
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 24-Апр-24 22:04 
gcc это вендорлок
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 25-Апр-24 11:37 
Я считаю это позором
"Анализ влияния ключевого слова final на производительность п..."
Отправлено Аноним , 26-Апр-24 09:13 
>final was placed on just about EVERY interface.

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

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