Pull to refresh

Comments 42

Nokia 5800., только 4 потока.

Вариант 1 — завис, после перезапуска — 42346,
Вариант 2 — без фризов, 114798. После перезапуска результат отличался незначительно.
А кстати первый вариант с 4 потоками на 5800 после перезапуска без фризов или с фризами также?
Насколько мне помнится в Симбиане не рекомендуется злоупотреблять потоками в UI приложении. Для этого лучше использовать отдельный exe и взаимодействовать с ним через Client/server framework. Тогда фризов в приложении не будет, так как оно будет делать то что задумано — отображать данные, а не производить вычисления.
Вообще, имхо, симбиан разрабатывали наркоманы. Оперативка в файловой системе, клиент-серверная модель на устройстве с ограниченными ресурсами и производительностью, гуй — отдельная песня. Странный он, проще говоря.
Вы категорически не правы, все же Symbian единственная микроядерная мобильная RTOS. А то, что для вас выдумка наркомана, для разработчиков OS было единственным верным решением. Да в ней много вещей которые сначала отпугивают, потом же наоборот, осознаешь, что того же CleanupStack тебе не хватает на других платформах. Есть книга, в которой подробно расписано, что как и почему сделано в Symbian.
www.amazon.com/Symbian-OS-Architecture-Sourcebook-Evolution/dp/0470018461/ref=sr_1_20?ie=UTF8&s=books&qid=1266887982&sr=8-20
Главная проблема Symbian — сложность для разработчика на начальных этапах, это не Android, где HelloWorld пишется за 15 минут.
Возможно вы правы, я сталкивался только с нокиевской реализацией и их монструозным Carbide.UI.
Что S60 от Nokia, что UIQ — OS одна и та же, а Carbide — всего лишь инструмент для разработки, основанный на Eclipse.
Ось-та одна, но построение интерфейса на них совершенно разное.

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

С точки зрения разработчика же — очень высокий входной уровень (освоить симбиан сложней, чем тот же андроид, обджектив си для айфона или винмобайл), но сейчас появляются альтернативы в виде питона / QT-приложений, разработка которых приводит к куда меньшим затратам усилий и средств.
А вы пробовали предыдущие издания S60? Так в общем то было всегда и средств визуального проектирования долгое время не было. У S60 всегда было много косяков и проблемы с документацией, а альтернативный UI (UIQ) для Symbian попросту убили.
У Symbian есть шансы на успех, если только они полностью откажутся от наследия S60 и не будут париться о всяких backward compatibility. Только QT поверх Symbian, это мне кажется уже слишком. Так как может привести к путанице с обработкой ошибок/сигналов и прочего.
Немного тыка S60 3rd и UIQ версии тоже. Если третье издание в принципе не особо отличалось от обычных телефонов, как по юзабельности, так и по скорости работы, то пятое… :)

Чтобы послать 12 файлов по блютус одной пачкой (5800) нужно совершить… 64 клика. По 5 на каждый файл минимум. Не кажется, что это перебор?
Это плата за визуальную и программную( в некоторой степени) совместимость с предыдущей версий платформы. Нокия решила просто добавить touch в платформу, редизайна UI и юзабилити похоже не производили.
Программы с S60 v3 не идут на пятом издании. Верней, идут, но на так, в отличии от Java, совсем не откликаются.
Не все. Часть все таки идет. Достаточно большое число программ требует просто перекомпиляции. Ну а в остальные надо добавлять поддержку тача.
В плане юзабилити и user experience мне кажется между v5 и v3 достаточно много общего, потому и существуют косяки, вроде описанного вами.
А что плохого в Qt? С точки зрения разработчика она куда проще и удобнее, да и возможностей больше. А что насчет путаницы, то разве Symbian не posix совместимая?
В QT нет ничего плохого. Наоборот, данный framework очень хорош. Однако меня несколько беспокоит использование двух различных базовых идеологий. Скажем так, если использовать QT, то надо запретить программистам использовать API Symbian, иначе будет повсеместное использование костылей — приведение строк от платформенного типа к типу в QT, конвертация событий между системой и фреймворком итд.
Насколько мне известно, старый avkon будет выпилен напрочь
А почему просто не понизить приоритеты вычислительных потоков относительно потока UI?
Т.Е. Мы добиваемся повышения производительности через многопоточность, и тут же понижаем приоритет расчитывающих потоков?
1. Повышение производительности через многопоточность возможно только при наличии нескольких вычислительных ядер. Во всех остальных случаях мы добиваемся упрощения логики, уменьшения связности, группировки кода и т.п.

2. Приоритет — это штука, которая определяет, какой поток будет исполняться из множества готовых к выполнению потоков. Интерфейсный поток большую часть времени простаивает ожидая сообщений. Однако, коль скоро он получил сообщение, вы сами хотите чтобы выполнялся он, а не вычислители.

Поэкспериментируйте, чтоли.
Повышение производительности через многопоточность на одноядерном процессоре? Бугага))))
В один момент времени он может обрабатывать только один поток, итого таким образом можно повысить отзывчивость приложения, затолкав длительное действие в отдельный поток
кстати зря смеешься) наилучшее количество потоков n+1 если что (где n-количество ядер), по причине неполной загрузки одним потоком проца полностью (в случае одноядерного проца)
Про смену приоритетов забыл, да. Привык уже что под линем нет их. Вечером дополню статью вариантами с приоритетами.
>Привык уже что под линем нет их.

