html5 hype

[wizzard0]

Интелу надо сделать процессор, оптимизированный для Javascript.

Или сделать свой JS-движок, вложив туда наследие от своего С++-компилятора ;)

Тогда x86 начнут снова любить ;)

This entry was originally posted at http://wizzard.dreamwidth.org/306125.html. It has

Comments

[nicka_startcev]

аппаратный сборщик мусора и 2х..5х к памяти?

бугога.

[wizzard0]

в каждом браузере УЖЕ есть сборщик мусора и 2х..5х к памяти, мы ничего не теряем

а приобрести можем оптимизации, которые нынче упираются в отсутствие поддержки железом (read barriers, stm, и так далее)

[nicka_startcev]

> и 2х..5х к памяти, мы ничего не теряем

таки теряем. Всреднем, если мы уже согласились на автоматический а не ручной, на волшебноавтоматический меморименеджмент, то нам сразу надо в 2-5 раз больше памяти. Но сейчас это не проблема, да. хоть 8 гб, хоть 32 или 128, это фигня, пипл хавает.

[wizzard0]

я повторю, мы УЖЕ их потеряли, понимаешь?

[nicka_startcev]

таки да. Как только мы зааутсорсили меморименеджмент, так сразу нам надо 2х-4х памяти.

[wizzard0]

а если мы не аутсорсим мемори-менеджмент, то нам нужен proof-carrying assembler, который может сказать браузеру, что вот этот блоб менеджит память правильно. вот к чему я собственно веду.

[nicka_startcev]

>а если мы не аутсорсим мемори-менеджмент, то

если мы руками распределяем память, то у нас ряд других граблей, да. У нас не жаба и не жабоскрипт, а приземленный маллок/фри и производные от него нью/делит.

Много ручных движений, но надо вдвое-впятеро меньше памяти.

[wizzard0]

пофиг на ручные или автоматические движения. c эксплоитами в твою память от соседнего куска кода ты что делать собираешься?

[nicka_startcev]

не. не асилил.

но я вижу альтернативы

а) надо 1х памяти и си/с++, память будем руками распределять
б) надо 2х-4х памяти, можно не париться и пользовать автораспределение памяти как в жабе-додиезе.

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

Во всяких яфонах-андроидах памяти мало (до 4 гб) и по этим граблям приходится ходить плотно и неприятно. 10-100гб памяти в яфонах пока что нет, к сожалению и приходится руками ходить по граблям и руками делать то, что типа-должны сделать меморименеджменты.

[wizzard0]

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

1. ручное управление памятью экономит память 3х.
2. ручное управление памятью замедляет разработку 2х.
4. крупные блобы данных (текстуры, 3д модели, скачиваемые файлы, etc) все равно все менеджат руками и точечно
5. закон мура дает нам озу 2х в 2 года.
6. процент крупных блобов в памяти обычно 90%.

итого, вот у нас сферический девайс с 2 гб озу, в нем у приложения 100 мб памяти в управляемом хипе, гигабайт скажем ресурсов, еще 1 гб отьедает говноОС.

что ты вообще такое пишешь, что тебе ценно выюзать не 100 а 25 мб, при том что на рынке разброс суммарной памяти на девайсе от 256 мб до 2 гб?

юзкейс только один - покрыть ВСЕ девайсы на рынке при разработке в КОРОТКИЙ (3 месяца...1 год) срок. больше не вижу.

edit: а, есть еще второй юзкейс. миллионная партия эмбеддед девайсов, сэкономить $5 на чипе окупит $500000 доп затрат на разработку.

[nicka_startcev]

не. не асилил. Вот я всасываю с ёбкамеры кадр (4к х 4к точек х 32 бит), всасываю второй, пятый кадр.. итого имею порядка гб адресного пространства. А потом приходит сборщик мусора и программа встает раком. Тут я думаю и начинаю руками распределять память. Итого, автоменеджмент памяти идет лесом.

итого, при 32-битной архитектуре, 1-4г рам мне надо руками всё менеджерить.

ну, или, при гигабайтной картинке я хочу делать слайдшоу. у меня в память влезает примерно 4 картинки. А как только сожрано примерно 25-50% памяти, автосборка мусора встает раком и всё тормозит. В общем, на 32-битной архитектуре всё вполне впритык, а яфоны, андроиды, винмобайлы - они 32бит, а 64 бит в мобайлах еще нету и тут мы снаскоку упираемся в то, что память надо руками распределять.

Итого, имеем что х86 или амд32/винтел32 или еще какая 32-36 битная архитектура приводит к острой попоболи.

[wizzard0]

приложение опиши, короче.

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

[nicka_startcev]

всосал картинку, обработал, выбросил.
Всосал вторую, обработал, выбросил.
И так 50 раз в секунду.

Если адресного пространства хватает примерно на 4 картинки, то при обработке 2 картинок будут тормоза и застревания. (для кошерной работы неявного меморименеджмента надо порядка 4х памяти)

Итого, или надо больше чем 32 бит, или надо явно руками распределять память.

[jakobz]

>всосал картинку, обработал, выбросил.
Всосал вторую, обработал, выбросил.

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

Короче переходом в ручной режим ровно в одном месте.

[wizzard0]

именно!

[nicka_startcev]

вот-вот. :)
Вместо теплого и лампового автоматического меморименеджмента приходится делать практически то, что было бы без всех этих автоматических менеджментов.