Russian Qt Forum

Очень часто некоторым студентам ставлю хорошую оценку без решения задачи, только за один единственный вопрос: а зачем нужен такой алгоритм, если он оптимизирует задачу на ~0.5%. К примеру: есть функция memset, надо 128kB заполнить быстрее чем эта функция. А надо ли учить их оптимизации с учетом быстродействия современных вычислительных систем?

Конечно надо. Сейчас на первое место ставят сроки разработки, от этого качество кода начинает сильно страдать. Оптимизацию "забывают", если нет явных просадок в производительности/ресурсах. Считаю это не правильным, с тоской вспоминаю положение дел лет 20-30 назад. Программированием занимались те кто это любил и хотел, поэтому умел, а сейчас это скатилось в покраску заборов, вместо рисования картин. :(

Насчет числовых показателей... там пару процентов, здесь пару процентов, а на выходе ускорились на 20. :)

Когда то в давние времена типа синклер и айбиэм часто применяли "асм"- вставки, которые повышали скорострельность), но с последующим выпуском турбоси и его привязки к процу вставки стали тормозить из-за оптимизации и можно было восхищаться разработчиками компиллеров. А сей час же питон, ява, руби, пихапи и др. выполняют то же самое но чуть дольше и нашим юзерам это визуально незаметно, пусть вместо 0.3 сек задача будет висеть 0.7, да и Х. с ним. Для больших задач в 30 мин. оптимизация снизит до 23 мин - ну и Х. с ним, скажут наши заказчики. А оптимиза стоит денег.
Кстати о ностальгии во вложении, наверняка у кого то есть круче))

Вот поэтому раньше я писал код в текстовом редакторе ed.com размером 64Кб, где даже была зашита подсветка синтаксиса для нескольких языков, а сейчас есть eclipse, который весит как все книги из библиотеки Ленина и тормозит даже на современном железе. :(

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

От задачи зависит. Иногда оптимизация это единственное, что позволяет продавать и стричь :)

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

Хороший вопрос. Ну что "более быстрое заполнение 128Kb" никому сейчас нафиг не нужно - это точно. Но с др стороны выражение "преждевременная оптимизация" давным-давно потеряло всякий смысл и используется для отмазки любого говнокода. Нередко удается без особых усилий ускорить код в 5 и более раз. Несколько типовых вещей

- передача структур по значению (часто оправдываемая имплисит шарой). С возвратом по значению тоньше, но тоже не все гладкo

- банальная распущенность. Напр такой код вряд ли будет осуждаться на форуме

C++ (Qt)
int red = qRed(image.pixel(x, y)) / 2;
int green = qQreen(image.pixel(x, y)) / 2;
int blue = qBlue(image.pixel(x, y)) / 2;

А ведь есть куда более быстрый доступ к пикселю. И, по крайней мере, никто не мешал сохранить рез-т в локальной переменной. И деление на 2 далеко не безгрешно. Но все это не считается важным, мол, "экономия на спичках".
 
Вот за такие вещи нормальный препод должен бить мокрым веником по заднице.

Узкоспециализированная задача))): был расчет для некого гироскопа на неком проце, медленно работал, оптимизация расчета заняла 2 месяца, руководство послало нахер всех математиков и купила новый проц :)

Если дешевле купить новый проц, то нафига заморачиваться с оптимизацией? У меня в проекте недавно тоже встал вопрос с ростом нагрузки и проседанием по скорости. В итоге, решили, что дешевле будет реализовать поддержку работы на нескольких серверах и докупать по серверу в год.

Когда-то кто-то решил, что труд программиста стоит дороже, чем новая железка. Так и появилась ява :)

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

Далеко не все даже очень известные и богатые фирмы пойдут на то, чтобы просто "купить новый проц".
Иногда жлобство просто зашкаливает.
Например, один из наших очень крупных заказчиков (фирма известная во всем мире) захотел, чтоб на один комп можно было ставить параллельно несколько экземпляров обслуживающего софта (чтобы каждый управлял отдельным роботом). Чтобы сэкономить на втором компе и мониторе :) Хотя само это требование уже будет стоить в итоге в разы больше...

ССЗБ. :)

