The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Релиз набора компиляторов GCC 14, opennews (??), 07-Май-24, (0) [смотреть все]

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


2. "Релиз набора компиляторов GCC 14"  –1 +/–
Сообщение от Аноним (2), 07-Май-24, 14:26 
Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем в clang? Такая разница делает мне некомфортно. Вот это фрагмент, да

https://books.google.ru/books?id=xlkPDAAAQBAJ&lpg=PT413&ots=...

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

10. "Релиз набора компиляторов GCC 14"  +1 +/–
Сообщение от n00by (ok), 07-Май-24, 15:11 
> Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем
> в clang?

Потому что это наброс?

> Такая разница делает мне некомфортно.

"Такая", в смысле, воображаемая? Пока нет результатов тестов, нет разницы.

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

12. "Релиз набора компиляторов GCC 14"  –9 +/–
Сообщение от Аноним (2), 07-Май-24, 15:15 
Я привёл код, вперёд, воспроизводи. Почитай в интернете про ядерные кэши и планирование эксперимента заодно.
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от n00by (ok), 08-Май-24, 09:54 
> Я привёл код, вперёд, воспроизводи.

"Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть и опыт не ставил.

> Почитай в интернете про ядерные кэши.

Кеши ядер процессора не имеют отношения к файловым операциям. А вот файловый вполне влияет и заметно. Ты не слышал про прогрев? :)

> и планирование эксперимента заодно.

Этот твой ответ вполне укладывается в допустимую погрешность. ;)

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

142. "Релиз набора компиляторов GCC 14"  +1 +/–
Сообщение от Sw00p aka Jerom (?), 08-Май-24, 12:44 
> "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть
> и опыт не ставил.

какой хитрец, результаты ему заранее давай, чтоб он подвел под них собственные, в этом то и интрига. И по вашим результатам ясно будет, вроводили вы их или нет, может с потолка взяли, как говорили нам в школе :)

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

157. "Релиз набора компиляторов GCC 14"  –1 +/–
Сообщение от Аноним (2), 08-Май-24, 18:14 
Но ведь это не мне надо. Если тебе так тяжело написать мейкфайл на 20 строк (ещё 20 строк на тесты) и 60 строк достаточно примитивного кода (40 из которых скопировать), то, может быть, это всё просто не твоё. Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость, только то, что ситуация имеет место. Зависит от оборудования, тестовых данных, и так далее. А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. И неплохо бы посмотреть на твои результаты, прежде чем продолжать разговор.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

183. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от n00by (ok), 10-Май-24, 12:13 
> Но ведь это не мне надо.

В смысле, не тебе? Тебя кто-то заставил задать вопрос, якобы тебе интересен ответ?

> Если тебе так тяжело написать мейкфайл
> на 20 строк (ещё 20 строк на тесты) и 60 строк
> достаточно примитивного кода (40 из которых скопировать), то, может быть, это
> всё просто не твоё.

Мейкфайл для сборки одной единицы трансляции? Это не просто тяжело, мне такую бессмысленную деятельность религия не позволяет.

> Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость,
> только то, что ситуация имеет место. Зависит от
> оборудования, тестовых данных, и так далее.

Естественно, зависит. Потому ты и должен указать, что именно, чем, с какими ключами собирал. Что бы каждый мог тупо скопировать и посмотреть, так ли это в его случае. Это позволяет локализовать проблему.

> А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов.

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

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

Для продолжения разговора с тобой мне результаты не требуются - априори ясно, что ты не ставил эксперимент. Ты можешь с важным видом написать любую чушь: мне этого достаточно, что бы ответить, как оно принято в метрологии. Если настроение окажется подходящим.

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

187. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (2), 10-Май-24, 15:01 
>[оверквотинг удален]
> ли это в его случае. Это позволяет локализовать проблему.
>> А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов.
> Вот потому ты и должен указать, какой у тебя "тулчейн", что бы
> повторяли именно с ним.
>> И неплохо бы
>> посмотреть на твои результаты, прежде чем продолжать разговор.
> Для продолжения разговора с тобой мне результаты не требуются - априори ясно,
> что ты не ставил эксперимент. Ты можешь с важным видом написать
> любую чушь: мне этого достаточно, что бы ответить, как оно принято
> в метрологии. Если настроение окажется подходящим.

