Шай Альмог (Shai Almog), один из разработчиков виртуальной машины и JIT-движка для Java, опубликовал (http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-... развёрнутый ответ на недавнюю публикацию (http://www.opennet.me/opennews/art.shtml?num=37421) Дрю Кроуфорда о проблемах JavaScript, мешающих использованию данного языка для создания мобильных приложений. По мнению Шая причина низкой производительности web-приложений в основном связана с особенностью интерфейса DOM (http://ru.wikipedia.org/wiki/Document_Object_Model) (Document Object Model), а не самим языком. Кроме того, высказанные в статье претензии к сборщику мусора и JIT-компилятору, по мнению Шая, являются ошибочными. В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ.
URL: http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-...
Новость: http://www.opennet.me/opennews/art.shtml?num=37442
Будем делать интерфейсы на канвансе и ВебГЛ.
Ох, /me предчувствует, что слова анонима пророческие.
Под канвас и вебгл и для десктопов-то нет нормальных гуй-библиотек. Разве что квадратные кнопочки в блендере.
Если описывать полноценный DOM-аналог для канваса на js - он будет тормозит намного больше чем сам DOMЧто же до тормозов DOM'а. Так сравнивать-то его не с чем. Возможности разметки на HTML+CSS+js куда значительнее любого GUI на любом языке
>> Возможности разметки на HTML+CSS+js куда значительнее любого GUI на любом языкеЛяпнул так ляпнул...
У меня даже была шальная мысль попробовать нарисовать веб-приложение (даже не так, приложение в браузере) целиком на канве, но подумал о производительности и сразу охота отпала. Хотя вроде как Qt и GTK именно так и делают.
на Qt3 было достаточно много проблем с отрисовкой, очень многое из проблемного списка было улучшено в Qt4. Но, довольно часто были траблы, когда похабно сделанный signal-slot механизм в исходном коде программы списывался на кривость Qt. Такое видел очень часто.
Для канвы хотя бы в принципе есть шанс получить приличное быстродействие, выкинув все что можно в видеокарту, оставив браузеру самый минимум. А с монструозным DOM - ни шанса, так еще и приходится втискиваться в идиотскую браузерную потоковую модель.
Да, кстати, работа с DOM самое тормозное, пожалуй.
Возразить нечего, я так понимаю?
Фишка в том, что для ПРИЛОЖЕНИЯ 99% этих возможностей либо избыточны, либо вообще вредны. А ресурсы на них тратить всё равно приходится. А примитивная и довольно симпатичная кнопочка жила еще в DOS на каком-нибудь 286.
Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и больше ничего
Для веб-приложения - именно это и нужно.
> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и
> больше ничегоэто было бы просто великолепно. а то МегаДизайнеры задолбали.
>> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и
>> больше ничего
> это было бы просто великолепно. а то МегаДизайнеры задолбали.Linx в зубы. Что-то не слишком-то ты бежишь в голом текстике на мордокнижечке сидеть, а, арису?
> Linx в зубы. Что-то не слишком-то ты бежишь в голом текстике на
> мордокнижечке сидеть, а, арису?прикинь, я и в графичке туда не бегу. я понимаю, что ты жизни не представляешь без соцсетей, но я — к счастью — не ты.
> Представь себе что на всех сайтах есть только набор сереньких GUI-компонент и
> больше ничегоНу почему же обязательно серенькие? Можно и синие. :-)
Красивые кнопочки можно отрисовать с любыми ресурсами - это же задача художника. Скажем, многие художники вообще в бинарной палитре работали - гравюры делали. И великолепно получалось. :-)
Есть ряд вполне приятно отрисованных интерфейсов, сделанных в условиях жутких ресурсов - OpenLook, NEXTStep. Да даже MacOS в чёрно-белом варианте не так плоха.
> Можно и синиеЕретик!
>> Можно и синие
> Еретик!Трепло он, а не еретик.
На хабре народ в печали что флеш погубили, с его анимированными векторными мувиклипами..
А на опеннете предлагают довольствоваться стандартными визуальными компонентами..
Они там вообще красивости много больше любят, чем функциональность.
Так уже.
так криворукие программисты и на нём умудрятся сделать так, чтобы работало медленно. ибо у оных принцип: кое-как работает - не трогай. от этого все проблемы гурьбой потом внезапно появляются. здесь на 5% потери производительности забили, там - еще столько же. никто ж не знает, что такое профилировка, етить.
> В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ.там то GC скрее всего не было и мб даже самого JITа. Тормозить было особо нечему
>там то GC скрее всего не былоКак же? Ведь память надо как-то освобождать. Не в ручную же.
>мб даже самого JITамало какие телефоны умели jit.
> Как же? Ведь память надо как-то освобождать. Не в ручную же.там gc совсем простой, чуть ли не аналог сишного malloc()/free() или в лучшем случае питоновского GC со ссылками, который освобождает объект сразу как только можно. GC в яве тормозит именно из-за отложенного коллектора, сначала засирает что только можно, а потом наступает пц.
> там gc совсем простой, чуть ли не аналог сишного malloc()/free() или в лучшем случае
> питоновского GC со ссылками, который освобождает объект сразу как только можно. GC в яве
> тормозит именно из-за отложенного коллектора, сначала засирает что только можно, а потом
> наступает пц.Не такой и простой, по крайней мере на сонериках db2010 и выше.
Помню, как ручками вызывал System.gc() чтобы памяти чуть освободить когда она нужна.
Так что он, естественно, проще, чем на десктопе - но засирает что только можно ни капли не хуже.
> GC в яве тормозит именно из-за отложенного коллектора, сначала
> засирает что только можно, а потом наступает пц.Ну а кто, спрашивается, насоздаёт короткоживущих объектов на "каждый чих", а потом не знает как их повторно использовать и надеется на уборку мусора? Правильно — бывшие программеры C/C++, которым привычные malloc()/free() использовать тут не дали, а всучили убогий "ручник" сломанного "стопкрана" System.gc(). :)))
проверка твоих теоретических умозаключений: сделай парсер, или какой обработчик строк на жабе. будешь сильно удивлён. вот уж во истину, на каждый чих. даже, если соединяешь с константными строками.
просто пичалька, от "глубинных" знаний жабакодеров. и да, как обычно, в своём упорно не замечеют бревна. такая грусть.
> проверка твоих теоретических умозаключений: сделай парсер, или какой обработчик строк
> на жабе. будешь сильно удивлён. вот уж во истину, на каждый
> чих. даже, если соединяешь с константными строками.
> просто пичалька, от "глубинных" знаний жабакодеров. и да, как обычно, в своём
> упорно не замечеют бревна. такая грусть.Для простейшей операции конкатенации строк в Java (и J2ME) используется оптимизация на уровне компилятора — там, где это возможно и программист специально не извратился (а такое сплошь и рядом случается с обезьянками, которые лучше всех знают что и как), используется практически во всех случаях подстановка класса для работы со строками java.lang.StringBuffer. Это хорошо видно в декомпилируемом классе и в показаниях профилировщика.
Если вы не умеете пользоваться декомпилятором в Java и профилировщиком кода, то продолжайте дальше нести чушь про теоретические умозаключения и соринки в наших глазах.
ты это серьезно? декомпайлер для жабы, он такой ужасно сложный, прям аж жуть. как раз я и занимался разбором полётов подобных парсеров, логгеров, в том числе и видел, каким образом жабисты извращаются, дабы ускорить процесс обработки строк. так что можешь продолжать и дальше детский лепет на лужайке.
раскрою тебе даже большой секрет, до которого ты никак не можешь допиликать сам: именно из-за геморра с объектами из-за каждого выпука невозможно сделать адекватно работающий, не тормозящий браузер. это как пример.
Sun в свое время по этим же причинам не захотела конвертировать OpenOffice, а IBM свои большие проекты тестирует сначала на джаве, а потом уже конверитует их по своему усмотрению в фортран, плюсы и другие языки.
Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти?
> Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти?Потому что память в Java — не ресурс. Если его реально не хватает, то повышайте скилл Re-Usable Objects и/или докупайте модули памяти. Третьего не дано.
>> Какой смысл писать на жабе, если всё равно приходится изворачиваться кренделем ради памяти?
> Потому что память в Java — не ресурс. Если его реально не
> хватает, то повышайте скилл Re-Usable Objects и/или докупайте модули памяти. Третьего
> не дано.Ачо, сборщики мусора еще не изобрели? Или их вызов - песдетс ракетная наука?
ну чего ты пристал: изя же рукожоп. а у рукожопа «докупайте памяти, она копейки стоит» — любимый «аргумент».
>Третьего не дано.ой ли?! портировать программу из жабы на более подходящий для задачи язык программирования.
>>Третьего не дано.
> ой ли?! портировать программу из жабы на более подходящий для задачи язык программирования.Портируйте Spring Framework на что-то другое — поговорим.
Напишите NetBeans, Eclipse, IDEA на чём-то другом — обсудим.
Что, кишка тонка и рвётся от малейшего пука?
это да: таких тормозных удолбищ, как eclipse, например — ещё поискать. авторы Qt на это всё посмотрели — и сделали QtCreator.а если уж говорить про «кишки», изенька, то один emacs все ваши жабоподелки уделывает влёт.
если бы этим проектам не было бы адекватной альтернативы, их бы давно уже портировали. а для меня лично, так я не хочу, чтобы какой-то IDE откушивал под 2 гига памяти. не могу себе позволить, т.к. на работе в основном память под виртуалки уходит, для тестирования, а дома для моих проектов старенького лептопа хватает, на котором только 2 гига памяти. и ничего, для браузера, кедов и KDevelop хватает и в своп не лезет. прикинь?
У меня SWAP'а вообще нету и не жужжу. 8 ГБ, ZFS — полёт нормальный.
> и не жужжуединственное полезное дело, которое ты мог бы совершать, и то…
и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с двумя гигами своп вырубить и тоже начать гордиться?
> и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с
> двумя гигами своп вырубить и тоже начать гордиться?можешь не вырубать, а просто писать, что вырубил и гордиться. вон изя же сидит в винде, а бсдой ему это гордиться не мешает.
> и что? предмет гордости, или предлагаешь мне на моём домашнем лептопе с
> двумя гигами своп вырубить и тоже начать гордиться?Ни для кого не секрет, что SWAP придуман для того, чтобы "эмулировать" дополнительный объём оперативной памяти, когда приобрести модули ОЗУ выходит очень дорого или невозможно в принципе — конструктивно или ещё по каким-либо причинам. Плата за это — низкая скорость обмена данными с более медленными устройствами (HDD, SSD), чем микросхемы ОЗУ.
Гордится тем, что у тебя есть SWAP такого же объёма, что и оперативка (2 ГБ), незачем. Это констатирует лишь то, что задачам вполне хватает выделенного объёма оперативной памяти, а в какую-то часть времени приходится мириться с тормозами и замедлением ответной реакции системы. Ежели SWAP создан для того, что так советуют умудрённые опытом специалисты в учебниках 1990-х годов по организации виртуальной памяти, то гордиться "задним умом" забавно.
изька, зачем ты тут рассказываешь про своп? тебе больше рассказать нечего?
кто тебе сказал вообще, что я использую своп такого же объема, что оперативка? ты часто показываешь примитивность своего мышления. что наводит на мысли про "задний ум" относятся к тебе, а не ко мне.
> Правильно — бывшие программеры C/C++, которым привычные malloc()/free() использовать
> тут не дали, а всучили убогий "ручник" сломанного "стопкрана" System.gc(). :)))Вообще-то если что, emscripten для повышения производительности JS зарубает GC к черту. Знаешь как?
1) Он выделяет себе невь...й массив.
2) В него заворачиваются все malloc().
3) GC вообще в пролете - он это не сколлектит вплоть до самого конца работы программы.И вот только так emscripten умудряется нормальную скорость работы получить. Послав GC нафиг. Совсем.
> Ну а кто, спрашивается, насоздаёт короткоживущих объектов на «каждый чих», а потом
> не знает как их повторно использовать и надеется на уборку мусора?так кто же виноват, что в жабе сборщик настолько хреновый?
(хотя, конечно, он там не один, и не хреновые они, просто пишут на жабе вот такие вот изи — и получается говно).
>> Ну а кто, спрашивается, насоздаёт короткоживущих объектов на «каждый чих», а потом
>> не знает как их повторно использовать и надеется на уборку мусора?
> так кто же виноват, что в жабе сборщик настолько хреновый?
> (хотя, конечно, он там не один, и не хреновые они, просто пишут
> на жабе вот такие вот изи — и получается г о в н о).Х р е н о в ы й не сборщик. Х р е н о в ы е рукосуи, которые пишут программы. Каждый дятел....
Приведу один пример. Я несколько лет назад видел прикладу, разработанную на BPEL - слыхал? - которая за 7 минут работы после рестарта сервера на линухе умудрялась скушать 14 (!) Гб оперативы и сдохнуть. Почему? Потому что программер (в данном контексте слово означает сексуальную ориентацию) Костя Шакалов не знал, что надо вызывать сборщик мусора (один из трех, имеющихся в наличии, кстати говоря) и не посчитал это необходимым - при таком изобилии свежести^Wпамяти всего в двух калориях^Wтирах системы. Ачо, плашка памяти ж как лопата дерьма стоит, фуле! Память - не ресурс!
> Шакалов не знал, что надо вызывать сборщик мусора (один из трех,
> имеющихся в наличии, кстати говоря)А еще говорят что на си программировать сложно, память выделять/освобождать, блаблабла. А у самих вон сколько гемора. И память совсем не утекает :)
если сборщик мусора надо явно вызывать — это не язык, а дерьмо. впрочем, практика показывает, что если в названии чего-то софтового есть «bussines» — то это дерьмо с вероятностью, близкой к единице.
Вы хоть Макконнелла почитайте для общего развития, что ли, прежде, чем чушь пороть. Программы пишутся - в том числе и для людей, а не только для машин. Короткая жизнь объёкта - это во многом то, что борется с кашей в голове. А то, что жаба это переваривает с трудом - так это проблема жабы и её мусорки.
> А то, что жаба
> это переваривает с трудом - так это проблема жабы и её
> мусорки.Там нет выделения на стеке, прекрасно приспособленного для короткоживущих объектов.
> Там нет выделения на стеке, прекрасно приспособленного для короткоживущих объектов.что, в принципе, решается хитрым generational gc. стек тянет за собой толстый и невкусный механизм unwinding'а, а generational gc позволяет не загромождать VM всякой бесполезной фигнёй.
одно дело, когда у меня try/catch/finally явно в коде стоит, и unwind frames создаются только для такого кода. и совсем другое — когда создаются везде, где меня угораздило создать локальный автоматический объект.
Твой нелюбимый Куздра об этом недостатке Java как-то рассказывал, но где - не помню.
> Твой нелюбимый Куздра об этом недостатке Java как-то рассказывал, но где —
> не помню.этому товарищу доверие нулевое вообще, он феерически некомпетентен. проверять каждое его утверждение на предмет «а где он в этот раз накосячил» — мне откровенно лень.
p.s. другое дело, что для GC неплохо бы иметь несколько больше помощи от MMU, чем сейчас предоставляется через API, но это уже совсем другая песня. ребята из Azul Systems, например, показали, что при некоторой поддержке GC становится сильно легче жить.
> Вы хоть Макконнелла почитайте для общего развития, что ли, прежде, чем чушь
> пороть. Программы пишутся - в том числе и для людей, а
> не только для машин. Короткая жизнь объёкта - это во многом
> то, что борется с кашей в голове. А то, что жаба
> это переваривает с трудом - так это проблема жабы и её
> мусорки.Еще раз - это проблема не среды. Это проблема п и д о р а^Wп р о г р а м м и с т о в.
> Еще раз - это проблема не среды. Это проблема п и д
> о р а^Wп р о г р а м м и с т о в.Проблема только в том что сферическая среда в вакууме - ни о чем. А на яве, да и на JS обычно пишут ... изены всякие. Нет, парочка специалистов по рокетсайнсу на всю планету и на яве могут нормально писать. Остальные на ней пишут "как изен".
> Остальные на ней пишут "как изен".Смеёшься что ли?
Я привёл прямо противоположную историю о тех бывших C/C++ программистах, которые привыкли на каждый чих делать malloc()/free() в своих "сишечках", а потом пересели на Java с розовой надеждой на автоматику управления жизненным циклом объектов.
С таким отношением, естественно, скоро наступает песец и большое удивление на тему "куда это подевалась свободная память?!". Лихорадочно начинают дёргать ручник сломанного стоп-крана System.gc() в надежде на то, что JVM за них приберёт ИХ_ЖЕ мусор, который они бездумно наплодили в циклах и связали с долгоживущими объектами кучей ссылок.
Ага — щаз.
> о тех бывших C/C++ программистах, которые привыкли на каждый чих делать malloc()/free() в своих "сишечках", а потом пересели на Java с розовой надеждой на автоматику управления жизненным циклом объектов.какая-то невероятно неправдоподобная история. есть такая вещь, называется "сила привычки", так вот, если это действительно не жопорукие кодеры, то они бы и на джаве продолжали бы использовать подобные механизмы, как malloc/free: вызывать деструкторы объектов, когда они уже не нужны. в общем, нестыковка какая-то, нонсенс. сам историю выдумал?
> сам историю выдумал?а то. изя же говнокодер, причём говнокодер, который не знает ни одного языка нормально. иначе до него бы дошло, что те, кто «постоянно дёргают» — никак не могли наплодить якорей на автоматические объекты, потому что привычка чистить перед free() вырабатывается потом, кровью и болью. и потому такой программер на автомате вместо free() писал бы '= null' какое-нибудь.
>привычка чистить перед free() вырабатывается потом, кровью и больютак вот об чем и речь. или, может это джава так пагубно влияет, что люди явно дегенерировать начинают :-D
да нет, я изю много лет знаю (думаю, больше десяти), и не только по этому ресурсу. тут дело такое: он сначала был дурак, а потом увлёкся жавой. а не наоборот. :3
не, я не про него, а про его полёт фантазии, в которой бывшие программисты сей и плюсей дружно понадеялись на мегакрутую фичу жабы - автоматический мусоросборщик.
есть подозрение, что это отголоски его личного неприятного опыта.
Одно лучше другого,
Лучше бы что то типа Dart увидеть прям в ядре браузера
http://www.dartlang.org/
http://golang.org/
> Одно лучше другого,
> Лучше бы что то типа Dart увидеть прям в ядре браузераФичи дарта тут https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_...
> https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_...SIMD это хорошо, но...
...нет необходимости менять синтаксис языка ЛИШЬ ТОЛЬКО для того чтобы добавить туда SIMD
это можно реализовать -- даже и с существующим синтаксисом ECMAScript:
https://github.com/johnmccutchan/ecmascript_simd/blob/master...
>> это можно реализовать -- даже и с существующим синтаксисом ECMAScript:спасибо но костыли не нужны совершенно для скачки хлама
Лучше бы родили стандарт байткода для generic web browser vm. Не смогли договориться об интерфейсах в различных аппаратно-софтенных платформах, отрыгните хотя бы для браузеров. Нет, млин, будем костылять через конверторы c/c++ в js, лить эту беду по http и хвастаться какой у нас реализован расклиздатый jit
> Лучше бы родили стандарт байткода для generic web browser vm.Так вроде NaCl оно и есть, правда пока только у Google и не стандарт.
Похоже что оно. Вива ля Гугл?
нет, это совсем не оно. NaCl это нативный код.
Они PNaCl допилили, там именно байткод. Да и какая разница, байткод или натив - лишь бы были стандартные соглашения по вызовам.
> Да и какая разница, байткод или натив…всё равно кроме x86 процессоров нет!
_P_NaCl - уже LLVM.
> _P_NaCl — уже LLVM.я рад за него. а за тебя — нет: ты не умеешь читать то, на что отвечаешь.
>> Лучше бы родили стандарт байткода для generic web browser vm.
> Так вроде NaCl оно и есть, правда пока только у Google и
> не стандарт.NaCL/PNaCl ---- это <embed>-сущность
ну не могут быть <embed>-сущности быть даже близко быть в стандарте. слишком уж кривая задумка!!
более вероятно что вообще <embed>-тэг (и <object>-тэг) ВЫПИЛЮТ из стандарта! :)
Asm.Js ---- является намного более безкостыльное решение чем NaCL/PNaCl .
> Asm.Js ---- является намного более безкостыльное решение чем NaCL/PNaCl .ага. примерно такое же хорошее, как твой русский.
> Нет, млин, будем костылять через конверторы c/c++ в js,ну сколько уже раз повторять блин -----
Asm.Js -- НЕ ЯВЛЯЕТСЯ Яваскриптом!!! из него НЕЛЬЗЯ получить: ни доступа к объектам Document-Object-Model ни доступа даже к динамечески выделяемой памяти и сборщику мусора.
(ды и вообще объектов-ни-каких нет в Asm.Js, там только байты, и манипуляция с байтами..)
всё взаимодействие с внешним миром -- в выполяемом модуле Asm.Js -- происходит либо через FFI-интерфейс либо через общую бинарную память!.. ЭТО ДАЖЕ БЛИЗКО НЕ ПОХОЖЕ НА JAVASCRIPT!!!
Asm.Js даёт свободы -- даже меньше чем даёт свободы уровень языка Си! это уже реально почти ассемблер!! (есть же люди которые называют язык Си -- кросплатформенным ассемблером?! а Asm.Js ещё более низкоуровневый язык чем язык Си!)
(FFI --- "Foreign Function Interface")
<sarcasm>...но выже блин такие умные, вы даже не читая спецификаци (и не написав ни одного скрипта с использование Asm.Js) уже всё знаете</sarcasm>
попробуйте напишите на asm.js -- HelloWorld -- который оперирует с массивами данных и оперирует с указателями на функции --- и тогда поймёте настолько Asm.Js похож/или/не_похож на Javascript .
...ну например --- напишите модуль сортировки (таким образом: будут использованы массивы) с выбором алгоритма сортировки (таким образом: будут использованы указатели на функции).
или напишите модуль AES-шифрования. (в этом случае тоже можно задействовать массивы и указатели на функции).
чего вам терять? вот прям щаз сядьте и напишите!
откуда такая истерика-то? я читал предварительные спеки этих мегакостылей ещё до того, как тебе в новостях о них рассказали. родилось мегакостылями и осталось мегакостылями. по сравнению с этим даже си выглядит верхом изящества.
> по сравнению с этим даже си выглядит верхом изящества.ну логочни что ЯП Си сделан для того чтобы на нём писали люди.
а ASM.JS сделан для того чтобы в него компилировали из Emscripten (а НЕ для того чтобы напрямую на ASM.JS что-то писали люди!).
> а НЕ для того чтобы напрямую на ASM.JS что-то писали люди!
если эта фраза не понятна для тебя -- то повторяю: напиши хоть что-то вручную (без Emscripten) на ASM.JS и поймёшь почему я так говорю.
ASM.JS ---- это по сути лишь просто обычный байткод, но записынный в текстовом виде, а не в бинарном виде.> откуда такая истерика-то?
оттуда что пишут на форумах ерись, называя Asm.Js ---- Яваскриптом, или костылём.
************************************************************
разработчики ASM.JS могли бы запросто сделать чтобы код на ASM.JS был-бы в бинарном виде, а не в текстовом виде как щаз.
...но если бы они так сделали -- то это не увеличело бы производительность выполнения (а увеличело бы производительность лишь её инициализации). однако Emscripten в таком случае должен бы был генерировать двойной результат: на Javascript и в бинарном виде ----- И ЭТО БЫЛО БЫ ОЙ КАК ГЛУПО!!
вот почему как защитник очередных костылей — так даже человеческим языком, на котором пытается писать свою «защиту», и то не владеет нормально, а?
> Лучше бы родили стандарт байткода для generic web browser vm.Дык LLVM есть. PnaCL. Но что-то мне кажется что не договрятся.
>> Лучше бы родили стандарт байткода для generic web browser vm.
> Дык LLVM есть. PnaCL. Но что-то мне кажется что не договрятся.неа. он у LLVM неудобный для написания интерпретаторов. и не очень удобный для трансляции слабо типизированых языков с GC. поэтому LLVM можно использовать как одну из реализаций VM, но завязывать всё на него — неудобно.
Хоть кого то осенило, что недостаточно просто разрабатывать мощное железо чтобы была производительность надо еще и правильно его программировать. А то сейчас часто так: Что то программа тормозит, ай ладно напишу системные требования выше и проблема решена.
Что забавно - осенило одного из людей, стоявших у истоков этой веселой тенденции забивания на качество софта.
Слоупок у слоупока украл слоупока.
пля он сравнивает JavaME и JavaScript
че мелочится и городить, OpenJDK интегрируем в браузер и делов то.
Java апплетам в браузере сто лет в обед.
> приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ.J2ME работала в основном в AOT-окружении, с предварительной прекомпиляцией байткода, так как для полноценного JIT нужно довольно много дорогой на мобильных устройствах оперативной памяти.
> Clarification update: For some reason people read this as a rebuttal of Drew Crawford article, it is not. It is merely a response, I accept almost everything he said but have a slightly different interpretation on some of the points.
Недавно делали реализацию алгоритма RSA-шифрования на JS. Все правильно пишут - JS адский тормоз, на нем нереально добиться нормальной производительности. Впрочем и Java - жуткий тормоз ...
> Недавно делали реализацию алгоритма RSA-шифрования на JS. Все правильно пишут - JS
> адский тормоз, на нем нереально добиться нормальной производительности. Впрочем и Java
> - жуткий тормоз ...Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между сиденьем и консолью (С) Я
> Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между
> сиденьем и консолью (С) ЯНу да, конечно, только вот почему-то во всяких там кодеках и криптографии до сих пор юзают максимально оптимизированный вручную ассемблер с распоследними наборами команд. Потому что в разы быстрее работает, если горячий кусок так выписать.
>> Не бывает тормознутых систем. Тормоза бывают лишь между ушей у прокладки между
>> сиденьем и консолью (С) Я
> Ну да, конечно, только вот почему-то во всяких там кодеках и криптографии
> до сих пор юзают максимально оптимизированный вручную ассемблер с распоследними наборами
> команд. Потому что в разы быстрее работает, если горячий кусок так
> выписать.Ещё можно вспомнить апплеты "банк-клиент", которые почему-то не используют ассемблер (вот ведь странно), а юзающие алгоритмы на Java.
чем меньше вспоминать банковский софт — тем лучше. а то там и ActiveX были, помнится. тоже мне, вершина технологий.
> чем меньше вспоминать банковский софт — тем лучше. а то там и
> ActiveX были, помнится. тоже мне, вершина технологий.Увлекался COM-объектами? :)) Я тоже в своё время, но быстро понял угрёбищность этого.
изя, ты себе остаток мозга повредил?
мдя. вообще-то, на сколько я понял, подразумевалось совсем другое. раньше светились с завидным постоянством в новостях проблемы с безопасностью ActiveX. причем, некоторые дыры не закрывались месяцами. кто читал в своё время эти новости, тот знает, что ActiveX - одна большая дырень, спроектированная без какого-либо концепта безопасности ПО.
а какая может быть вообще с ActiveX безопасность, если там даже песочницы не предусмотрено изначально? а учитывая, что в XP юзер ещё и локальный администратор… заходи кто хочешь, бери что надо. жабка хоть изначально в песочницу посажена (пусть в песочнице и находят дырки, но тем не менее).что, как я выше писал, не мешало банкам вовсю ActiveX использовать (а кое-кто, по слухам, и до сих пор…). и я намекал на то, что «а банки используют» — вообще никакой не аргумент и ничего не доказывает.
Ну да, по сравнению с джава javaScript не такой уж и тормозной
ЖабоСкрипт не нужен уже просто за то, что это жабоскрипт. Как тот же ЛИСП или Хацкель - маргинальные уникумы для узкого круга некритичных задач.
Плюс, сама природа "динамики" - её уже не разогнать ничем. Да и сама опасность узнавать об ошибке только в рантайме - бомба. Оно нам надо??
>> В своей заметке Шай проводит достаточно много аналогий с Java и, в частности, приводит пример достижения приемлемой производительности Java Mobile на телефонах Nokia с экраном 240x320 и 2 Мб ОЗУ.оно еще существует?