Previous Entry Share Next Entry
2016-01

made my day

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

> ["10","10","10"].map(parseInt)
[10, NaN, 2]


This entry was originally posted at http://wizzard.dreamwidth.org/368320.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
gds April 21st, 2014
а чем это достигается?

jakobz April 21st, 2014
map отдает порядковый номер вторым аргументом, а parseInt вторым аргументом принимает основание системы счисления в которой парсить

enternet April 21st, 2014
Причем, блин, это не переопределяется.
>["10","10","10"].map(parseInt, 10)
[10, NaN, 2]

jakobz April 22nd, 2014
Это ты map-у второй параметр передаешь, который станет this для parseInt, которому на this пофигу. Там надо сделать частичное применение parseInt ко второму его аргументу. Хелперов для такого в чистом JS нету - bind только по порядку умеет.

Впрочем, parseInt по причине его работоспособности на всяких "123diebitch", юзать все равно не рекомендуют. Лучше юзать +str, или Number(str).

gds April 21st, 2014
> map отдает порядковый номер вторым аргументом

вот этого я не знал. Наверное, к счастью.
Теперь почти всё понял.
Разве что непонятно, почему при основании системы счисления 0 оно что-то выдаёт вообще. Но это уже мелочи, в самом деле. Не из-за них следует придираться к js.

jakobz April 21st, 2014
>Разве что непонятно, почему при основании системы счисления 0 оно что-то выдаёт вообще
Ну falsy же. На null и false ей тоже пофиг.

Оно даже такую ржаку пережевывает: parseInt("123456789", "0xF").

juan_gandhi April 21st, 2014
... дайте две... это больные люди, и Айх с его антипидорасами, и Крокфорд с его гонадами, и вообще.

wizzard0 April 21st, 2014
Посмотри весь talk, он хороший и серьезный.

juan_gandhi April 21st, 2014
Я смотрел уже. Хороший.

victorgr April 21st, 2014
Ну да, нужно понимать как работает map в JS.


["10","10","10"].map(parseInt.bind(this, 10));


- этот код делает всё как задумано автором.

jakobz April 21st, 2014
Ты ж прибиндил что надо парсить, а не систему счисления.

["0","1","2"].map(parseInt.bind(this, 10));
[10, NaN, 2]

victorgr April 22nd, 2014
Точно, ошибся.

Кстати, а проще чем

["0", "1", "2"].map(function(el) { return parseInt(el, 10); } )


никак не сделать?

jakobz April 22nd, 2014
На голом JS - не знаю способов. Во всяких либах бывает более гибкий вариант bind-а.

jakobz April 21st, 2014
Можно map(Number), но немного это WTF-но.

wizzard0 April 21st, 2014
Почему? Отмапить на множество чисел, клево же

jakobz April 22nd, 2014
Number - это вроде как конструктор. Непонятно что оно без new сработает, и при этом сконвертирует строку в не-box-нутое число, в отличии от new Number("100500")

Кстати оно это правильнее parseInt делает - не жует всякие "100500whatever".

enternet April 22nd, 2014
Ого. Спасибо.

(Deleted comment)
nponeccop April 22nd, 2014
> Оверхед на IPC между виртуальными машинами и ядром который по
> факту почти ничем не будет отличаться от тех же системных вызовов

ололо

(Deleted comment)
wizzard0 April 22nd, 2014
Ты помнишь, что долгое время у vmware эмуляция привилегированных инструкций через binary translation была быстрее, чем трапы?

Я, правда, не уверен на 100%, что аналогия переносима на kernel-user transition.

nponeccop April 22nd, 2014
> Я, правда, не уверен на 100%, что аналогия
> переносима на kernel-user transition.

Всё украдено до нас. В докладе была ссылка на статью - её прочитайте, и с ней спорьте.

Помимо этого, чтобы не говорить чушь вроде "перекладывания аргументов со стека на стек" рекомендую ознакомиться с мат. частью. Собственно, есть отличный Intel® 64 and IA-32 Architectures Developer's Manual.

Также здесь ссылаются на чуть меньшее кол-во букв by Geoff Chappell: http://stackoverflow.com/a/15214110/805266 , и на конкретные страницы ADM, где рассматривается оверхед.


Вопрос только, где? Я не нашёл. Меня интересует процесс переключения MMU, в частности, изменение CR3 на х86/х64

Edited at 2014-04-22 08:03 pm (UTC)

anonim_legion April 22nd, 2014
>мокрые фантазии скриптохипстоты

Прорыв двача в ЖЖ, все в укрытие.

nponeccop April 22nd, 2014
> От оверхеда MMU и таблиц трансляций это
> не поможет избавится ну никак

будет всего один процесс в ring 0, без пейджинга, т.е. фактически MMU будет отключен.

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

(Deleted comment)
nponeccop April 23rd, 2014
> в реальной жизни для компьютера общего назначения такое не подойдет

Как я понял, предлагается именно это. Заодно предлагается жить без memory-mapped files, copy on write, overcommit, NX и других прелестей, построенных на виртуальной памяти.

> то это невозможно бай дизайн

Вы говорите про количество уровней в иерархии, а я говорю про количество иерархий:

(наш любимый том 3А, раздел 2.1.5)

To use this paging mechanism, a linear address is broken into parts. The parts provide separate offsets into the paging structures and the page frame. A system can have a single hierarchy of paging structures or several. For example, each task can have its own hierarchy.

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

Edited at 2014-04-23 07:57 pm (UTC)

(Deleted comment)
nponeccop April 23rd, 2014
> Если JS выкинуть (я считаю, его сюда вообще не
> в тему приплели) и исполнять непосредственно байт-код LLVM

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

То есть, надо делать какой-то LLVM-подобный, но безопасный байткод. Что собственно и сделали в Microsoft Singularity, маме всех идей ускорения через отказ от аппаратной изоляции.

Мысль статьи в том, что из-за невероятного дебилизма и неизбежности JS в ускорение его виртуальной машины было вложено уйму человеколет, т.е. с нуля разработать и реализовать аналог просто нет ни у кого средств, а asm.js здесь рядом.

Почему не использовать другие зрелые VM (которых как я понимаю всего одна JVM) - потому что они более тяжеловесные, чем JS VM, об этом тоже упоминается в докладе.

mega_mosk April 23rd, 2014
Я просто изумлен разнообразием вариантов поесть говна в javascript, причем by design.

nponeccop April 23rd, 2014
Всё же не сравнить с сишечкой или крестиками. Ну ещё есть перл из страшилок.

_winnie May 8th, 2014
В сишечке получаем хотя бы кучу плюшек от статической типизации и близости к железу ( в JS даже битовая арифметика тормозит, ибо эмулируется через double ).

А тут единственное из-за чего терпим - это присутствие во всех браузерах.

nponeccop May 8th, 2014
В сишечке нет memory safety, а её близость к современному железу сильно преувеличена. Хорошая производительность там не от близости к железу, а от затраченных на компилятор человекочасов и ручного управления памятью.

Но я говорил не о сишечке, а о крестиках.

JS - это всё динамический функциональный Self, за это мы его любим.

Не любим за идиотизмы в мелочах. В крестиках та же штука. Ну а Перл тут вне конкуренции.

  • 1
?

Log in

No account? Create an account