На этом можно и закончить разговор. Ты некомпетентен и способен только заниматься пустословием и глупо переводить стрелки. Да, меня интересует, почему используется такой неэффективный код в индустриально принятом компиляторе, но и только. Может быть, я что-то упускаю и этому есть оправдание.

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

Твоё желание зачем-то спорить с очевидным вообще странно выглядит. Я за полчаса собрал и протестировал все варианты во всех интересующих условиях (разные носители, разный размер файла) несколькими тулчейнами, изучил их в дизассемблере и выяснил много интересного благодаря тому же cachegrind, в котором видно, что именно создаёт задержки в коде.

И мне было вполне интересно выяснить наиболее эффективные приёмы чтения файлов и по какой причине в одних компиляторах они ощутимо более эффективны, чем в других. Если ты не способен воспроизвести такой элементарный эксперимент, то говорить тут просто не о чем, и тебе определённо стоит прекратить тратить своё и чужое время.

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

188. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от n00by (ok), 10-Май-24, 16:01 
> На этом можно и закончить разговор.

Так будь последователен, закончи. Зачем ты написал следом простыню? Возомнил, что я буду читать, когда ты не указал условия эксперимента?

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

189. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (2), 10-Май-24, 16:14 
Именно это я и сделал, попутно поставив все точки и указав на определённые когнитивные ошибки, а также абсолютную необоснованность домыслов. Немного приятно, что мои собственные домыслы о твоих способностях оказались корректными.
Ответить | Правка | Наверх | Cообщить модератору

197. "Релиз набора компиляторов GCC 14"  –1 +/–
Сообщение от n00by (ok), 12-Май-24, 10:12 
Спасибо, показал цену своих слов: написал "закончил" и следом два сообщения. Это понятнее для зрителя, чем отсылка к метрологии.
Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз набора компиляторов GCC 14"  +2 +/–
Сообщение от Пряник (?), 07-Май-24, 15:26 
Возьми да сравни код на ассемблере. Или нам за тебя это делать? Мне лень.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

20. "Релиз набора компиляторов GCC 14"  –2 +/–
Сообщение от Аноним (2), 07-Май-24, 15:44 
Так я вижу в дизассемблере, но это не ответ на вопрос "почему".
Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз набора компиляторов GCC 14"  –1 +/–
Сообщение от Аноним (33), 07-Май-24, 16:20 
Я тебе тайну открою, возможно. Под MacOS и iOS оно, вероятно, более оптимально компиляет ;)
Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз набора компиляторов GCC 14"  +1 +/–
Сообщение от Пряник (?), 07-Май-24, 17:27 
Если видишь, тогда сравнивай по одной команде. Всё познаётся в сравнении.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

126. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от n00by (ok), 08-Май-24, 09:58 
Это бессмысленное сравнение. Если уж сравнивать, то время исполнения одной (любой) команды и время чтения с накопителя.
Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз набора компиляторов GCC 14"  +1 +/–
Сообщение от Ivan7 (ok), 07-Май-24, 19:36 
Потому что код криво написан. Это и дураку ясно.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

75. "Релиз набора компиляторов GCC 14"  –3 +/–
Сообщение от Аноним (2), 07-Май-24, 19:39 
Почему все эти корпорации не могут написать clang не криво? Гнутый опенсорсный компилятор унижает всех этих корпоративных разработчиков.
Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз набора компиляторов GCC 14"  –1 +/–
Сообщение от Ivan7 (ok), 07-Май-24, 19:50 
Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо где-то что-то настраивать. Для достижения лучшей производительности часто приходится переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы и даже в десятки раз работает быстрее... Как-то так. Мне казалось, что стандартную библиотеку должны писать профессионалы, но нет...
Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз набора компиляторов GCC 14"  +2 +/–
Сообщение от тыквенное латте (?), 07-Май-24, 21:01 
> Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что
> код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных
> библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо
> где-то что-то настраивать. Для достижения лучшей производительности часто приходится
> переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться
> ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы
> и даже в десятки раз работает быстрее... Как-то так. Мне казалось,
> что стандартную библиотеку должны писать профессионалы, но нет...

без примера - ложь, звездёжь и провокация.

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

92. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (2), 07-Май-24, 22:24 
К clang много вопросов, не догадывается до достаточно простых вещей. В книге, кстати, рассматривается также и "переписывать какую-то функциональность самостоятельно", но что-то не впечатляет. Можно предположить, что только 1 вариант неплохо работает (но он ощутимо медленнее "улучшенных" вариантов):

        time -p ./bin/readfile_string.gcc "$TESTFILE"
        time -p ./bin/readfile_string.gcc "$TESTFILE"
        time -p ./bin/readfile_string.gcc "$TESTFILE"
