Разработчики проекта Mozilla объявили (https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n.../) об интеграции в ночные сборки Firefox оптимизирующего модуля OdinMonkey c реализацией поддержки Asm.js (http://asmjs.org/) - низкоуровневого подмножества (http://asmjs.org/spec/latest/) языка JavaScript, позволяющего существенно увеличить производительность приложений, автоматически преобразованных в JavaScript с языков C/C++ при помощи таких инструментов, как Emscripten (https://www.opennet.ru/opennews/art.shtml?num=35313) и Mandreel (http://mandreel.com/). Ожидается, что поддержка Asm.js будет включена в выпуск Firefox 22, запланированный на 26 июня.
Из отличительных черт Asm.js можно отметить поддержку строгой типизации, при которой переменные на протяжении своего жизненного цикла имеют заранее известный и не изменяемый тип. Наличие информации о типах позволяет использовать не только JIT, но и предварительную AOT-компиляцию, выполняемую для всего кода до начала его выполнения и генерирующую более простой и эффективный машинный код. При этом, в отличие от JIT-компиляции, Asm.js обеспечивает предсказуемую производительность и не зависит от сборщика мусора. В итоге, код с известной информацией о типах выполняется всего в два раза медленнее нативного приложения, написанного на C/C++. В то время как без Asm.js скомпилированное с использованием Emscripten приложение выполняется медленнее в 5 раз.<center><a href="http://kripken.github.com/mloc_emscripten_talk/macro4b.png&q... src="https://www.opennet.ru/opennews/pics_base/0_1363977912.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
Достоинством Asm.js также является то, что он отлично интегрируется с существующими JavaScript-движками, не требуя подключения новой виртуальной машины или JIT-компилятора - достаточно внести небольшие оптимизацию в текущий движок JavaScript. В частности, для SpiderMonkey подготовлен оптимизирующий модуль OdinMonkey, реализующий дополнительные техники оптимизации для Asm.js.
Подмножество JavaScript, предлагаемое в Asm.js, полностью совместимо со стандартным JavaScript и может выполняться в любых браузерах, так как вся дополнительная информация определяется в форме аннотаций (например, "x = x|0; // x : int"). Совместимость полностью сохраняется - если браузер не поддерживает Asm.js, то код выполняется как обычный JavaScript, а если поддерживает - включается дополнительный оптимизирующий модуль, учитывающий добавленные в код аннотации.Поддержка Asm.js уже обеспечена в Emscripten и активируется при сборке с установкой флага "ASM_JS=1". Пока код Asm.js нацелен на автоматическую генерацию, но в будущем, планируется обеспечить поддержку генерации Asm.js-кода на основе исходных текстов, написанных на более удобных для разработчиков низкоуровневых диалектах JavaScript, таких как LLJS (http://lljs.org/) (Low-Level JavaScript), что позволит использовать Asm.js не только для кода, транслируемого с C/C++, но и для проектов, изначально развиваемых на JavaScript.
URL: https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=36468
идея Asm.js -- явно лучше чем гугловский NaCl(Asm.js -- чистое решение, без всяких <object> размером в нуль пикселей)
Ну вот если б еще сделали вменяемые области видимости и фиксированные структурные типы - было бы на язык хоть как-то похоже. Ну, или что-то в него транслировать - интересно, хоть сколько-нибудь большое подмножество с# получится?
> Ну вот если б еще сделали вменяемые области видимости и фиксированные структурные
> типы - было бы на язык хоть как-то похоже.Asm.js - это даже не ассемблер, это машинные коды, какие там области видимости?
Сорри, глянул спеку детальнее... Согласен. Тогда только один вопрос открытым остаётся - сподобится ли кто-нибудь сделать нормальный язык, эффективно транслируемый в это чудо. Ну хоть валу или Go, на C# или safe-часть D я и не надеюсь.
в новости упомянут emscripten, преобразующий в это дело бит-код LLVM. Для LLVM существует (судя по гитхабу, активно развивающийся) LDC, LLVM D Compiler. Танцуйте :)
Страшно представить себе какую цепочку геморроя надо пройти и сколько дополнительных знаний задействовать (кроме знания D и JavaScript с HTML) чтобы написать таким образом JavaScript-библиотеку на D.
> образом JavaScript-библиотеку на D.Хорожее дополнение к asm.js получится :)
Что интересно - на D (еще первом) был Валтером Брайтом в одно рыло написан движок JS, который на тот момент рвал всё и вся. Теперь, конечно, он давно отстал, так как не развивался в принципе. А вот прасер XML, кажется, до сих пор самый быстрый, хотя тоже еще под D1 писан.
> одно рыло написан движок JS, который на тот момент рвал всёну, не всё, а только JScript. который «порвать» была невелика задача. опера, емнип, на тот момент пошустрей была.
кстати, на c++, по-моему. а на D он потом портирован был. хотя может и наоборот, тут мне лень на сайт лазить.
Именно дишный был весьма шустр
Совершенно не представляю, как можно заведомо многопоточный (из-за GC) D осмысленно оттранслировать в JS. А даже если получится - скорость этой самой сборки мусора будет жуткой. Это так, одна из проблем. Тут надо с фронтенда начинать. А LDC - да, очень достойного качества компилятор.
> Совершенно не представляю, как можно заведомо многопоточный (из-за GC) Dа что, они уже осилили concurrent gc? помнится, когда я смотрел исходники (давно, да) — там был обычный stop-the-world, mark-and-sweep. конкурентным сборщиком даже и не пахло.
Да вроде thread-local делали. В любом случае он у них в отдельном потоке крутится
> Да вроде thread-local делали. В любом случае он у них в отдельном
> потоке крутитсяну, у xds, емнип, тоже так было, но сборщик «спал», пока его не пинали, потом делал «stop-the-world», собирал, и снова будил мир, а сам засыпал.
на самом деле давно хочу попробовать допилить туда настоящий concurrent gc (если ещё не), но не могу найти мотивации. вот этот вот: http://doc.cat-v.org/inferno/concurrent_gc/ очень забавная штучка. впрочем, вполне возможно, что пока я чесал зад, это (или что-то лучшее) давно уже реализовали.
кстати, вот у D как раз неплохой потенциал в плане сборки мусора. потому что компилятор может сборщику активно помогать. за счёт некоторой потери в оптимальности работы с регистрами можно действительно вкусный precise gc сделать.
Для @safe-подмножества - да. А если @system - то там хрен поймёшь, где что лежит. Но и так неплохо выходит, вроде XML-парсер у них супершустрый именно за счет активного использования GC.
Может Dart сгодится? Было бы не плохо.
Это просто прекрасная новость! Давно ждал подобного в JS. Главное чтобы Гугл или Эппл поддержали эту инициативу и тогда все остальные подтянутся.
Почему в последнее время все так на JS поехали? Этой технологии уже сто лет, что изменилось?
Ну как же. HTML5, canvas, webgl, node, увеличение производительности на порядок.
Ога, все вычисления на юзера переложили... Типа теперь каждый ССЗБ, а не сайт кривой!
Тормозит видео - купи видюшку!
Тормозит JS - купи процессор!
Тормозит сеть - купи тариф побольше!
Тормозит диск - купи SSD!Хочешь прочитать рецепт приготовления пельменей?! - Купи 1024-ядерный Xeon c 1Tb RAM и Quadro 100500980 GTX Ulimate OverDrive Extended Super Edition!
---
И ни одна интерпрайзная программисткая песта, даже не подумает об оптимизации кода
оптимизации алгоритмов, минимизации трафика, устранение задержек!!!
А нахера?! Пиплы - говно, пипл - схавает!Скоро мля, доживем, сервера будут полностью выгружаться в оперативку к юзеру,
и он будет тупа шарится у себя по RAMе, на с серваком будет происходить только
синхронизация.А в венде появиться новое предупреждение [ У Вас недостаточно памяти для просмотра этого сайта ]
+100500 =)
так надо же производителей железяк поддерживать, а то вообще без работы останутся
павлинух, тебя заносит. статья как раз о том, что JS оптимизируют до такой степени, что он тормозит теперь в 2.5 раза меньше, чем раньше. как раз в заботе о твоем пентиуме-166, возможно даже без ММХ. так что не слюной брызгать надо, а радоваться - JS все равно никуда не уйдет, а ты в кои-то веки можешь сэкономить $50, отложив апгрейд своей S3Trio64 на какой-нибудь ATi Rage 3D и оставшись жить еще год на 128М рамы.
ты этот мегакостыль вообще смотрел? эти идиоты понаделали гигакостылей, изо всех сил стараясь и рыбку съесть (остаться совместимым с «обычным js»), и на оптимизатор сесть (при помощи бессмысленных конструкций вроде «i = 0+i» мы теперь указываем тип переменной). в итоге эта херь напоминает xml: и для человека выглядит дико, и для машины неудобно.но ничего, изобретательным костылестроителям такие мелочи не помеха, костылестроители опытные, сумеют воткнуть костыль даже туда, куда он на первый взгляд не втыкается.
> ты этот мегакостыль вообще смотрел? эти идиоты понаделали гигакостылей, изо всех сил
> стараясь и рыбку съесть (остаться совместимым с «обычным js»), и на
> оптимизатор сесть (при помощи бессмысленных конструкций вроде «i = 0+i» мы
> теперь указываем тип переменной). в итоге эта херь напоминает xml: и
> для человека выглядит дико, и для машины неудобно.
> но ничего, изобретательным костылестроителям такие мелочи не помеха, костылестроители
> опытные, сумеют воткнуть костыль даже туда, куда он на первый взгляд
> не втыкается.Любым полудуркам только открой исходники. Тут же найдется, что "улучшить"
если что: я имел в виду сам asm.js.
> сумеют воткнуть костыль даже туда, куда он на первый взгляд не втыкаетсяОх, поручик...
Как ни печально, но в большинстве случаев тормозит сам пользователь. И его не поменяешь — рынок, однако. А пользователь склонен ориентироваться на те самые свистелки и рюшечки, благодаря которым он может демонстрировать своё место в социальной иерархии. И тут — всё как с биткойнами — производительность не подделаешь ))> Скоро мля, доживем, сервера будут полностью выгружаться в оперативку к юзеру, и он будет тупа шарится у себя по RAMе, на с серваком будет происходить только синхронизация.
А вот тут Вы что-то путаете. Времена статических сайтов уже прошли. А на всякие джумлы и вордпрессы нужны не самые древние сервера )))
> Времена статических сайтов уже прошли.только в пустых черепах маркетолухов.
> Тормозит видео - купи видюшку!
> Тормозит JS - купи процессор!
> Тормозит сеть - купи тариф побольше!
> Тормозит диск - купи SSD!Дело в том, что у юзера уже есть хорошая видюшка, процессор и анлим-интернет. Этим можно пользоваться и не тратить дорогое время программиста на оптимизацию и рефакторинг
> Дело в том, что у юзера уже есть хорошая видюшка, процессор и
> анлим-интернет. Этим можно пользоваться и не тратить дорогое время программиста на
> оптимизацию и рефакторинга ещё лучше — не тратить время пользователя на говнокод. я даже не знаю, стоит ли пояснять, что оптимизация программы в итоге даёт выигрыш для всех пользователей, а «купи ещё 64 терабайта RAM» — ни для кого в итоге. мне казалось, что это очевидно.
> «купи ещё 64 терабайта RAM» — ни для кого в итоге.Как это? А производители оперативки?! :)
А 64Тб RAM я бы купил. Если б стоили дешево и лезли в сокеты на моей мамке. А то вон сканы интернета - 9Тб барахла. А у меня даже на винче столько нету.. :(.
> А 64Тб RAM я бы купил.не так долго ждать-то. сколько лет назад гигабайт памяти казался неумной сказкой?
> не так долго ждать-то. сколько лет назад гигабайт памяти казался неумной сказкой?(глядя на платку размером с креду с гигом оперативки) а ведь ты пожалуй прав. Правда есть опасения что дальше закон Мура начнет буксовать по чисто физическим причинам.
решат как-нибудь, я оптимист. проблему с конским навозом на улицах вон решили, и кардинально.
Проблема в том, что идея «не тратить дорогое время программиста» посещает слишком много голов одновременно. Мысль же, что отдельно взятый продукт может оказаться не единственным, кто претендует на ресурсы пользовательского компьютера, почему-то куда менее популярна. В итоге производительность железа растёт и растёт, а софт этот рост шустро подъедает, иногда с опережением. При этом функционал, по крайней мере в строну увеличения, за то же время меняется не в разы, а на жалкие проценты. Вот и получается, что «блокнот» с подсветкой синтаксиса нынче жрёт как целая операционная система с графикой лет 20 назад. И браузер жрёт, причём ещё больше. И просмотрщик картинок. И вообще все-все-все.
сейчас тебе расскажут, что это стенания нищеброда. Реальные Пацаны просто докупают ещё коробку терабайтных винтов, стопку ssd и ящик планок памяти.
кстати, ssd то говно ещё. нынче уже начинаются проблемы с этими накопителями. скоро они перерастут в жесткач, когда через полгода эксплуатации они будут терять половину своей изначальной вместимости при интенсивном пользовании.
ну, я их не использую пока. нужды не вижу. у друзей есть, вроде особо не жалуются. мне оно пока так же неинтересно, как и x86_64.
> ну, я их не использую пока. нужды не вижу. у друзей есть,
> вроде особо не жалуются. мне оно пока так же неинтересно, как и x86_64.На самом деле клевые штуки - работа с разлапистым деревом исходников например там становится просто реактивной. Seek time порядка нуля. Практически как рамдиск, только энергонезависимый и крупнее по объему. Впрочем, меня RAM-диски испортили еще в конце 80-х - взлет CP/M за 2 секунды выглядел очень круто :)
ну, я и так тормозов не вижу на многомегабайтных исходниках. таки работа мозгом и набор текста занимают сильно больше времени, чем компиляция. а полные ребилды вообще делаются на фоне и не мешают.
> кстати, ssd то гoвно ещё. нынче уже начинаются проблемы с этими накопителями.
> скоро они перерастут в жесткач, когда через полгода эксплуатации они будут
> терять половину своей изначальной вместимости при интенсивном пользовании.При интенсивном использовании SSD просто равномерно мрет по всей поверхности. Пока есть сектора в резерве - из их числа подмена идет. А когда они кончатся - начнутся всякеи спецэффекты. До этого лучше не доводить и сбэкапать данные с такого носителя при первых признаках.
А так с SSD никакой проблемы нет, если с умом юзать. У меня вот за год на 1% протерся. Зато бут - 5 секунд. Запуск программ - моментально. Работа с файлами? Это как если пересесть из древней копейки в реактивный истребитель. В общем замечательная штука. Если пользоваться с умом сильными сторонами технологии и обрулить слабые. А техника в руках дикаря - груда металлолома. Да, под нелинейный монтаж видео или кэши брать SSD - тот еще разор. Но есть и куча иных применений. Где они прекрасно выступают. В частности - как системный накопитель десктопа это просто великолепно. А вот для жирных данных лучше оставить механические HDD. И дешевле и лимитов по перезаписям нет.
Вы абсолютно правы! посадить бы их за железо 80-х, к примеру... =))) впрочем, современное железо никак не мешает ребятам, создающим демо-сцены, писать код в 256 байт (одна из номинаций) =)))
> Вы абсолютно правы! посадить бы их за железо 80-х, к примеру... =)))У меня в конце 80-х был агрегат с 256К рамдиском. Взлет CP/M на горячую занимал 2 секунды. Этот результат даже современные писюки не побили. У них POST в биосе дольше раздупляется чем тот агрегат грузился в систему (там был простейший ROM-загрузчик без самотестов и определения оборудования вообще).
> впрочем, современное железо никак не мешает ребятам, создающим демо-сцены, писать код
> в 256 байт (одна из номинаций) =)))Если хочешь жесткача - возьми PIC16. Узнаешь что такое понастоящему галимый процессор.
> Если хочешь жесткача - возьми PIC16. Узнаешь что такое понастоящему галимый процессор.Ыммм... ATmega88 не сильно лучше PIC16 - а вон что умельцы вытворяют на голом проце: http://www.linusakesson.net/scene/craft/
Понимаешь ли в чём тут дело, количество перешло в качество, а образно выражаясь вебу неудобно в вебе. Ну вот почтовый клиент в браузере, который совершенно неспособен интегрироваться с рабочим столом и перезагружает всю страницу по каждому пустяку,— это же лажа полная, не правда ли? Ок, навернули сверху скриптов, сделали поддержку более плотной интеграции в браузере… и стал этот пепелац дико тормозить. Ок, оптимизировали браузеры. Ещё оптимизировали браузеры. Народ заметил, что JS это уже не так и плохо, и на нём можно писать простенькие интерфейсы, а не ужасаться тормозам, но ведь на них дело не остановилось!.. и стал этот пепелац дико тормозить, снова. Ок, снова оптимизировали движки. А народ видит, что JS становится всё ближе и ближе по скорости к нативному коду, да и сам язык простой и удобный, в отличие от сей и плюсов, и всё более сложный код на нём клепает. Да ещё и всякие извращения придумали, вроде конвертации из сей в JS. Вроде и тормозное чудовище, но и думать не надо на чём его запускают — оно просто работает. И пепелацу деваться просто некуда — приходится развиваться.
Вот это вот всё.
> Ну вот почтовый клиент в браузере,
> который совершенно неспособен интегрироваться с рабочим столомЭто совершенно не связано с языком JS. Это связано с тем, что "рабочий стол" выполняется в одной ОС, а "почтовый клиент" - в другой. Т.о. плохо налажено взаимодействие между виртуальными машинами => нужно смотреть в сторону VM/370, где это было каким-то образом отработано.
Там наверняка будет что-то навороченное, а здесь - всего лишь простейшее взаимодействие в рамках гуя нужно. Можно просто дать отдельную D-Bus, на которую и выпихивать события - понятно, браузер должен добавлять URL сайта и нужна фильтрация - какие сайты что могут получать. Проектирования на пару дней, и реализации на столько же.Ну или если хотеть красиво и стандартизированно - то компонентные интерфейсы и возможность для сайтов регистрироваться (с запросом пользователю, понятно) реализациями тех или иных компонент. Тогда, грубо говоря, локальное приложение сможет открыть пользователю гугловскую адресную книгу, а веб-приложение - открыть локальный редактор картинок.
А ещё гугл что-то подобное пытался ввести, там для веб-приложений - но на десктоп оно, скорее всего, расширяемо.
> А ещё гугл что-то подобное пытался ввести, там для веб-приложений - но
> на десктоп оно, скорее всего, расширяемо.
Нет, не типа такого. Веб-интенты - это когда тыркаешь в социалочке кнопочку "редактировать картинку" и браузер тебе открывает эту картинку в каком-то совершенно другом веб-приложении-графическом редакторе (ты предварительно его, конечно, добавил себе как дефолтный редактор для таких случаев), после редактирования результат попадает обратно в социалочку. В общем, эдакие компоненты для веба.
Только вот тебе придётся писать скрипты, чтоб потом все необходимые в почтовом клиенте события обрабатывать. Без скриптов ты не обойдёшься. Их ведь и в локально установленном почтовике обрабатывать нужно. Ну а ещё я сказал не только о интеграции с рабочим столом — не выдёргивай половину фразы. А где скрипт, там и тормоза. По крайней мере так было, но… постепенно это перестаёт так быть.
> Ну а ещё я сказал
> не только о интеграции с рабочим столом — не выдёргивай половину
> фразы.Та половина фразы малоинтересна - скорость лечится движком JS или скоростью железа. А для реализации взаимодействия с другой ОС нужно придумывать что-то более серьёзное.
Тут тяжело сказать чья это головная боль. Вон в Ubuntu сделали расширение для фокса, которое позволяет отчасти наладить взаимодействие между сайтом и рабочим столом. Может на основе этих идей что-то и разовьётся более универсальное со временем. Просто без JS работающего во всех случаях со скоростью, близкой к нативному коду, это всё будет иметь мало смысла.
Напоминаю, изначально вопрос был о том, почему всех вдруг так заинтересовал этот JS. Так ведь потому и заинтересовал, что чем ближе веб-приложения подбираются к нише локально установленных приложений, тем больше он всех интересует, а чем больше он всех интересует, тем больше развивается всё, что этому сопутствует.
> Тут тяжело сказать чья это головная боль.Браузера и ОС. Причём, скорее именно браузера.
> Напоминаю, изначально вопрос был о том, почему всех вдруг так заинтересовал этот JS.
Удобно использовать конечному пользователю. Для программиста это геморрой - один единственный язык с несколькими сильно различающимися платформами.
> Браузера и ОС. Причём, скорее именно браузера.Ну да, на винде и маках некому, кроме самих браузеров.
> Для программиста это геморрой - один единственный язык с несколькими сильно различающимися платформами.
Вообще-то платформа одна — веб. Т.е. весь этот HTML, WebGL и прочее. Проблема в различиях реализации JS и поддерживаемых «технологиях» в различных браузерах, но это как говорить о различиях в компиляторах одного и того же языка или о различиях в разных версиях одной и той же платформы, а не как о принципиально разных. Браузеры уже превратились в прослойку универсального API для различных систем. Теперь остаётся только лишь идти вперёд.
Дело в том что люди наконец-то поняли что это html5 это самый кроссплатформенный стек для разработки приложений из всего что есть в данный момент на рынке.
единственно что нахрен никому не нужный. а так да, правильно.
"Если звёзды зажигают, значит это кому-нибудь нужно". И да, отучаемся говорить за всех!
И самый уродливый при этом. Это как взяли небольшой красивый домик и понастроили к нему пристроек по мере необходимости.
Одним нравится его платформонезависимость, другим нужна асинхронность и неблокируемый I/O...
внезапно выяснилось, что это, все-таки, ЯП
Это повлияет только на немногочисленные жирные выхлопы emscripten на открываемых html-страницах? Или есть надежда, что кое-какой браузер, написанный на javascript, тоже получит ускорение?
> браузер, написанный на javascriptSup dawg, I herd you like browsing, so I put a browser into your browser so you can browse while you browse!
А на самом деле новость дочитай. Там всё сказано.
Дочитал. Там лишь надежды и идеи на тему каких-то левых проектов.
Явно же сказано, что asm.js применим и в прочих проектах — им просто нужно использовать его аннотацию. Просто сейчас эта аннотация генерируется автоматически для C/C++ кода, но никто не мешает её использовать в других местах.
сколько можно костылить..... пора уже на dart переходить или какойнибудь typescript но разроботчики броузеров сконцентрированы на награмождении новых костылей для нелогичного неоднозначного javascript который свой век давно отжил. поделка написанная за несколько недель в условиях жестких сроков зачем ее тянут дальше!??
Оно да, но в таких масштабах революции страются не устраивать - уж очень дорого обходятся. Лучше помаленьку эту поделку до ума доводить.
> пора уже на dart переходить или какойнибудь typescript...комментатор надеюсь понимает что даже в гипотетическом случае перехода на dart или/и typescript -- то всё равно это НЕ избавило бы от необходимости разработать: asm.dart и/или asm.ts ???
asm.js -- это всего лишь способ записать низкоуровневые операции таким образом чтобы эта запись не была протеворечащей с теми браузерами которые не понимают asm.js .
> asm.js — это всего лишь способ записать низкоуровневые операции таким образом чтобы
> эта запись не была протеворечащей с теми браузерами которые не понимают
> asm.js .ты мне не поверишь, конечно, но тем не менее: это нормальные люди называют «костыль».
ну может быть в очень отдалённом приближении -- это чуть чуть похоже на костыль... и то я даже как-то не уверен.декларация -- "use asm" -- вполне очевидно декларирует что испьзуется особое подмножество языка! так-что здесь вполне чистое решение...
...отдалённая костыльность может быть только в том что asm.js не похож по своему синтаксису на традиционный ассемблерский вид?
но ведь поэтому он и называется asm.js :-) !!
> но ведь поэтому он и называется asm.js :-)Я думаю что мозильщики просто дорвались до луркоморья и решили проиллюстрировать термин "взаимоисключающие параграфы" как-нибудь покрасивее. Вот asm.js - достаточно красиво, по программмерски :)
(вздыхает) если дураков в школе хорошо и обильно бить — вырастают дураки пуганые, пригодные для простейших работ. а если не бить — получаешься ты.
но ведь меня били....и обзывание дураком -- это отличный способ уклонится от ответа?
очень "умно" :D
ну хотя наверно можно школьников называть дураками... да... для этого они и учатся...
> но ведь меня били.значит, мало били, ума не прибавилось.
впрочем, тут ты не отличаешься от большинства людей, у которых отсутствует навык абстрактного мышления.
> значит, мало били, ума не прибавилось.И всё-таки предлагаю попытаться объяснить хотя бы в виде списка ключевых слов на посмотреть и подумать.
смысла нет. если бы человек хоть допускал мысль, что не прав — можно было бы попробовать. а так — нет смысла.
> Из отличительных черт Asm.js можно отметить поддержку строгой типизации, при которой переменные на протяжении своего жизненного цикла имеют заранее известный и не изменяемый тип. Наличие информации о типах позволяет использовать не только JIT, но и предварительную AOT-компиляцию, выполняемую для всего кода до начала его выполнения и генерирующую более простой и эффективный машинный код.Осталось переименовать JavaScript в Java, a JavaScript Engine в Java Virtual Machine и всё встанет на свои места.
Это сколько же ресурсов и времени надо было впихнуть кошке под хвост чтобы прийти к такому результату ?
> Осталось переименовать JavaScript в Java, a JavaScript Engine в Java Virtual
> Machine и всё встанет на свои места.наконец-то до моих анонимных братьев начинает доходить
Блин, Михрюндель, зачем абижаешь? :-)Твои анонимные братья об этом уже давно догадывались, что всё закончится строгой типизацией и байт-кодом для JVM, которая будет встроена в браусер ;-)
Капитан просил передать, что JavaScript отличается от Java не только типизацией.
> Капитан просил передать, что JavaScript отличается от Java не только типизацией.Передай капитану, что его мнение майора не заинтересовало.
> Передай капитану, что его мнение майора не заинтересовало.Капитан сообщает что Капитан - это имя. А вовсе и не звание. Поэтому Капитану пофиг на майоров.
> Капитан просил передать, что JavaScript отличается от Java не только типизацией.Гуго, поведай нам детали капитанского послания.
> Осталось переименовать JavaScript в Java, a JavaScript Engine в Java Virtual Machine и всё встанет на свои места.
> Это сколько же ресурсов и времени надо было впихнуть кошке под хвост чтобы прийти к такому результату ?самый главный весомый (и решающий) аргумент почему JavaPlugin оказался хуже чем Javascript -- ...
... -- это потому что JavaPlugin является именно плугином. то есть является компонентом который "проволокой" привязан к www (через технологию "браузер внутри браузера").
если бы не эта "проволока" -- то может быть JVM давно бы уже был бы в браузерах, и проприетарщина цвела бы в www -- словно как весенний сад :) .
однако теперь строит ожидать наплыв проприетарщины -- только после того как asm.js (по сути тот же JVM) станет работающим и популярным (если конешно станет популярным).
впрочем мне пофиг на количество проприетарщины, а за Mozilla и общей прогресс я очень рад! ^_^
Строгая типизация -- это самое нужное в любой языке.
> Строгая типизация -- это самое нужное в любой языке.кроме языков, которые ценят время отведённое на разработку.
кстате не забудь ещё высказаться на тему "ручное управление ресурсами -- это самое нужное в любой языке" (ведь в asm.js и это тоже оптимизировали :)).
По сути из нестрогой типизации в большинстве программ обычно используется только возможность вернуть None/Null/Undef вместо подходящего значения.Есть, кончено, более сложные случаи, но для них в строго типизированном языке можно предусмотреть отдельный класс Object, от которого наследовались бы все остальные типы. В этом случае в программе в 90% случаев можно было бы использовать типизированный подход, а в остальных 10% случаев, когда это явно необходимо - не типизированный.
Почему-то все языки сейчас стремятся стать мультипарадигменными, поддерживая и процедурное, и объектное, и функциональное программирование, но что-то я не замечаю языков, которые бы стремились стать языками со смешанной типизацией.
Object это и есть смешанная типизация. в том же груви можно написать, какpublic def inc(def val) {
return val +1;
}так и
public Integer inc(int val) {
return val +1;
}
> По сути из нестрогой типизации в большинстве программ обычно используется только возможность
> вернуть None/Null/Undef вместо подходящего значения.
> Есть, кончено, более сложные случаи, но для них в строго типизированном языке
> можно предусмотреть отдельный класс Object, от которого наследовались бы все остальные
> типы. В этом случае в программе в 90% случаев можно было
> бы использовать типизированный подход, а в остальных 10% случаев, когда это
> явно необходимо - не типизированный.
> Почему-то все языки сейчас стремятся стать мультипарадигменными, поддерживая и процедурное,
> и объектное, и функциональное программирование, но что-то я не замечаю языков,
> которые бы стремились стать языками со смешанной типизацией.RTTI уже давно придумали
> RTTI уже давно придумалиАнонимные пользователи персональных компьютеров (АППК) шутку оценили и передают свой анонимный привет поклонникам Леопольда фон Захер-Мазоха.
А также ожидают дальнейших пояснений преимуществ этой революционной технологии от нашего брата-эксперта по имени СРР.
> Есть, кончено, более сложные случаи, но для них в строго типизированном языке
> можно предусмотреть отдельный класс Object, от которого наследовались бы все остальные
> типы. В этом случае в программе в 90% случаев можно было
> бы использовать типизированный подход, а в остальных 10% случаев, когда это
> явно необходимо — не типизированный.и тут язык резко перестал быть строго типизированым. сюрпрайз. и рыбку, и половые удовольствия — не получается, никак.
а вот опциональные аннотации типов — это штука вполне хорошая. в Strongtalk это сделали, получилось годно. но потом команду, увы, купили.
> кроме языков, которые ценят время отведённое на разработку.В которых парадигма "written once, debug everywhere"? Ну да, там любят сравнить гайки с бананами, а когда через полчаса работы все после долгих мучений наконец окончательно упало - они пытаются понять где же все-таки порылся этот факап. Убивая на дебаг больше времени чем ассемблерщик просадил бы на написание такого же куска на идеально вылизанном асме :)
Слушай, ну не неси совсем уж явную чушь. Гляди на скалу, D и прочее современное - там (да даже в плюсах нынешних) тип почти везде выводится автоматом. Зато еще до юнит-тестов отлавливается громадная куча ошибок вида "забыл засунуть в объект еще одно значение или сунул не с тем именем". Разработку это только ускоряет.
> тип почти везде выводится автоматомтолько его ещё и задекларировать надо.
а с учётом того что один и тотже алгоритм может (и ДОЛЖЕН! так как Don’t Repeat Yourself) выполнять манипуляции с различными видами объектов -- то нужно ещё и интерфейсы декларировать.
вот сидишь и занимаешься всем этим декларированием, вместо того чтобы сразу описывать алгоритмы.
не, не, я не спорю -- можно это делать... но время то ведь на всё это -- тратится!
а при этом ошибки могут получатся у языков со строгой типизацией -- такие же как в утиной типизации -- ввиду того что если нам была передана ссылка на объект какого-то типа -- то это вовсе не значит что это именно определённй тип, это может быть и наследник (который ведёт себя по-другому). короче один фиг -- полиморфизм
Пишешь алгоритм в шаблонной функции - и всё. При компиляции будет подставлен нужный тип и проведена статическая проверка. Duck-typing на этапе компиляции. Ну и да, динамический полиморфизм пихать только туда, где он нужен (это, кстати, не так уж часто). Хотя даже для него если наследование писали не анусом то класс-наследник сохраняет все гарантии предка. Что в том же D при желании проверяется контрактами (которые, кстати, круто дополняют юнит-тесты).При всём уважении - ты правда не в курсе, как пишется код на современных статически типизированных языках.
Им походу надо просто встроить компилер си/си++ в браузер и не париться :)
> Им походу надо просто встроить компилер си/си++ в браузер и не париться
> :)ещё не вечер. к тому всё идёт, да.
>> Им походу надо просто встроить компилер си/си++ в браузер и не париться
>> :)
> ещё не вечер. к тому всё идёт, да.ну Мозилка сделала возможным компилировать C/C++-программы -- для www-страниц
Clang => LLVM => Emscripten => Asm.js
...так-что ваш скепсис не очень ясен.
да, компиляция происходит НЕ внутри браузера (в отличии от JIT-компиляции, которая была БЫ нужна ДО создания Asm.js). ну и что с этого?
хочешь выполнять C/C++-программы в браузере, без применения всякого Javascript?! как раз это тебе и предоставили, радуйся...
причём [повторяюсь] -- без костылей. в чём именно по твоему мнению заключаются костыли, ты так и не назвал..
Ты синтаксис этого asm.js видел? Что это если не костыль? А не костыль - это NaCl или PNaCl (как по мне - и первого за глаза, там всего 4 варианта бинаря получаются).
ты синтаксис nexe-файла видил?...ой тамже двоичный код, и поэтому синтаксис поглядеть нельзя :D
[если нельзя поглядеть синтаксис значит синтаксис автоматически становиться хорошим?]
> видилчто, пардон?
ага :)
забиваешь url, исходники мгновенно сливаются, минут пять компиляются, и потом страница летает :)
> забиваешь url, исходники мгновенно сливаются, минут пять компиляются, и потом страница
> летает :)кстати, если убрать сарказм, то хранить и передавать не исходник html, а скомпилированый бинарный html было бы намного лучше.
> скомпилированый бинарный html было бы намного лучше.JS в принципе такое уже может изобразить :) парсинг и декомпрессию бинаря на нем можно сделать. Другое дело что там все это через ж#пу.
Для извращений вроде gmail, на который пользователь каждый день ходит - был бы не такой уж плохой вариант (ну, за исключением того, что лучше уж локальный клиент завести). С кешированием, конечно - но это даже сейчас довольно пристойно сделано.
очень здорово, но все забыли про минимайзеры.
скорость загрузки: упаковка в единый файл, отрезание лишних пробелов, новых строк. комментарии, кстати, тоже удаляются.
Вы не поняли. Комментарии в asm.js игнорируются (да, совсем игнорируются). Читайте спецификацию.
простите, до документации пока глаза не дойдут...
меня смутило:
> информация определяется в форме аннотаций (например, "x = x|0; // x : int")разве необходимая вспомогательная информация о типе переменной находится не в комментарии?
а комментарии удаляются минимизаторами.
> разве необходимая вспомогательная информация о типе переменной находится не в комментарии?нет, как раз в идиотском «|0».
> нет, как раз в идиотском «|0».хм. странные они. изобрели палочку и написали спецификацию? :) а я для этого на 1 делил или добавлял +''. и при объявлении тоже. работало :)
и так тоже. ребятам очень хотелось и на гениталий сесть, и рыбки откушать. то бишь, чтобы их костыль и в «обычном» браузере тоже работал. поэтому вместо внятной аннотации типов — вот такая анальная магия. по их задумке, «обычный» браузер просто исполнит, а специально обученый тут же поймёт, что x — это целое и только целое, и всё резко заоптимизирует.ну, то есть, идея сама по себе неплоха, но *такое* костыльное воплощение придумать — это действительно одарёнными надо быть.
> и так тоже. ребятам очень хотелосьа мне нравится фокс.
> ну, то есть, идея сама по себе неплоха, но *такое* костыльное воплощение
> придумать — это действительно одарёнными надо быть.имхо, они пытаются решить проблему, которая находится в зоне ответственности пользователя.
достаточно было бы сказать:
"ребята, если вы при объявлении сделаете так: var x = 1/1; , или так x = parseInt( str_x); , то далее мы до конца жизни переменной будем ее считать целым.
используя сие глубокое знание вы можете запустить третий квейк в FF уже вчера."думаю, тут вопрос политики. им хочется быть первыми, чтобы хромые под них подделывались.
я подозреваю, хромые скажут "пффф!" и забабахают, как я написал выше.
а чтоб ничего не ломалось, попросят указывать версию JS в секции <script
они пытаются привинтить костыли, а не решить проблему. «решить» — это выпнуть нафиг js и запилить что-нибудь нормальное. точнее, js оставить «как есть», и добавить что-нибудь хоть на том же llvm. специально для обезьян, которые решили, что браузер — это новая ОС и хотят там какие-то «приложения». пусть llvm их aot-откомпилит, и будет «родная» производительность. и идиотские танцы вокруг js не нужны.
> производительность. и идиотские танцы вокруг js не нужны.вы не правы. это идиотские танцы вокруг IE и Opera не нужны. если все забудут о наглом существовании этих броузеров, производительность всех джаваскрипт-библиотек утроится, а размеры ополовинятся :)
и все вздохнут с облегчением.
> вы не правы. это идиотские танцы вокруг IE и Opera не нужны.да всё, нет больше оперы. будет теперь сборка хромиума, только с буквой «о».
кстати: а какие претензии к поддержке ecma-стандарта оперой? УМВР.
> производительность всех джаваскрипт-библиотек утроится, а размеры ополовинятся :)насчёт размеров js, конечно, художественное преувеличение. тут больше стили урежутся :) а вот про скорость я уверен
собственно, особенности Опера уже никого не волнуют. остался гадкий майкрософт, который с 10м IE уже вынуждено встал в коленно-локтевую позицию. но ещё пока огрызается отдельными свойствами
> собственно, особенности Опера уже никого не волнуют.они и раньше не волновали. ну, потому что их не было, фактически. написаный *по стандартам* код вполне предсказуемо себя вёл. разве что анноящий баг с забытым redraw после удаления ноды приходилось таймером решать.
>> собственно, особенности Опера уже никого не волнуют.
> написаный *по стандартам* код вполне предсказуемо себя вёл. разве что анноящийкод-то вел. а стили и свойства - не всегда. это тоже неудобство, учитывая, что все сейчас хотят видеть вебдванольный интерфейс...
> код-то вел. а стили и свойства — не всегда.ну дык я весь код имел в виду. html, css, js. собственно, каких-то диких багов и не припомню. если, конечно, не в лыжах по асфальту.
я, впрочем, не веб-дисихнер, так, ковырял на досуге. что характерно: код, написаный и отлаженый в опере (весь который код, не только js) великолепно потом работал в тормозилле. а вот наоборот — не всегда.
> я, впрочем, не веб-дисихнер, так, ковырял на досуге. что характерно: код, написаный
> и отлаженый в опере (весь который код, не только js) великолепно
> потом работал в тормозилле. а вот наоборот — не всегда.я не то, чтобы много программировал на js в расцвет Оперы... плотнее занялся, когда опера пошла на спад. и проблем с именно js в опера не припомню, если писал в мозилла и с использованием каких-то библиотек. у меня мозилла первична.
вот со стилями приходилось возиться. особенно раздражало не что-то вычурное там, а просто стили форм. какие-нибудь аплоадеры, какие-нибудь красивые формы - "все должно быть как везде" и начинается любовь...
обычно как получалось: если дизайнер задумал конкретно сделать, тютелька-в-тютельку, а в опера не получалось, приходилось отказываться от какого-нибудь решения вообще и перерисовывать с другой логикой поведения. естественно, стили от этого пухли и, бывало, и js-код.сейчас знаете ли, в библиотеках js момент инициализации очень важен, поскольку от него зависит пауза при рендеринге. занимает дофига времени из-за проверок разных объектов и свойств броузера + подгрузка стилей.
тут избежание 10-20% проверок/стилей может очень радикально сказаться на визуальных ощущениях от загрузки страницы, вы знаете.
веб распух.
> веб распух.вот это главная беда. как только наши танки, мы перевешаем на столбах любителей «веб-приложений», и всё снова станет хорошо.
а вот кстати особенности вебкита скоро будут волновать почти всех. потому что вебкит — это такая замена IE теперь в плане сранья на стандарты.
> вебкит — это такая замена IE теперь в плане сраньяэто точно. при чем еще от особенностей IE до конца не избавились, IE10 ещё отчебучивает, между вебкит с мозиллой уже намечены тёрки...
> они пытаются привинтить костыли, а не решить проблему. «решить» — это выпнуть
> нафиг js и запилить что-нибудь нормальное. точнее, js оставить «как есть»,
> и добавить что-нибудь хоть на том же llvm. специально для обезьян,
> которые решили, что браузер — это новая ОС и хотят там
> какие-то «приложения». пусть llvm их aot-откомпилит, и будет «родная»
> производительность. и идиотские танцы вокруг js не нужны.Пилите. Не забудьте написать:
- какая именно из версий llvm должна стать стандартом на много лет
- как обеспечить отсутствие undefined behavior
- как быть с тем, что в llvm-коде есть команды, работающие только на одной архитектуре (см. LLVM IR is a compiler IR: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... )
- как взаимодействует код на js и llvm
- как это должно работать, если в браузере нет поддержки LLVM
> — какая именно из версий llvm должна стать стандартом на много летлюбая.
> — как обеспечить отсутствие undefined behaviorне пользоваться тем, что даёт undefined behavior.
> — как быть с тем, что в llvm-коде есть команды, работающие только
> на одной архитектуреплевать. я *нигде* не писал, что надо передавать llvm ir.
> — как взаимодействует код на js и llvm
никак. это не надо.
> — как это должно работать, если в браузере нет поддержки LLVM
никак. это не надо.
дальше я ничего пояснять не буду, потому что ты изначально ничего не понял.
> и так тоже. ребятам очень хотелось и на гениталий сесть, и рыбки
> откушать. то бишь, чтобы их костыль и в «обычном» браузере тоже
> работал. поэтому вместо внятной аннотации типов — вот такая анальная магия.
> по их задумке, «обычный» браузер просто исполнит, а специально обученый тут
> же поймёт, что x — это целое и только целое, и
> всё резко заоптимизирует.
> ну, то есть, идея сама по себе неплоха, но *такое* костыльное воплощение
> придумать — это действительно одарёнными надо быть.Придумайте лучше. Я лично не могу.
> Я лично не могу.это хорошо заметно.
кстати, надо будет в свои странички повставлять немножко подобного кода. а потом начать использовать переменную как double. или вообще как строку. пусть мегакомпиляторы порадуются. а если заглючит — бомбить тормозилловцев истерическими багрепортами: «а-а-а, вы поломали мне весь жабоскрип! быстро запилите обратно!»
Этот код просто будет выполняться как обычный JS. А в мозилле вас пошлют и будут правы.
Вот там уже как мысль далеко зашла: http://habrahabr.ru/post/174481/"Сегодня Mozilla совместно с игровой студией Epic Games выступила с инициативой создания визуально привлекательных 3D-игр, которые не должны уступать декстопным аналогам, и выполняться прямо в браузере.
Фактически идёт о том, чтобы перенести в веб опыт создания качественных, требующих высокой производительности, игровых приложений, которые должны будут выполняться обновленным движком JavaScript OdinMonkey, который недавно был включён в ночные сборки FireFox и скорость выполнения кода на Asm.js которым в 10 раз превышает аналогичный в других браузерах. Причём это всё без сторонних плагинов вроде Flash или Silverlight — чистый JavaScript."
Если asm.js приблизится к нативной производительности, то венде 100% капец, ибо игры будут работать на любой ОС без необходимости портирования - иди попробуй удержи монополию когда воздание новых ОС на произвольном железе - будет проще.
cb
Задолбали со своим JavaScript-ом, теперь недо программисты будут понтить больше чем надо.
