LINUX.ORG.RU

хромиум на среднем i7 в 8 потоков собирается около получаса, соответственно v8 собирается менее получаса.

а почему этот процесс должен быть муторный? у меня вообще всё из сорцов собирается

anonymous ()

Сколько времени собирается javascript v8?

Node.js-9.11.2 (с v8 в составе) собирается за 4.0 SBU (using parallelism=4). Вот и оценивай, сколько это у тебя.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Ммм, понял. Не так уж страшно. Но и не так уж весело. (я так понимаю, что при однопроцессорной сборке 1SBU - это порядка 3 минут).

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

зависит от твоего железа

When completing LFS, people commonly want to know how long it will take to compile each package. Unfortunately, build times are very much dependent on the power and configuration of the system the packages are being compiled on. Some packages may take a few minutes on a powerful workstation, but hours on an aged laptop. While it cannot be said how long a specific build will take on any device, we can normalize how long each package build takes comparatively to each other. This normalization is done using Stand Build Units, or SBUs.

http://ryan.himmelwright.net/post/lfs-sbus-and-binutils/

anonymous ()
Ответ на: комментарий от monk

Я посмотрел в гугле примерно на своё железо.

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

Мне нужно, чтобы JS компилировался в машкод и v8 это делает. Делает ли это duktape? Судя по его сайту - нет.

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

JS компилировался в машкод и v8 это делает

Неее. Оно - это не машкод, ты чо? Jit это не совсем машкод, это так, ерунда. Маркетинг + какие-то там оптимизации. Оно не может быть машкодом из-за своей динамической сущности. Как ты будешь eval там делать, если везде машкод?

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

Спорить не будем. Почитай, как работает v8 и потом напиши сюда свои впечатления. Моё мнение - v8 тормозной из-за чрезмерной гибкости объектов, а не из-за дефектов компилятора. Компилятор там в машкод без всяких оговорок. Сделай хоть AOT - быстрее всё равно не будет.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

Пробовал, v8 на Travis CI не пролезает в бесплатные 50 мин, причем хорошо так не пролезает - где то половина успевала собираться за это время. Сборка оче муторная - фактически v8 живет в дереве Chromium и его сборка - это часть общей сборки. Все тулзы себя качают из интернета, шаг в сторону от этого процесса - и хрен соберешь.

Под онтоп - есть JavaScriptCore - всюду опакечен и отличное C API имеет, если нужен просто быстрый ES6 на онтопе, то это оптимальный вариант. Если можно ES5 и небыстрый, то Duktape удобнее (и собирается где угодно).

anonymous ()
Ответ на: комментарий от den73

Я почитал. Вот это ты имеешь ввиду? http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/
Там куча всяких оптимизаций, хеш таблиц, таблиц для объектов и пр.примочек, которые ускоряют работу js, например, когда строки сравниваются не побайтово, а по хешу. Или для объекта есть таблица со смещениями и когда ты делаешь p.y он ищет не по хэшу «y» а сразу по смещению. А p - это уже какой-то там вн.указатель на класс. Но крутится весь код всё равно виртуальной машиной, а как может быть по-другому?

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

Моё мнение - v8 тормозной

Тебе не нужен быстрый js. Серьёзно. Он не про это. Если что-то надо делать быстро - считай на си, приделывай вызовы в js. Js - это всякие извраты с obj[function](args...); //или obj.invoke

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

Ты дал ссылку на огромный текст, от 2013 года. С тех пор прошло время. Вот тебе данные от 2017-го.

https://habr.com/company/ruvds/blog/337460/

Для того, чтобы добиться высокой скорости выполнения программ, V8 транслирует JS-код в более эффективный машинный код, не используя интерпретатор. Движок компилирует JavaScript-код в машинные инструкции в ходе исполнения программы, реализуя механизм динамической компиляции, как и многие современные JavaScript-движки, например, SpiderMonkey и Rhino (Mozilla). Основное различие заключается в том, что V8 не использует при исполнении JS-программ байт-код или любой промежуточный код.

Почему же я должен работать за тебя? (а что мне нужно, я сам решу, спасибо за заботу :) )

И ещё, к слову: Javascript так научился делать в 2017, а Common Lisp так работал в 1991 :) Но всё равно JS пока отстаёт от CL по скорости ЛОЛ.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