Не раз убеждался что купить железо помощнее оказывается лучшим решением. Беда в том что проходится "точка невозврата". Ляпнув разок-другой чем-то типа QString::split человек уверяется что это совершенно нормально, так писать МОЖНО. И все, хана. Не надо питать иллюзий, что, мол, "вот когда нужно будет, тогда и напишет оптимально, а пока нечего заморачиваться". Это как любой алкаш заявит что, конечно, он может бросить пить в любой момент - но пока не хочет.

Вот неплохая статейка (https://habrahabr.ru/post/126818) на эту тему

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

Слышал историю, как один разработчик переписывал ради оптимизации функцию на асм. В результате через 2 недели получилась оптимизация на 4 мс.

Смотря что называть "десктопами". Конечно, нет особого смысла оптимизировать почтовый клиент или примитивный текстовый редактор (все равно пользователь не заметит разницы). Но когда речь идет о научных вычислениях или высокопроизводительных системах обработки данных, то как бы не всякий компилятор сможет помочь, если код изначально написан тормознуто.

Странно, почему же тогда все процессоры от интел имеют симд-инструкции, а не только узкоспециализированные ???

Ну в 90% программ оптимизация не нужна. Достаточно просто следить за чистотой кода.

А 10% узкоспециализированных - там и писать то надо для специализированных компьютеров/плисин.

PS ну есть ещё микроконтроллеры, но там тоже всё лучше становится. Разница в мощности современных мк многократна, а по цене почти незначительна.

а что плохово в QString::split  ?

Не статья, а какое-то говно.
Собаку съел на профилировании - всегда тормозит "пара функций". Другое дело, что эти пару функций будешь переписывать месяц:)
К примеру - вот у нас есть TableView, которая постоянно вставляет-удаляет строки. И мы видим, что тормозит paintEvent (жрет 90% ядра). Ваши действия? Будем выжимать из каждой строки в нём максимум аки стандартная библиотека?

По сабжу - мы считаем, что memset написан втупую ака while(*c++) или всё мы знаем, что в современных библиотеках мемсет уже дано использует SIMD инструкции и надо быстрее них написать?

ЗЫ: присоединяюсь к вопросу про string::split.

То, что он удобен и что он потребляет ресурсы.

Т.е. проход по std::char будет выгоднее по ресурсам, но неудобнее для программиста :D

PS статейка шлак. Какая то невнятная отсебятина с криво опущенными графиками.  Мало того он приводит html страничку в качестве примера... Это же блестящий пример :D

А что, мы не знаем, что компилятор оптимизирует деление на степени 2 в сдвиг? Хотя для работы с пикселями сдвиги нагляднее, имхо. Хотя иногда и вредны:)

это ответ про QString::split  ?
мысль не раскрыта

Ну, особо упертые типа Igors, борются за каждую инструкцию. QString::split в разы массивнее такой же конструкции на чистом C. И пусть падение быстродействия где то 0,5%, их это всё равно не устраивает.

Можете поискать, он серьёзно борется с этим и пишет об этом в каждой теме, где есть это сочетание :D

Да пофиг на QString::split. Функция как функция, юзать удобно, и это главное. Для гуя пойдет.
Для хардкорной оптимизации - нет. Но для этого, как правило, все равно другие способы есть.
Посыл темы был, я так понимаю, в том, что мощность процессоров развращает - и народ не то что не оптимизирует,
а даже не думает об эффективности написанного говнокода. Зачем, есть же умный компилятор, а если он не разрулит,
то докинем еще памяти и проц заменим. А мозги можно выключить и передавать вектора по значению.
Как то так, в общем.

А так по сути и есть. И это называется эволюцией.

Раньше надо было все регистры знать процессора, все инструкции. Что то не так сделал - капец.
А эволюция то идёт, теперь вместо достоверного знания всех инструкций мы запоминаем конструкции языка.
А ещё дальше, я верю, будет компилятор понимающий базовые вещи на  обычном языке. И даже тогда будут находиться люди, говорящие - а вот раньше, мы писали на c++ и чтобы файл прочитать надо было написать 24 строки, а сейчас просто сказать "прочитать файл".

"Раньше было лучше..." ©

А тут все как раз наоборот :) Если есть последующие вычисления я бы соскочил в float, т.е. делил бы на 255.0f / 2. Xотя большинство расчетов можно исполнить и в интах без потери точности, это часто сложно, а главное - загромоздит код. Тут опять мы знаем что "целочисленная арифметика намного быстрее плавающей" - но опять знаем не то и кое-как (типа "почитал/слышал" :))

