А вариант «у нас был плохой код на С++/Qt» не рассматривали?

P.S. У нас на арме 750 Мгц из четырех портов на 57600 программа все отлично читает, успевает обработать данные и выплюнуть на экран. Помимо чтения данных есть еще куча сложных мат.расчетов. Все летает.

Да, рассматривал. Но дело в том, что там самого кода, который «делает дело» — раз и обчелся. Теже 50 строк, тот же смысл. Критично ошибиться там нереально.Но даже если предположить «криворукость» в этих 50 строках, но не на разницу же в 90%.

Вот и не знаю, на что грешить: плюсы с их классами, кривость КуТэ в целом или на саму либу

Сразу видно профессиональный подход к разработке.

Вы используете в проекте плюсы как таковые или также Qt? И производите работу с серийником средствами Qt? Если да, то какой библиотекой пользуетесь?

Без профилирования разговор бесполезен.

в 50 строках можно сделать более ста логических и синтаксических ошибок. Так что нечего на зеркало пенять коль рожа крива.

Я не говорю о синтаксических ошибках. Да и код не совсем кривой. Хотя признаюсь, что без прямых сравнений кода, конечно, сложно определить что и к чему. Но просто эти 90% прироста порадовали очень.

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

Что говорит профайлер?

уже сказали - профайлер в руки и смотреть, 99.99% за то, что ты сам напортачил в коде

Да, я тоже более склонен грешить на саму библиотеку. Но других, увы, нет. Залез я ради интереса во внутренности этой библиотечки, увидел что там практически «теже Фаберже, только в профиль» (select'ы и прочие) и особо далее не углублялся.

Признаюсь, что профайлером пока не прогонял (какой, кстати, лучше использовать, gprof?).

у нас для

uname -a
Linux 192.168.1.56 2.6.27.8 #107 PREEMPT Thu Aug 9 10:15:08 YEKT 2012 armv5tejl unknown

# cat /proc/meminfo
MemTotal:        61676 kB
MemFree:         56544 kB

cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 4 (v5l)
BogoMIPS        : 107.52
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 4
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 4
I line length   : 32
I sets          : 256
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : Phytec 3250 board with the LPC3250 Microcontroller
Revision        : 0000
Serial          : 0000000000000000

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

В проекте используется C++/Qt. Порты читаем напрямую.
Если Inbiza Labs сделали кривую библиотеку, то не надо по этому поводу гнать на ++ и Qt.

Чего? 10%? С каким лихом? У меня из сериал порта передается на скриптинг луа, и то, 1-3% на атоме кушает. Делай на pure C через epoll.
Вот тебе пример как у меня сделано: https://github.com/nekromant/usniffer

Да, видать скорее всего затык в самой библиотечке. А «напрямую» это как? через QIODevice?

«Почему ядро Linux не перепишут под плюсы?».

Чтобы те, кто задает эти вопросы не прикасались к разработке ядра.

Кстати, да. Слыхал об epoll, но подзабыл. Таки попробую и этот метод. Благодарю.

Через open/read.

QIODevice кстати, не особо тормозной, так что можно и его.

Этому коду уже 3 года, если не больше. Работает хорошо, так что шансов на рефакторинг у него практически нет.

Ты про что?

Я про наш read/open.

Не, я просто скорее ТСу, что если ему проще заюзать QIODevice, то он не проиграет по сравнению с чистыми read/open.

Вот и не знаю, на что грешить: плюсы с их классами, кривость КуТэ в целом или на саму либу (хотя она вроде как офф, будет в кутэ 5 «изкоробки).

На кривые руки не пробовал грешить?

„Почему ядро Linux не перепишут под плюсы“.

что бы было?!

Вот и не знаю, на что грешить: плюсы с их классами, кривость КуТэ в целом или на саму либу

это наивно так полагать что раз ты не смог осилить и грамотно прочитать документацию, отладить проблему в ТВОЕМ коде, то значит Qt и C++ не годны

выводы делай

Не понравилось мне все это, и переписал под pure C

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

И, кстати, если скомпилить с помощью с++ вашу С-шную прогу, тоже летает? А если вернуть весь C++ - specific код, но использовать С-шную библиотеку QT? может дело в QT библиотеке, может в C++ компиляторе, может в специфических конструкциях C++.

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

попробуй тот же oprofile или valgrind, сразу поймешь в чем проблема, или gperftools, да даже gprof если у тебя один поток в программе

неужели это так сложно применить профилировщик? я думал раньше что это трудно, но оказалось просто, особенно valgrind

так что смело читай что такое профилировка и найдешь причины в своем коде на счет раз

Плюсую валгринд.
Тем более, что из последних QtCreator работать с ним - одно удовольствие.

QIODevice кстати, не особо тормозной, так что можно и его.

QIODevice - абстрактный интерфейс. Как вы собираетесь его юзать? :}

okay, QFile.

профайлер? не, не слышал.

форматирование какое-то не очень.

Согласен, выглядит как говно:

if (ev->events & EPOLLIN)
  { // отступ 2, новый блок на новой строке
   if (us->tag != prev_tag) { // if - отступ 1, новый блок на текущей строке
   printf("[%d bytes]\n", count); // отступ 0
   count=0;
   frametimer_update();
   printf("[%f\t] %s:\t",frametimer_since(0), us->tag); 
   prev_tag=us->tag;
   } 
   while (count!=-1)
     { // отступ 2, новый блок на новой строке
       count = read(us->fd, buf, 8);
       for (i=0;i<count;i++){ // нет пробела, новый блок на текущей строке
	printf(" 0x%hhx",buf[i]); // табы вместо пробелов
	bytes++;
       }
       fflush(stdout);
     }

Почему ядро Linux не перепишут под плюсы

Linus

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Это писалось под задачу за 30 минут c использованием gedit вместо редактора на чужой машине, что ты хочешь? Будет время - поправлю кодинг стайл. А пока работает - и хрен бы с ним.

Если зело раздражает, натрави astyle или сделай C-x h C-\

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

Хорошо анон, форкни добавь блэкджек, шлюх и форматирование. Разрешаю. И не забудь скопировать текст GPL в файл COPYING. Мне было лень.

ну ты даешь. у нас на http://www.friendlyarm.net/products/mini2440 кьюты с компортом не тупили

Зато получил ответ на вопрос, который иногда меня мучал (и будил по ночам): «Почему ядро Linux не перепишут под плюсы».

Лучше поздно, чем никогда.©

Так лучше юзай написанную нашим соотвечественником либу, она вошла в аддоны к Qt5

А ссылку на либу не дадите?

1. Что за либа?
2. Зачем она мне, если у меня свое решение, протестированное вдоль и поперек, работает на ура.

Может проще выложить свои 50 строк кода?

Что-то у меня на говенном атоме qextserialport на 115200 спокойно туда-сюда данные гоняет и проц не грузит, наверное, у меня неправильные Qt и g++....

что бы было?!

403 Forbidden

УМВР

А ссылку на либу не дадите?

http://qt-project.org/wiki/QtSerialPort_Russian

Хотя еще имеются небольшие проблемы. В Виндах на некоторых USB/Serial контроллерах проявляется высокая загрузка на процессор.

Баг тут https://bugreports.qt-project.org/browse/QTPLAYGROUND-2

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

Предварительно ознакомится и протестить примерный будущий вариант можно отсюда:

https://codereview.qt-project.org/#change,32186

В принципе, это уже дало результаты:

http://qt-project.org/forums/viewthread/18580/P15

Так что, кому не безразлично наличие поддержки последовательных портов - милости просим к сотрудничеству жителей Л.О.Р а. :)