Вот тебе данные от 2017-го.

Так это перевод первой статьи. Да и нет там полной компиляции и не будет. Чтобы была нормальная компиляция надо знать заранее где у тебя какие структуры. В js это нельзя знать и не нужно. Там не компиляция на лету, а какие-то куски js кода оптимизируются jit в куски написанного заранее быдлокода. На модном фреймворке это работать не будет. Да даже на не модном всё будет работать с 3x оверхедом в лучшем случае.

Движок компилирует JavaScript-код в машинные инструкции в ходе исполнения программы
Но всё равно JS пока отстаёт от CL по скорости ЛОЛ.

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

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

Так это перевод первой статьи.

Неправда, они отличаются. Но не суть. Ты и ту статью плохо прочитал.

It compiles JavaScript code into machine code at execution by implementing a JIT (Just-In-Time) compiler like a lot of modern JavaScript engines such as SpiderMonkey or Rhino (Mozilla) are doing. The main difference with V8 is that it doesn’t produce bytecode or any intermediate code.

Хотя меня озадачивает статья https://habr.com/company/ruvds/blog/336294/ , в которой описан якобы байт-код. Однако вот что написано в документации:

https://github.com/v8/v8/wiki/Design-Elements#dynamic-machine-code-generation

Как бы то ни было. В SBCL (и многих других лиспах) есть И интерпретатор, И компилятор в маш код. Можешь по своему выбору использовать то или другое. Так что неважно, как сделано в v8 - компилятор в машкод там есть, что бы ты про это не думал.

Для чего им интерпретатор - не знаю, но области применения у него в принципе есть.

Судя по всему, https://tproger.ru/news/google-tool-reduces-js-size/, они заменили интерпретатором свой первый (быстрый, но глупый) компилятор, с целью сокращения объёма кода.

То есть в итоге ты отчасти прав, разница лишь в том, как ты воспринимаешь JIT. Я на самом деле не знаю, как устроен там JIT, я надеялся, что там нормальный компилятор, как в CL. Думаю, это так и есть, но дальше в это пока не буду лезть, т.к. интерес отпал.

CL, вроде, вообще интерпретировался в код на си полностью

Вообще говоря, нет, и плюс к тому вместо «интерпретировался» надо было поставить какое-нибудь другое слово, например, транспилировался - так вообще безграмотная фраза у тебя получалась.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

я надеялся, что там нормальный компилятор, как в CL. Думаю, это так и есть, но дальше в это пока не буду лезть, т.к. интерес отпал.

Ну если бы там был норм.компилятор, им бы пришлось туда тащить свой маленький gcc и движок должен знать кучу платформ. Зачем это надо? Можно просто написать какие-то часто используемые функции, передать им туда указателей и дёргать их по очереди, вместо того, чтобы интерпретировать js код. Я тоже не знаю наверняка как там, но думаю, что так. Экспертов бы по js, но их что-то почти всех залошили.

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

Ну если бы там был норм.компилятор,

Он там есть, называется Turbofan. https://medium.com/devschacht/v8-behind-the-scenes-7ff45a7134fd

Там даже картиночка есть :) Дисклеймер - всю статью не читал. Но там есть слова Register allocator, code generator, что есть признаки компилятора.

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

Собственно, лисп в своё время не нравился, потому что был очень большим. Но если сравнить CL (с нормальным компилятором на борту) и современный браузер, то браузер гораздо больше.

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

Пробежался, так и не понял, что там за компилятор и как он работает.

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

что есть признаки компилятора.

Ты удивишься, но аббревиатура JIT означает лишь Just In Time. Чтобы какой-то смысл был, к ней добавляют compiler. Так что «наличие jit» это «наличие jit компилятора». Ну и конечно же там должен быть register allocator. А иначе как вообще?

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от den73

Да они делают всякую херню на этом своём жс'е, вот и получается целая операционка воокруг браузера.

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

Ты знаешь, как он компилирует у них на ходу?

Не знаю.

Сам себе переполнение буфера делает что-ли?

Зачем? mmap + mprotect дают возможность сгенерировать код в памяти, а потом его запустить. Даже в ситуации, когда используется W^X, можно сначала генерировать код, потом убрать возможность записи, добавить возможность выполнения. И прыгнуть туда.

