Вообще статью можно экстраполировать несколько больше (я читал например исследования товарища по имени David Rock на эту тему, а также проходил тренинг). В итоге выводилось утверждение, что решение любых нетривиальных задач, а особенно задач с высокой степенью неопределенности вызывает фактически физическую боль. Также просто депрессия вызывает боль. Проводили даже исследование, что люди при стрессе съев обычное болеутоляющее получали облегчение (и естественно строго не советовалось таким развлекаться так как для здоровья это не в радость).
Резюмируя — решение задачи, которая для тебя имеет большую степень неопределенности, т.е. ты не знаешь как её решать — вызывает боль. И чем более ты не знаешь — тем больнее это чувствуется. Т.е. если суровому технарю дать задачу написать симфонию для скрипки — он испытает не меньшую боль, чем если композитору дать рассчитать сопромат конструкции моста.
Вполне :) В двух словах: я пытался донести мысль, что при правильном применении, выигрыш в производительности софта при использовании С++ и Qt совсем не мифический.
Я просто обычно использую Qt для связи с интерфейсом и т.п., а если в процессе появляется например необходимость обсчитать какую-нибудь рабочую область какого-нибудь невероятного устройства или проложить какой-нибудь хитро-выделанный маршрут на невероятных размеров карте, то создаем обычный класс и, никуда не переключаясь, в C-style пишем все быстро и оптимально. Идеологически это конечно не совсем тру, но «какого черта, мне надо чтобы программа в этом месте выжала максимум из компьютера!» :)
На той же яве реализовать такой подход было бы ИМХО труднее.
P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
В приведенном примере структура напоминает дерево. Если один виджет владеет остальными и может их удалить в деструкторе, то это ни разу не GC. Это как приводить в пример связный список и говорить что это GC.
Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
EeePC 901 (SSD, linux, + батарейка на 12к mAh), может здравствовать до 15-ти часов без подзарядки, отлично тянет QtCreator, сборка может немного подольше идет, но для поездок лучше не придумаешь. Сейчас пишу с него с воткнутой клавиатурой, мышью и многодюймовым монитором…
Жаль что их отменяют. По поводу минусов планшетов — у них-то и eth разъема нет, а + к этому 3 usb и выход в монитор, наверно вообще ни у кого нет. Eth например полезен для людей далеких от IT и далеких от центра по зарплатам — теперь к интернет проводу им надо ещё и роутер всем покупать, настраивать в обязательном порядке.
Синхронность / асинхронность зависит от выбранной модели обработки (см. статью). На Control Plane производительность в общем случае никого не волнует, важна 100%-я доставка, т.к. траффик маленький но важный, а вот на Data Plane там все синхронизации делаются через asm атомарные операции процессора, на которую тратится (если я не ошибаюсь) около 1 такта, и нет никаких блокирующих ожиданий — таких как взаимодействие с OS и т.п. — все они конвейером могут быть вынесены на отдельные коры процессора и работать асинхронно разбирая очереди.
К сожалению, я внезапно для себя обнаружил что в открытом доступе про DPDK и их реализации/парадигмы информации нет, так что больше ничего не скажу, чтобы не сболтнуть лишнего..( Скажу лишь что они там действительно ускоряют все что ускоряется.
Имею ввиду обычные переменные аля int, а не всякие мьютексы, у которых скорее всего все это предусмотрено. Если кто-то точно знает что я не прав, то буду рад услышать комментарии на эту тему.
Так если приложение выполняет два своих потока на двух разных физических процессорах, они разве будут синхронизировать свои кеши? Мне внутреннее чувство подсказывает что нет.
Volatile в c/c++ говорит компилятору, не доверять значению переменной которое хранится в регистрах процессора, а все время лазить за ним в память, в надежде что его там кто-то поменяет. В многопроцессорных системах, на сколько я помню, для «хитрых флагов» стоит его выставлять.
В Intel DPDK (Data plane development kit) тема ring buffer'ов с возможностью многих читателей и писателей раскрыта очень хорошо (а также пулов данных, процессорных кэшей и максимального увеличения производительности приложений-обработчиков сетевого трафика). Там работает все максимально изолированно от OS, даже мьютексы считаются долгой операцией, и синхронизировано все через хардварные локеры… платформо-зависимо правда, но работает очень эффективно.
Занимательная статья на тему подходов к fast-path processing с точки зрения Intel (да и не только): download.intel.com/design/intarch/papers/321058.pdf
P.S. Правда это уже ближе к embedded и обработке в реальном времени, с попыткой подвинуть TI процессоры.
— Взглянуть на код и логику свежим взглядом (как своим, так и чужими)
— Когда сам расскажешь другим людям про свой код (особенно про алгоритмически или логически сложные места) — сам можешь понять в чем могут быть проблемы
— Познакомиться с кодом и логикой, которая происходит в параллельном компоненте/классе
— Научиться у гуру и научить недогуру
— Получить фидбек на свою работу у коллег
— Синхронизировать понятия хорошего кода с коллегами (ведь хорошо когда код в проекте хороший не только ИМХО)
— Найти баги
— Найти забытые грязные хаки
— Найти забытые закоментированые участки кода и прочий мертвый код
У нас на ревью (чаще, правда, не кода) порой была практика аля «до конца недели каждый должен найти по 5 уникальных проблем и описать их в трекере» — мотивирует почитать не для галочки. :)
Я однажды удалил логи из папки таким образом (случайно пробел нажал при наборе команды): rm -rf logs /*
Хорошо вовремя сообразил что ругань нездоровая началась.
Т.е. если много вкладывать денег в продвижение какого-либо исполнителя на радио, то независимо от его популярности, теоретически, в какой-то момент этот исполнитель может стать прибыльным за счет налога (если логика меня в выходные не подводит)… интересно…
Так, на сколько я знаю, почти везде где не используется коммутация каналов, даже в gprs :)
Пока писал — придумал потенциальную проблему и ответ на свой вопрос: вероятно таймер активации программы был немного длиннее чем таймер отбора у абонента PDP контекста, и получалось «только отобрали IP по таймауту и отключили от пакетной передачи, как он редиска снова лезет в сеть и PDP активирует». Видимо увеличение таймаута (статическое или адаптивное, что было бы правильнее) их спасло.
Резюмируя — решение задачи, которая для тебя имеет большую степень неопределенности, т.е. ты не знаешь как её решать — вызывает боль. И чем более ты не знаешь — тем больнее это чувствуется. Т.е. если суровому технарю дать задачу написать симфонию для скрипки — он испытает не меньшую боль, чем если композитору дать рассчитать сопромат конструкции моста.
На той же яве реализовать такой подход было бы ИМХО труднее.
P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
Жаль что их отменяют. По поводу минусов планшетов — у них-то и eth разъема нет, а + к этому 3 usb и выход в монитор, наверно вообще ни у кого нет. Eth например полезен для людей далеких от IT и далеких от центра по зарплатам — теперь к интернет проводу им надо ещё и роутер всем покупать, настраивать в обязательном порядке.
К сожалению, я внезапно для себя обнаружил что в открытом доступе про DPDK и их реализации/парадигмы информации нет, так что больше ничего не скажу, чтобы не сболтнуть лишнего..( Скажу лишь что они там действительно ускоряют все что ускоряется.
Занимательная статья на тему подходов к fast-path processing с точки зрения Intel (да и не только): download.intel.com/design/intarch/papers/321058.pdf
P.S. Правда это уже ближе к embedded и обработке в реальном времени, с попыткой подвинуть TI процессоры.
— Когда сам расскажешь другим людям про свой код (особенно про алгоритмически или логически сложные места) — сам можешь понять в чем могут быть проблемы
— Познакомиться с кодом и логикой, которая происходит в параллельном компоненте/классе
— Научиться у гуру и научить недогуру
— Получить фидбек на свою работу у коллег
— Синхронизировать понятия хорошего кода с коллегами (ведь хорошо когда код в проекте хороший не только ИМХО)
— Найти баги
— Найти забытые грязные хаки
— Найти забытые закоментированые участки кода и прочий мертвый код
У нас на ревью (чаще, правда, не кода) порой была практика аля «до конца недели каждый должен найти по 5 уникальных проблем и описать их в трекере» — мотивирует почитать не для галочки. :)
Хорошо вовремя сообразил что ругань нездоровая началась.
Пока писал — придумал потенциальную проблему и ответ на свой вопрос: вероятно таймер активации программы был немного длиннее чем таймер отбора у абонента PDP контекста, и получалось «только отобрали IP по таймауту и отключили от пакетной передачи, как он редиска снова лезет в сеть и PDP активирует». Видимо увеличение таймаута (статическое или адаптивное, что было бы правильнее) их спасло.