Мсье не в курсе про nice и не слышал про posix?
я про QThread если что
Используйте системный RThread, а не настройку QThread из Qt.
я так понимаю RThread это чисто симбиановская вещь? стояла цель именно полностью кроссового теста, без каких-либо дополнительных системных библиотек
Учите матчасть! (С)…

QThread это чисто cooperative multi-tasking, её предназначение — быстро выполнить какой нибудь асинхронный запрос (HTTP к примеру) и ВСЕ! Производить длительные или CPU интенсивные вычисления в таких нитях строго запрещено, и об этом четко сказано в документации.

RThread это системный вызов (аналог pthread) с pe-emptive multi-tasking. Такие нити как раз пердназначены для CPU-intensive вычислений.

В догонку. Даже pre-emptive multi-tasking (т.е. RThread и RProcess) в симбиане реализован крайне кривой, а системный шедюлер — полное говно! Любая нить может полностью повесить операционную систему, чего принципе быть не должно.
Дело не в матчасти (а в симбиане я полный профан, я не спорю). Я говорю про кроссовость.
Плюс (опять же не касаясь симбиана, а говоря про настольные оси) кутешная реализация потоков вполне на уровне. По крайне мере на винде (на x86) и на линуксе (x86 и SPARC) меня вполне устроила эта реализация (про SPARC правда могу сказать только за Qt3, я сравнивал это года 3 или 4 назад, когда например wxWidgets работала из рук вон плохо с потоками).
На PC и Sparc-ах вычислительная мощность столь велика (даже по сравнению с самыми современными ARM-ами), что подобные тесты влёгкую «проваливаются» незамеченными для остальных нитей/приложений. Вот вы попробуйте на PC вычислить в одной Q-нитке что нибудь посерьезнее, да подольше — эффект будет точно такой же.
ну я проверял на достаточно серьезных и долгих вычислениях) обработка изображения с камеры БПЛА в приближенном к риал-тайм режиме на Эльбрусах это не так-то и просто)
Некрокомментинг, канеш, но все ж: эльбурс, если мне память не изменяет — это vliw проц, на котором чем длинней «нитка» — тем лучше, не?
Я все к тому, что Symbian надо хоронить! Этот хаотичный набор классов и бесполезных абстракций называть операционной системой не поворачивается язык. И никакой Qt или иная надстройка сверху не только не помогает, а наоборот — усугубляет процесс разработки, так как приходится одновременно бороться с багами и фичами уже двух сложных сущностей, порой противоречивых. Как бы красив и лаконичен не был бы Qt, Symbian все равно все испортит! Это та самая ложка дёгтя, которая из бочки мёда делает бочку говна.
ну благо скоро появится Symbian^3, а за ней Symbian^4. Будем надеяться что там все будет гораздо лучше. В последней кстати, Qt будет основой UI.
Неа. Symbian^3 и прочее, это очередная поделка финских студентов (или даже переделка S60). От таких поделок надо избавляться на ранней стадии проектирования. Вообще, изобретение операционной системы давно сравнивается с изобретением вечного двигателя, т.е. является абсурдным и бесполезным занятием. Ничего нового в этой отрасли привнести уже давно не возможно, вся теория четко и ясно расписана в учебниках, а имплементировать теорию лучше чем это сделано в ядре Linux или BSD — тянет на нобелевку как минимум (если бы её еще давали за программизм). По этому, надо брать и адаптировать уже имеющиеся стабильные и отлаженные ОС, т.е. Linux. И в этом смысле у Nokia есть отличнеший проект — Maemo. Я был бы несказанно рад, если бы Nokia полность похоронила Symbian и начала бы выпускать девайсы только на Maemo. Технически это весьма просто, но политически — скорее всего нет.

Я считаю, что любая реинкарнация Symbian заведомо обречена на провал, по одной существенной причине — годами заслуженное сугубо негативное отношение к этой ОС среди разработчиков.
откуда такие знания про симбиан3? просто из-за отношения к с60 или что-то более значимое? может вы инсайдер в Нокии?
Я не инсайдер, я давно пишу софт под S60 и читаю форумы девелоперские. Ничего хорошего из ^3 не выйдет по очевидным причинам.
ну то есть я так понял дело именно в отношении к с60?
Нельзя так говорить, что Symbian объективно плох. Про минусы уже много сказали, но из плюсов я вижу энергосбережение (до которого Маемо, к сожалению, далеко), реалтаймовость, поддержка symmetric multi-processor.

ИМХО, лучшее, что можно сделать с Симбианом — оставить старые API но пометить их как deprecated (а кому хочется срочно переписывать всю работу с камерой, например, или сложное приложение на Active Objects?). И ввести новые API, основанные на Qt, GSreamer и STL. Компилятор чуть-чуть поновее взять :) (под эмулятор s60 v3 программа собирается компилятором, не знающим слова explicit)
Sign up to leave a comment.

Articles