i-rinat ★★★★★ ()
Ответ на: комментарий от crutch_master

Ты что ли пытаешься JIT сделать? Если так, то вряд ли стоит начинать с копирования v8. Они там всё-таки до предела производительность выжимают. Возможно, стоит взять какой-нибудь готовый инструмент, вроде LLVM.

i-rinat ★★★★★ ()
Ответ на: комментарий от den73

Стандартное окружение браузера умеет на порядки больше, чем стандартное окружение CL, поэтому сравнивать это не правильно.

anonymous ()
Ответ на: комментарий от i-rinat

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

crutch_master ★★★★★ ()
Ответ на: комментарий от i-rinat

Не, мне просто интересно понять, как оно у них работает. На динамическом языке, к тому же.

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

Я плохо понимаю, что ты пытаешься сказать. Но там в коде действительно есть отдельные кодогенераторы под ia32, x64, ppc, mips, mips64, arm, arm64. Ну или были. У меня на компе версия от 2015 года. Новую смотреть лень.

i-rinat ★★★★★ ()
Ответ на: комментарий от den73

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

Его основное отличие от других JS движков, в том что у него одновременно есть и стабильное C API и автивно поддерживаемые пакеты во всех основных дистрибутивах. У V8 - ни C API ни пакетов, у SpiderMonkey (Mozilla) есть пакеты но нет C API, у ChakraCore (Microsoft) есть C API но нет пакетов (он clang-only на онтопике и никто не хочет его опакечивать).

Пакет JSC в бубунте:

libjavascriptcoregtk-4.0

Основное C API: #include <JavaScriptCore/JavaScript.h>

Еще с недавнего времени есть Glib API: https://webkitgtk.org/reference/jsc-glib/unstable/index.html

Ссылки:

https://en.wikipedia.org/wiki/WebKit#JavaScriptCore https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

anonymous ()
Ответ на: комментарий от crutch_master

Ну наконец-то! Когда я тебе это 10 раз сказал, ты мне не поверил :)

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

Компилирует, все как во всех больших JS движках, многоуровневый JIT - сначала быстренько в машкод компиляет,

Что-то ты неправду, по-моему, говоришь. Это вот что?. Сдаётся мне, что он сначала компилирует в байт-код.

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

Спасибо! На самом деле, это не так интересно. VLIW архитектура - это, на мой взгляд, попадалово, мне жаль эльбрусовцев, но ничего сделать тут нельзя.

И сам JS не особо интересен. Сначала сделали каку, а потом пытаются от этого спастись. Не вникая в детали, почти уверен, что вокруг этого и крутятся их оптимизации. Вместо этого надо просто сделать нормальный ЯП, который будет не так враждебен скорости, и пользоваться им :)

По сути, от идее что-либо делать с движками JS я уже отказался - в JS всё изначально не так, как надо.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от missxu

Не. Я просто знаю, как надо. Я на протяжении более чем 10 лет наблюдаю. как «мейнстрим» языки мигрируют в направлении Common Lisp. Но раз за разом промахиваются :)

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

Сверхчеловеком быть не нужно. Просто узнай что-нибудь про Common Lisp и обрати внимание на то, когда он появился. В нём предсказано будущее. Но не потому, что его делали пророки. А потому, что умные люди его вовремя закопали, как клад. Потом стали по одной монетке откапывать и в розницу продавать. На данный момент уже почти всё откопали и продали, но кое-что ещё осталось. Например, в JS ещё нет аннотаций типов. А в CL они уже были в 1990-м году. В Питон их кое-как криво впилили.

http://clhs.lisp.se/Body/d_type.htm

Нет макросов, а в CL они уже были. В С++ макросы только собираются добавить.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

Ну есть ещё некоторые вещи, которые пока не спешат откапывать. Smalltalk в JS тоже в каком-то пародийном виде есть. А Prolog даже в намёках отсутствует.

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

В нём предсказано будущее

обрати внимание на то, когда он появился

держи в курсе

если не знал, люди пользуются тем что актуально и современно для промежутка минус 5лет, и не дрочат на старье

чем ЛОР так притягивает дрочеров на старый мусор(во всех областях), тут медом чтоли намазано или что

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