LINUX.ORG.RU

Компилируемый язык вместо javascript

 , ,


0

2

Помнится несколько раз читал о прожектах использования какого-нибудь компилируемого языка в качестве основы web приложений. Т.е. вырисовывается такая цепочка:

  • Пользователь зашел на какой-нить gmail;
  • Браузер качает код написаный на быстром в компиляции языке (например что-нибудь паскалеподобное).
  • Код компилируется и запускается в песочнице и собственно делает все тоже самое, что js, но быстрее и без жора памяти на каждый чих.

Подводных камней тут конечно не мало, но профиты очевидны. Существует ли в природе работоспособная модель? Я бы помацал для одной задачки.

★★★★

Последнее исправление: zloelamo (всего исправлений: 1)
Ответ на: комментарий от PolarFox

Но и интернет тоже изменился.

И что позвольте изменилось? JS+AJAX стали повсеместными. Вот я и сделал вывод, что JS та ещё гадость.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Кстати да, можно же через профайлер хромого посмотреть сколько ЦПУ и сколько памяти ест конкретная вкладка, с детализацией до переменной.

Tark ★★
()
Ответ на: комментарий от zloelamo

Я его привел потому, что он быстро компилируется

LLVM IR. В NaCl собирались сделать.

note173 ★★★★★
()
Ответ на: комментарий от zloelamo

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

PolarFox ★★★★★
()
Ответ на: комментарий от Tark

Во-первых, почему в си неявный расход памяти выше, чем у ассемблера?

Из-за лени :). Тут либо вы используете си именно как высокоуровневый язык и теряете несколько тактов то там, то тут, поскольку оптимизации компилятора не везде хороши, либо пишите на нем как на ассемблере с прямым доступом к регистрам например.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Из-за лени :). Тут либо вы используете си именно как высокоуровневый язык и теряете несколько тактов то там, то тут, поскольку оптимизации компилятора не везде хороши, либо пишите на нем как на ассемблере с прямым доступом к регистрам например.

Ага, а потом такие оптимизированные программы на 64 битах не работают, или не используют половину регистров.
И не надо говорить про то, что оптимизации компилятора не везде хороши, я не думаю, что у кого-нибудь хватит терпения вручную векторизировать циклы и выравнивать память.

Tark ★★
()

web надо делать с использованием какой-нибудь VM, вроде дотнетовской. Сразу решит много проблем:

1. Даст некоторую защиту от реверса.

2. Расширит выбор языков.

3. Меньше ресурсов будет требоваться для интерпретации/компиляции (насчёт компиляции не уверен).

kike
()
Ответ на: комментарий от zloelamo

Почем дожно быть по другому? Си или тотже паскаль ближе к железу, меньше абстрагированы, соответсвенно на одну и туже операцию будут тратить меньше.

ты про web или как? какое железо? API браузера?

Stil ★★★★★
()
Ответ на: комментарий от mopsene

Где? Пруфы в студию.

1. Открыть 10-20 фоновых вкладок с хабром (статьями) на андроиде с 768MB RAM (HTC Sensation в моем случае). Dolphin HD в качестве браузера.

2. Наслаждаться полученным эффектом.

3. Переключить внимание с телефона на что-то еще на минуту.

4. 10 минут пытаться разблокировать экран пробиваясь через жуткие тормоза, до тех пор, пока Android не решится таки прибить браузер, т.к. памяти жрет много, и уже давно не активная activity. (десять!! передаю по буквам - петр иван зинаида даниил емеля царь, даниил ольга леонид генадий ольга )

qrck ★★
()

Не ешь больше этих грибочков. JIT везде, как уже сказали. А браузер жрёт ещё и по причине кэширования всего и вся, т.к. не хочет тормозить [ещё больше]. Да и отдавать и выделять память постоянно туда-сюда тоже никакого профита нет.

Deleted
()

это уже какой-то javaassember получается

visual ★★★
()
Ответ на: комментарий от qrck

Открыть 10-20 фоновых вкладок с вебодинноль/флеш/джава-апплеты и посмотреть на тот же самый эффект.

mopsene ★★★
()
Ответ на: комментарий от PolarFox

Живее всех живых.

Какая прелесть :)

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

«Решено» поставь, сразу будет понятно :)

Deleted
()

Существует ли в природе работоспособная модель?

Morfik для Java, C#, BASIC, Object Pascal.

quickquest ★★★★★
()

Java, Adobe Flash, MS Silverlight - не знакомые слова, случаем?

EugeneBas ★★
()

Собсно Java это оно и есть

Karapuz ★★★★★
()

WebGL Создавался для 3D графики в браузере, а поскольку для нее нужно много ресурсов, то возможностей для оптимизации в ней куча.