---
real 12.70
user 1.54
sys 1.93
---
real 6.53
user 1.59
sys 1.76
---
real 5.95
user 1.63
sys 1.59
        time -p ./bin/readfile_string.clang "$TESTFILE"
        time -p ./bin/readfile_string.clang "$TESTFILE"
        time -p ./bin/readfile_string.clang "$TESTFILE"
---
real 11.67
user 0.92
sys 1.96
---
real 6.69
user 0.87
sys 1.68
---
real 5.73
user 0.88
sys 1.68
        time -p ./bin/readfile_resize.gcc "$TESTFILE"
        time -p ./bin/readfile_resize.gcc "$TESTFILE"
        time -p ./bin/readfile_resize.gcc "$TESTFILE"
---
real 10.72
user 0.12
sys 1.33
---
real 1.14
user 0.14
sys 0.99
---
real 1.14
user 0.15
sys 0.98
        time -p ./bin/readfile_resize.clang "$TESTFILE"
        time -p ./bin/readfile_resize.clang "$TESTFILE"
        time -p ./bin/readfile_resize.clang "$TESTFILE"
---
real 10.79
user 0.42
sys 1.44
---
real 1.35
user 0.47
sys 0.87
---
real 1.32
user 0.43
sys 0.87
        time -p ./bin/readfile_assign.gcc "$TESTFILE"
        time -p ./bin/readfile_assign.gcc "$TESTFILE"
        time -p ./bin/readfile_assign.gcc "$TESTFILE"
---
real 11.03
user 0.41
sys 1.86
---
real 3.86
user 0.44
sys 1.61
---
real 3.84
user 0.40
sys 1.56
        time -p ./bin/readfile_assign.clang "$TESTFILE"
        time -p ./bin/readfile_assign.clang "$TESTFILE"
        time -p ./bin/readfile_assign.clang "$TESTFILE"
---
real 11.04
user 0.76
sys 2.03
---
real 3.99
user 0.71
sys 1.55
---
real 5.06
user 0.71
sys 1.70
        time -p ./bin/readfile_whileread.gcc "$TESTFILE"
        time -p ./bin/readfile_whileread.gcc "$TESTFILE"        
        time -p ./bin/readfile_whileread.gcc "$TESTFILE"
---
real 31.52
user 29.94
sys 0.77
---
real 30.23
user 29.93
sys 0.25
---
real 30.20
user 29.90
sys 0.26
        time -p ./bin/readfile_whileread.clang "$TESTFILE"
        time -p ./bin/readfile_whileread.clang "$TESTFILE"
        time -p ./bin/readfile_whileread.clang "$TESTFILE"
---
real 101.05
user 93.37
sys 4.81
---
real 90.21
user 83.18
sys 4.93
---
real 89.42
user 83.58
sys 4.34

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

99. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Прадед (?), 07-Май-24, 23:50 
Гцц лучше в лайкли/анлайкли. Такое чувство что в шланге его пустым местом оставили
Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 03:46 
Переписывание тупо в лоб не особенно эффективно. Эффективно переосмысление задачи: изменение интерфейса какого-то функционала вместе с изменением модели его использования, что позволяет сделать более эффективную реализацию. В таком случае преимущество по производительности и/или памяти можно получить в разы и даже в десятки раз по сравнению со стандартными библиотеками С и С++, причём часто вместе с улучшением удобства использования. Иногда можно немного урезать функционал или гибкость, но сильно поднять производительность. В таком духе. Тем более программный интерфейс у стандартной библиотеки С++ такой себе, на любителя, часто очень многословный и плохо читаемый.
Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

96. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (96), 07-Май-24, 22:54 
Ой все, типа никто не знает что гцц пишет красношапка .
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

97. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (2), 07-Май-24, 23:06 
Сомневаюсь, у неё были только разработчики для avahi, но они перебрались в Майрософт.
Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз набора компиляторов GCC 14"  +/–
Сообщение от Аноним (102), 08-Май-24, 00:31 
Когда-то точно писала. В эпоху форка под названием egcs точно было. Но и сами они тогда были настоящей опенорсной компанией.
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

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

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




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

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