Разработчики проекта Enlightenment провели (https://phab.enlightenment.org/phame/live/1/post/simple_efl_.../) разбор результатов недавно опубликованного (http://www.opennet.me/opennews/art.shtml?num=36446) сравнения эффективности кода, созданного при использовании библиотек Qt Quick и EFL (Enlightenment Foundation Library).
С позиции удобства разработки, отмечается, что использующие язык Си библиотеки EFL в первую очередь рассчитана на использование для встраиваемых систем, ограниченных по доступным ресурсам. QML оперирует языком JavaScript и изначально рассчитан на упрощение и ускорение процесса разработки (RAD). EFL в текущем виде, основан на концепции разделения логики и внешнего оформления, но из-за использования языка Си не нацелен на быструю разработку приложений и требует для реализации RAD дополнительной прослойки, которая пока не готова но запланирована к реализации. Поэтому с точки зрения разработки QML по своей сути в более выигрышном положении, по сравнению с EFL.
Что качается потребления ресурсов, то данные разработчиков Enlightenment указывают на то, что на 32-разрядных системах программа на EFL требует для своей работы как минимум на 30% меньше ОЗУ и запускается в три раза быстрее, чем программа на QML. Что касается 64-разрядных платформ, то слабые показатели EFL обусловлены наличием некоторых недоработок, требующих оптимизации. К новому релизу EFL указанные проблемы будут устранены.
URL: https://phab.enlightenment.org/phame/live/1/post/simple_efl_.../
Новость: http://www.opennet.me/opennews/art.shtml?num=36652
> Что качается потребления ресурсов, то данные разработчиков Enlightenment указывают на то, что на 32-разрядных системах программа на EFL требует для своей работы как минимум на 30% меньше ОЗУ и запускается в три раза быстрее, чем программа на QML. Что касается 64-разрядных платформ, то слабые показатели EFL обусловлены наличием некоторых недоработок, требующих оптимизации. К новому релизу EFL указанные проблемы будут устранены."Во-первых, кувшин я не брала, во-вторых, уже вернула, в-третьих, он и так был с трещиной"
Разработчики эталонной ненужности сравнивают значит... Как чудесен этот мир:)))
Ждем Unity Next на QT / QML!!!
> Ждем Unity Next на QT / QML!!!Вот это - эталонная ненужность. А EFL - так себе, нужноватенько :)
> Вот это - эталонная ненужность...Даже наоборот, очень хорошая и нужная вещь, Unity на QT - это давно так и напрашивалось само по себе. Но...
> Ждем Unity Next на QT / QML!!!Это конечно не к месту в данной теме
> Даже наоборот, очень хорошая и нужная вещь, Unity на QTНет.
> Даже наоборот, очень хорошая и нужная вещь, Unity на QT - это давно так и напрашивалось само по себе.А нафиг оно надо, если оно будет гвоздями приколочено к дисплейному серверу от каноникал и системе инициализации от каноникал?
>> Даже наоборот, очень хорошая и нужная вещь, Unity на QT - это давно так и напрашивалось само по себе.
> А нафиг оно надо, если оно будет гвоздями приколочено к дисплейному серверу
> от каноникал и системе инициализации от каноникал?Кто вам такое сказал? Я не разбирался в том на сколько это дело привязано, но покажите если это так(прошу не надо в пример приводить какие то прошлые наработки Canonical, хочу узнать конкретно про UnityNext)
> Разработчики эталонной ненужности сравнивают значит... Как чудесен этот мир:)))
> Ждем Unity Next на QT / QML!!!Это убунтухейтер вбрасывает. Слишком очевидно.
> Это убунтухейтер вбрасывает. Слишком очевидно.Одни убунтохейтеры, понимаешь, вбрасывают, другие, значить, этот самый Unity на Qt переписывают!
А третьи - приколачивают все это к Mir и Upstart.
> А третьи - приколачивают все это к Mir и Upstart.Оно не взлетит - я порылся в "исторических справках": попыток заменить Х на аналог Wayland'а было не две (SVGAlib, DirectFB), а значительно больше - MicroXWin, Y Window System, Wayland, DirectFB, Xynth Window System, Fresco, KDrive (Tiny X), SVGAlib, Nano-X, PicoGUI.
Все пролетели, т.к. не обеспечивали должной гибкости, хотя были раза в 2-3 быстрее Х.
Вы просто забываете, сколько Шатлворт перед этим грозился всякой хрени сделать, но так и забил )))Ничего страшного не произойдёт - в очередной раз молча сольются грандиозные планы )
у них просто бомбануло
Но вот это
> отмечается, что использующие язык Си библиотеки EFL в первую очередь рассчитаны на использование для встраиваемых систем, ограниченных по доступным ресурсампо сути вполне себе верно.
QML - это классический "херак-херак и в продакшен", как PHP, только для десктопа, а не веба. С эмбеддовкой такой подход не катит.
А что их ткнули носом в косяки - так то даже им на пользу.
> по сути вполне себе верно.Да, только про Закон Мура забыли.
> QML - это классический "херак-херак и в продакшен", как PHP, только для
> десктопа, а не веба. С эмбеддовкой такой подход не катит.:-) Ну да, ну да.
>Да, только про Закон Мура забыли.Только вот после выхода восьмёрочки пользователи уже начинают понимать, что отапливание помещений посредством отрисовки интерфейсов довольно бредовая идея.
Так это и не идея, а лишь неожиданная фича.
> Только вот после выхода восьмёрочки пользователи уже начинают понимать, что отапливание
> помещений посредством отрисовки интерфейсов довольно бредовая идея.Я бы сказал, что просто мода на фефекты ушла. Интерфейс той же MacOSX изначально жрал очень мало ресурсов: iMac типа торшер - жуткая дрянь по железу, по ощущениям не дотягивающая до PIII-500. Т.е. сильно хуже современных планшетов.
А так, да, красивый интерфейс можно сделать на практически любом железе - см. NeXTSTEP или OpenLook, разработанные до 1990го года. Или избранные темы E16 (середина 90-х). Нужно просто чтобы это делали разумные люди с хорошим художественным вкусом.
Вот тут ты прав на 100%. WindowMaker красив, как Бог, черт возьми!!!
> Да, только про Закон Мура забыли.Он уже не актуален.
> Он уже не актуален.Ирония заключается в том, что Закон Мура по части производительности не актуален на десктопах/мощных ноутах, где мощности ЦП хватает на всё с избытком. А на планшетах, где ЦП слаб, закон Мура вполне себе работает.
Впрочем, даже на десктопах скорость ЦП растёт в однопотоке примерно по 10% ежегодно. То есть, нет ни малейшего смысла делать 30%-ную оптимизацию, если время разработки программы превышает 2 года.
(поэтому, кстати, Шаттлвортовский Mir не заменит Х. :-)
>Ирония заключается в том, что Закон Мура по части производительности не актуален на десктопах/мощных ноутахА правда заключается в том, что Закон Мура вообще не говорит ничего о производительности.
> А правда заключается в том, что Закон Мура вообще не говорит ничего
> о производительности.Если вы посмотрите на предыдущее сообщение, на контекст, то поймёте, что имелась ввиду "жаргонная трактовка" - экспоненциальное увеличение производительности железа, а не экспоненциальное увеличение кол-ва транзисторов, которое, кстати, до сих пор работает везде.
> Если вы посмотрите на предыдущее сообщение, на контекст, то поймёте, что имелась
> ввиду "жаргонная трактовка" - экспоненциальное увеличение производительности железа,
> а не экспоненциальное увеличение кол-ва транзисторов, которое, кстати, до сих пор
> работает везде.Работает оно нынче за счет экстенсивного прироста (увеличение схемы, вместо повышения плотности), т.к. плотность упирается уже в туннельный эффект.
Поэтому соответствующий рост производительности возможен только при асинхронной многопоточной архитектуре приложений.
> Работает оно нынче за счет экстенсивного прироста (увеличение схемы, вместо повышения плотности),
> т.к. плотность упирается уже в туннельный эффект.Здесь я пропустил: а экстенсивное развитие выливается в основном в увеличение количества потоков и ядер.
> Поэтому соответствующий рост производительности возможен только при асинхронной многопоточной
> архитектуре приложений.
> Работает оно нынче за счет экстенсивного прироста (увеличение схемы, вместо повышения плотности),
> т.к. плотность упирается уже в туннельный эффект.В контексте, это не важно, на каком принципе оно работает - товарищ хотел чОткости, товарищ, надеюсь, её получил.
>Работает оно нынче за счет экстенсивного прироста (увеличение схемы, вместо повышения плотности)Вот жеж как, значит вышедший в прошлом году IvyBridge на 22нм с 3D-транзисторами был обманом ЗОГа. Как страшно жить
> на десктопах/мощных ноутах, где мощности ЦП хватает на всё с избыткомЗависит от задачи. В общем случае, ваше утверждение ложно.
> А на планшетах, где ЦП слаб, закон Мура вполне себе работает.
Закон Мура касается только плотности размещения элементов на схеме. (Впрочем, некоторые блондинки считают, что это абсолютно то же самое, что и производительность. Но мы же с вами взрослые люди?)
> Впрочем, даже на десктопах скорость ЦП растёт в однопотоке примерно по 10% ежегодно.
В однопотоке? Растет? Не смешите мои тапочки. Современные десктопные и серверные системы в последние годы развиваются в основном в сторону увеличения числа ядер и потоков. По однопоточности ресурс развития практически выбран.
> Зависит от задачи. В общем случае, ваше утверждение ложно.Любители абсолютной строгости идут на север, вместе со слонами. Ибо только дурак не понимает, что каждая фраза имеет смысл лишь в контексте. А контекст - обсуждение интерфейсов.
> (Впрочем, некоторые
> блондинки считают, что это абсолютно то же самое, что и производительность.
> Но мы же с вами взрослые люди?)Мать, мать, мать. Под законом Мура, издавна, называлось несколько экспоненциальных закономерностей, работавших в 90-е: рост производительности, рост памяти и пропускной способности шин, рост числа транзисторов (в последнюю очередь, т.к. он интересует лишь разработчиков железа).
Это такой профессиональный жаргон. См. статьи того же С.Д. Кузнецова "Рабы закона Мура" - это один из ведущих сотрудников ИСП РАН.
> В однопотоке? Растет?
Смотрите тесты ixbt, растёт. Просто 10% - это очень мало.
> По однопоточности ресурс развития практически выбран.
Поэтому не полтора раза ежегодно, с обнулением топа каждые 3 года, а лишь жалкие 10%.
> Любители абсолютной строгости идут на север, вместе со слонами. Ибо только дурак
> не понимает, что каждая фраза имеет смысл лишь в контексте. А
> контекст - обсуждение интерфейсов.Даже под Linux несложно найти интерфейсы, которые капитально грузят проц (не будем тыкать пальцем), отнимая ресурсы у полезных задач.
А все потому, что их авторы не "экономили на спичках"™> Это такой профессиональный жаргон.
s/профессиональный/блондиночий
> Смотрите тесты ixbt, растёт. Просто 10% - это очень мало.
Всякие форониксы - не аргумент. Он все что угодно намерить могут.
> Даже под Linux несложно найти интерфейсы, которые капитально грузят проц (не будем
> тыкать пальцем)Поделись, ткни, если в себя не боишься попасть, ггг
>> Зависит от задачи. В общем случае, ваше утверждение ложно.
> Любители абсолютной строгости идут на север, вместе со слонами. Ибо только дурак
> не понимает, что каждая фраза имеет смысл лишь в контексте. А
> контекст - обсуждение интерфейсов.В вашем утверждении четко и однозначно сказано: "хватает на _все_ с избытком". Т.е. на все возможные задачи.
Но даже если бы вы не сделали этого уточнения, сути бы это не изменило - криво написанный интерфейс (авторы которого не экономили на спичках) потребляет _общие_ системные ресурсы, отнимая их у других задач. А значит, потребление ресурсов интерфейсом нельзя рассматривать отдельно.
> В вашем утверждении четко и однозначно сказано: "хватает на _все_ с избытком".
> Т.е. на все возможные задачи.Я же для Вас и других любителей "чОткой логики" уже написал - "со слонами на север".
>Что качается потребления ресурсов, то данные разработчиков Enlightenment указывают на то, что на никому не нужных устаревших 32-разрядных системах программа на EFL требует для своей работы как минимум на 30% меньше ОЗУ, что, вероятно, понадобится бедным детям Индии и Гаити, которым не надо будет неделю экономить на питании, чтобы докупить пару планок памяти; и запускается в три раза быстрее, чем программа на QML, - не секунду,- а одну треть секунды!Поправил новость для затравки
Ждем рисового ткджика, без него срача не будет.
>>Что качается потребления ресурсов, то данные разработчиков Enlightenment указывают на то, что на никому не нужных устаревших 32-разрядных системах программа на EFL требует для своей работы как минимум на 30% меньше ОЗУ, что, вероятно, понадобится бедным детям Индии и Гаити, которым не надо будет неделю экономить на питании, чтобы докупить пару планок памяти; и запускается в три раза быстрее, чем программа на QML, - не секунду,- а одну треть секунды!
> Поправил новость для затравки
> Ждем рисового ткджика, без него срача не будет.Культура программирования? Не, не слышал. Ты это хотел сказать?
Ну и что, что запускаться будет не секунда, а аж 0.33333333333333333333333 секунды? Суть то не в этом, а в том, что в EFL культура программирования и вцелом код намного красивее, чем в QML.
> Суть то не в этом, а в том, что в EFL
> культура программирования и вцелом код намного красивее, чем в QML.И то, и другое - жуткое старьё.
Qtшный JavaScript - это язык с динамической типизацией, хотя уже 30 лет, как умеют делать языки со статической типизацией и теми же удобствами (ML/Haskell). EFL - Cшная библиотека - т.е. библиотека, имеющая интерфейсы на портируемом макроассемблере, т.е. глубоко системной штуке.
Всё хорошо но причем здесь qml, qtscript и типизация?
> портируемом макроассемблере, т.е. глубоко системной штуке.И это фича, а не баг: именно поэтому она привинчивается куда попало. К любому ЯП. В отличие от всякого концептуального булшита, с ножом к горлу сватающим один конкретный ЯП.
>>Что качается потребления ресурсов, то данные разработчиков Enlightenment указывают на то, что на никому не нужных устаревших 32-разрядных системахДа ну? А тут вот в соседнем обсуждении (новость про PCLinuxOS) доказывают, что x86_64 - это ненужная новомодная свистоперделка, и только здоровый консерватизм с i586 спасет мир.
А если я начну утверждать, что 16битные проги и процы это Ъ, а 32бита - это для метросексуалов, для вас это тоже станет аргументом, а может и истиной?
> А если я начну утверждать, что 16битные проги и процы это Ъ,
> а 32бита - это для метросексуалов, для вас это тоже станет
> аргументом, а может и истиной?На опеннете - вполне себе за аргумент покатит.
Ведь тут еще встречаются люди, которые верят в то, что x86 уже устарела. А значит, поверят в любую фигню.
> которые верят в то, что x86 уже устарела.В это не надо верить. Это видно невооруженным глазом. Соотношение потребления к производительности у х86 сакс.
Почему-то в мобильных устройствах где потребление критично - обосновались ARM и подобные. А в суперкомпьютерах - победное шествие начали GPU. Что за фигня? :)
> К новому релизу EFL указанные проблемы будут устранены.Лет так через 10)
Где-то было (может здесь), что для qt процент озу используемой разделяемыми библиотеками, значительно больше такового для efl. Так что при запуске нескольких программ qt потребляет меньше озу.
> Где-то было (может здесь), что для qt процент озу используемой разделяемыми библиотеками,
> значительно больше такового для efl. Так что при запуске нескольких программ
> qt потребляет меньше озу.Планка 2Гб ОЗУ стоит 20-30 баксов, меньше, чем хороший обед в ресторане.
Вообще-то в сабже сравнивается использование памяти.
> Вообще-то в сабже сравнивается использование памяти.Дык, фигня это всё, экономия на спичках.
>> Вообще-то в сабже сравнивается использование памяти.
> Дык, фигня это всё, экономия на спичках.Когда количество спичек подваливает к тонне в месяц - имеет смысл задуматься об экономии.
> Дык, фигня это всё, экономия на спичках.Да, конечно, каждому автору кажется что его программа лучшая на свете и уж пару гиг ей можно подкинуть. Вот только довольно позорно когда гражданин вопящий про "однозадачные" системы насчет вяленда, вдруг начинает страдать избирательным склерозом в другой ветке. Надо же - когда надо про многозадачность можно и забыть? :)
>> Вообще-то в сабже сравнивается использование памяти.
> Дык, фигня это всё, экономия на спичках.«Спичка, ломающая спину верблюду» — это когда слоты под планки памяти заканчиваются, а система глубоко в свопе. Спасибо, но не надо — достало уже.
> «Спичка, ломающая спину верблюду» — это когда слоты под планки памяти заканчиваются,
> а система глубоко в свопе. Спасибо, но не надо — достало
> уже.так у рассуждающих по типу «а, если что — добавить памяти, да и все дела» ОС используется в режиме однозадачности. максимум — двухзадачности. они не могут представить, зачем больше надо. поэтому и рассуждают на уровне одной программы. с такой точки зрения — действительно: ну, будет любимая программа жрать больше памяти. ерунда. всё равно она практически монопольно ресурсами владеет.
Из-за разработчиков, которые так рассуждают, отдельная планка нужна каждой второй программе. Дырок в материнке ограниченное количество, между прочим.
> Планка 2Гб ОЗУ стоит 20-30 баксов, меньше, чем хороший обед в ресторане.Как бы это - индикатор подхода в целом. Если софт писали по быдлокодерски - то он быдлокодерский насквозь. Рапидчина означает что положили на все что можно было положить. Т.е. быстро набросали код - и скорей-быстрей в катало-апстор. Что из этого получается - можете посмотреть на примере андроида. И как вам софтец в андроиде, ась?
> Планка 2Гб ОЗУ стоит 20–30 баксов, меньше, чем хороший обед в ресторане.у тебя DOS, что ли? у нас, знаешь ли, многозадачные системы уже. 10 программ, каждая хочет по 2 гб неизвестно зачем — сколько получается? не запаришься дырки под планки сверлить, нет?
Милые други, отписавшиеся выше. Я вас очень люблю и прекрасно понимаю ваши аргументы.Я осознаю, что та же Qt крайне прожорлива до памяти. Но шутка заключается в том, что отличие EFL от Qt - жалкие 2 раза по памяти и унылые 30% по производительности. Единственное, что радует - это 3 раза по времени запуска.
Это, как подсказывает нам история, мелочи. Переход из количества в качество появляется, когда разница в потреблении памяти отличается хотя бы на порядок.
То есть, у меня на текущем компе 2.5 Гб памяти, чего хватает. Воткнуть 4Гб я могу не выходя из дому. Некоторым образом заплатив (временем и деньгами), я могу воткнуть 8Гб, но не более. Т.о., если потребление программ возрастёт в 4-е раза, я переживу, а вот в 10 раз - нет, придётся менять компьютер. Это качественная разница.
Теперь рассмотрим ситуацию с т.зрения "погроммиста". На Qt есть RAD, а на EFL - нет. Т.е. затраты на создание программы под Qt сильно ниже, чем под EFL. Т.о. выбор очевиден.
P.S.
Х, как известно, по производительности ВСЕГДА были ХУЖЕ конкурентов: MicroXWin, Y Window System, Wayland, DirectFB, Xynth Window System, Fresco(Berlin), KDrive (Tiny X), SVGAlib, Nano-X, PicoGUI. Примерно раза в 2-3. Но, в отличие от них Х качественно позволяли БОЛЬШЕ. И разница в производительности в 2 раза НЕ играла роли.
Поэтому победы Mir/Wayland над X можно не ждать. И работает тут ровно тот же механизм, что в противостоянии Qt и EFL.
> Теперь рассмотрим ситуацию с т.зрения "погроммиста". На Qt есть RAD, а на
> EFL - нет. Т.е. затраты на создание программы под Qt сильно
> ниже, чем под EFL. Т.о. выбор очевиден.да. при прочих равных лучше выбирать софт на EFL, а не формошлёпство.
> Планка 2Гб ОЗУ стоит 20-30 баксов, меньше, чем хороший обед в ресторане.Только в embedded-железку ее не засунешь, да и при многотысячных тиражах 20 баксов - это очень много.
>при запуске нескольких программ qt потребляет меньше озу.Не меньше, просто разница менее крупной становится.
> Не меньше, просто разница менее крупной становится.И не в обиду кутям, куть нынче стал жирный и довольно слоупочный.
Не трогайте EFL, хорошая штука, вот бы еще достойные биндинг для Lua
> биндинг для LuaВы как-то путаете причину и следствие. Lua обычно юзают как встраиваемый в софт интерпретер.
> Не трогайте EFL, хорошая штука, вот бы еще достойные биндинг для Luaу тебя есть шанс стать законодателем мод.
ты не первый, кому это в голову пришло ;)
правда ближайшие полгода ты навряд ли что-то нагуглишь, я уверен.
Потрясная новость: сравнили js+биндинги к си и qml+(либо jscore, либо v8)+биндинги к c++
Ваще говорить о сравнении жабаскрипта и сей в плане потребления ресурсов это из разряда вялотекущей той самой, что на букву "ша"
> не нацелен на быструю разработку приложенийТак это фича а не баг. Пользоваться рапидно налабаной наколенщиной, где индусы только и думали как побыстрее отъ...ся от написания "этого крапа" - удовольствие сильно ниже среднего.
В Ubuntu 15.04 Unity будет переписана на RAD Enlightment, так как QT станет слишком высококалорийным для космонавта...