jamy
()
Ответ на: комментарий от zloelamo

или тотже паскаль ближе к железу, меньше абстрагированы, соответсвенно на одну и туже операцию будут тратить меньше.

Разница вас может удивить: http://rghost.ru/40458003/image.png

Пример конечно неудобный для паскаля, но это не оправдывает всего двукратной разницы между ним и js.

JustGuest
()
Ответ на: комментарий от Deleted

Ок, допустим про производительность я не прав. Но неужели хорошо спроектированный компилируемый язык не был бы ко двору в вебе?

zloelamo ★★★★
() автор топика

js благодаря гуглу стал невероятно быстрым, один из быстрейших скриптовых языков, посмотри как работают node.js приложения серверные - особенно с последними версиями ноды. Смогли выжать 1кк тупых ping-pong подключений, без форканья процессов и доточки ноды (всякие там флаги при вызове передавая или еще чего). Есть реальные примеры на реально крупном проекте, но увы NDA :) Самая большая проблема в текущем вебе - DOM и CSS рендеринг (когда меняешь хоть одно css свойство, которое может передаваться по наследству приходится пересчитывать всю страничку (в лучшем случае повторяющиеся изменения туда-сюда браузер будет их кэшировать, и то не все это делают).

wwwsevolod
()
Ответ на: комментарий от zloelamo

JIT — повсеместно, бинарники только всякие NaCL в хроме. Второе не нужно, да и собирается не на клиенте.

Deleted
()
Ответ на: комментарий от wwwsevolod

А кэширование это дополнительные расходы памяти. Тоже народ возмущается. Не угодить :}

Deleted
()
Ответ на: комментарий от PolarFox

Тех веб-нубов, которые не фигачат вырвиглазный фон на свои сайты, сжигают на кострах что-ли?

Вот пример годного 1.0

gear ★★★
()
Ответ на: комментарий от wwwsevolod

Самая большая проблема в текущем вебе - DOM и CSS рендеринг.

Ок, объясните динозавру из 90х. Неужели нельзя сделать менее ресурсоемкую модель, если причины в ней?

zloelamo ★★★★
() автор топика

Очередной быдлокодер который свои ошибки вешает на ЯП.
Понапишут какой нибудь поиск одного и того же элемента по DOM через jquery в 25 местах скрипта, вместо того чтобы найти один раз и сохранить в переменной, а потом кричат, что js говно и из за него у них сайт 5 мин прогружается.

TDrive ★★★★★
()
Ответ на: комментарий от wwwsevolod

Смогли выжать 1кк тупых ping-pong подключений,
1кк тупых ping-pong
тупых

Это можно реализовать на абсолютно любом языке и платформе.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Врятли, это ж манипуляции с текстом и деревьями. Модель нормальная, такое всегда медленно и всегда будет узким местом.

Kalashnikov ★★★
()
Ответ на: комментарий от zloelamo

Я бы врятли ругал JS, если бы я на нем писал.

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

ОК, у меня больше нет вопросов.

TDrive ★★★★★
()

lua с jit-компиляцией же! Но браузеры умеют только js, увы.

quantum-troll ★★★★★
()
Ответ на: комментарий от PolarFox

Вот человек изучил вопрос, почему код на js оказался быстрее аналогичного кода на java.

4.2

X*X*X*X*X*X конечно быстрее, чем pow(X, 7.000); И что? В каком ЯП иначе? А то, что JS обожает целые числа (как php) - для меня лично не новость. Это иногда (как здесь) хорошо, но чаще ведёт к совершенно неожиданным ошибкам (когда строку ВНЕЗАПНО интерпретатор преобразовал в целый ноль).

drBatty ★★
()
Ответ на: комментарий от Tark

Почему картинка в памяти занимает мегабайт?

на хорошем мониторе будет намного больше. ИЧСХ, это совсем не зависит от размера картинки в пикселях.

drBatty ★★
()
Ответ на: комментарий от zloelamo

Я и так его прочитал прежде чем писать.
Вкратце:
- ты не осилил найти в гугле названия языков которые используются для веба на стороне клиента и полез с глупыми вопросами на ЛОР, в полной уверенности, что js тебе не подойдет потому что он тормозит и любой другой ЯП априори тормозит меньше чем js.

- тебе начинают объяснять что ты совершенно не прав и занимаешься ерундой.

- по пути выясняется, что на самом деле ты даже не знаешь js и по этому не можешь сформулировать, что именно тебя в нем не устраивает. + Приводишь нелепые сравнения с Си и Асмом, судя по которым в этом вопросе ты тоже не компетентен.

- Я обоснованно называю тебя очередным быдлокодером.

- Занавес

TDrive ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.