Для каждой найденной подстроки создается новый QString. Все они помещаются в контейнер, который тоже нужно создать. И потом еще затратить время на удаление всего этого. Поэтому неудивительно что часто синтаксический разбор ускоряется в N раз просто вычисткой split

Ничего подобного, ф-ционал спланирован отвратно. Напр
В первом случае (после того как юзер ткнет носом) придется сначала по-колхозному заменить табы на пробелы. Во втором пооткусывать пробелы. Эти операции тоже недешевые. Где же "удобство"? А у кого-то еще хватит ума решать это через QRegExp. В итоге смех и грех - "на скриптах разбирается быстрее - вот видите, скрипты уже догнали плюсы"  :)

Справедливости ради надо отметить что тролли учли критику и сделали QStringRef::split. Вообще QStringRef - отличный класс, практически без накладных расходов.

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

Там где разбирают текстовые файлы - там вообще пофиг на производительность.
А вот к примеру расчёт траектории, сканирование местности или же обработка поступающих данных в 10 гб/с, вот где узкая специализация. Ну ещё можно добавить системы безопасности допустим той же АЭС.

Справедливости ради, в Qt6 уберут QStringRef и сделают, чтобы QString сам себе был рефом. И QString::split магическим образом перестанет аллоцировать память. И вам придется переписать код взад. Выпендриваясь "потому что это неоптимально", вам придется дважды написать один и тот же код.

а если файл на десяток гигов? которые надо быстро распарсить и обработать?

Текстовый формат и быстродействие - это две большие разницы. Во всяком случае бинарные форматы оставляют текстовые форматы далеко позади по быстродействию.

Вы очень много читаете, а я почти ничего (все время съедает предметная часть). Тем не менее (да-да, ничего не слышав) рискну утверждать что этого не произойдет, рефом QString не станет. Просто потому что это уже др сущность, а значит уже и др класс. А вот что Вы верите в такие "сказки про белого бычка"....  :)

"говно", "Выпендриваясь" и.т.п. - так грубо реагируя Вы только показываете что боитесь за свой код.  Да и вообще грубить нехорошо, и главное - совершенно неэффективно  :)

Не-а, тот же. Сейчас QString это
А достаточно переделать

Лазить в этих потрохах нет необходимости (вообще изучение исходников Qt хорошо до определенного предела).

C++ (Qt)
QString src("a b c ...");
QString sub = SomeMagic(src);
 

Допустим с помощью имплисит шары мы сделали так что sub не аллоцирует свои данные, а ссылается напр на "a" в src. Это возможно, но тогда при первом же неконстантном обращении к src надо копировать ее данные отдельно. Тогда sub должен ответить за удаление оригинала. Не слабо выходит - используется одно "а", а хранится вся строка, может неск метров :) Да и копирование может оказаться куда расходнее чем создание крохотного sub. В общем типичный "implcit" (не только в Qt, а неявное действие вообще) - всегда выглядит ну очень заманчиво, но расплата неизбежна  :)

QStringRef копировать тоже дорого, и что?
QStringRef тоже валиден, пока валидна исходная строка "на несколько метров".
Только при неявной шаре вы не выстрелите себе в ногу, удалив исходную строку.

Не понял, как же дорого если данных QStringRef с гулькин нос?  QStringRef - это чистой воды explicit, где все определено явно. Начиная с названия класса, всем видно - ссылка. Это хорошо и правильно, так и надо делать. Да, изменю исходную строку - огребу, но мне было прекрасно известно что менять нельзя. Сам виноват - сам исправлю, и это куда проще и лучше чем кто-то за меня будет чего-то делать втихаря.

Ну хорошо, а откуда неуемное желание застрелить QStringRef? :) Читает по константному указатели и меняет пару индексов. Каким же принципам или правилам языка это противоречит?

Ну вы сами привели юзкейз, абсолютно нерелевантный использованию стрингрефа, он тут не нужен:

Реф нужен, чтобы работать с кусками исходной строки (например, частями пути к файлу), почти всегда это readonly доступ. Максимум, что я могу придумать на write - это replace конкретных символов, что-то более сложное надо делать на исходной строке, чтобы рефы не поехали.

Есть желание застрелить его и заменить на QStringView:

Мой поинт в чем - сделать эффективный mid()/split() можно и без QStringRef/QStringView и сидеть писать многокод "потому что так быстрее" смысла нет (если не доказано профайлером, что именно это является узким местом).