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

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

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

как-то так https://github.com/Microsoft/v8-docker-buildscript

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

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

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

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

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/

1SBU = время компиляции bash или binutils.

v8 не знаю, duktape собирается за секунды.

Спасибо, но мне нужно в машкод.

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

Собирается в машкод. Движок js. НЕ js код. Сам движок. С js. В машкод.

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

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

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

Учи матчасть.

Да я знаю, что там jit, но jit это не тоже самое, что машкод.

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

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

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

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

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

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

Ты дал ссылку на огромный текст, от 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 по скорости ЛОЛ.

Спасибо! JavaScriptCore интерпретирует или компилирует в машкод?

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

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

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

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

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

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

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, вроде, вообще интерпретировался в код на си полностью

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

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

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

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

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

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

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

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

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

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

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

Ты знаешь, как он компилирует у них на ходу? Сам себе переполнение буфера делает что-ли?

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

Не знаю.

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

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

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

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

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

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

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

Ну, понятно. Таки я был не прав и он пилит под что-то под проц. по ходу работы.

Компилирует, все как во всех больших 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/

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

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

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

Тут как раз была статейка

https://habr.com/company/jugru/blog/419155/

https://hsto.org/getpro/habr/post_images/c91/301/274/c9130127464ac436103ab6e8...

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

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

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

пол часа-час на новых i3-i7, два-три часа на старом core2

Мне нужно, чтобы JS компилировался в машкод и v8 это делает.

О, да вас покусали маркетологи, прививку сделайте

Это чисто сам v8? Ого-го.

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

Не. Я просто знаю, как надо.

сверхчеловек на лоре

никогда такого не было, и вот опять

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

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

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

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

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

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

держи в курсе

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

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

Ок, ты имеешь полное право оставаться невеждой :)