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.
Неее. Оно - это не машкод, ты чо? Jit это не совсем машкод, это так, ерунда. Маркетинг + какие-то там оптимизации. Оно не может быть машкодом из-за своей динамической сущности. Как ты будешь eval там делать, если везде машкод?
Спорить не будем. Почитай, как работает 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 - это уже какой-то там вн.указатель на класс. Но крутится весь код всё равно виртуальной машиной, а как может быть по-другому?
Тебе не нужен быстрый js. Серьёзно. Он не про это. Если что-то надо делать быстро - считай на си, приделывай вызовы в js. Js - это всякие извраты с obj[function](args...); //или obj.invoke
Для того, чтобы добиться высокой скорости выполнения программ, V8 транслирует JS-код в более эффективный машинный код, не используя интерпретатор. Движок компилирует JavaScript-код в машинные инструкции в ходе исполнения программы, реализуя механизм динамической компиляции, как и многие современные JavaScript-движки, например, SpiderMonkey и Rhino (Mozilla). Основное различие заключается в том, что V8 не использует при исполнении JS-программ байт-код или любой промежуточный код.
Почему же я должен работать за тебя? (а что мне нужно, я сам решу, спасибо за заботу :) )
И ещё, к слову: Javascript так научился делать в 2017, а Common Lisp так работал в 1991 :) Но всё равно JS пока отстаёт от CL по скорости ЛОЛ.
Так это перевод первой статьи. Да и нет там полной компиляции и не будет. Чтобы была нормальная компиляция надо знать заранее где у тебя какие структуры. В 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.
Как бы то ни было. В SBCL (и многих других лиспах) есть И интерпретатор, И компилятор в маш код. Можешь по своему выбору использовать то или другое. Так что неважно, как сделано в v8 - компилятор в машкод там есть, что бы ты про это не думал.
Для чего им интерпретатор - не знаю, но области применения у него в принципе есть.
То есть в итоге ты отчасти прав, разница лишь в том, как ты воспринимаешь JIT. Я на самом деле не знаю, как устроен там JIT, я надеялся, что там нормальный компилятор, как в CL. Думаю, это так и есть, но дальше в это пока не буду лезть, т.к. интерес отпал.
CL, вроде, вообще интерпретировался в код на си полностью
Вообще говоря, нет, и плюс к тому вместо «интерпретировался» надо было поставить какое-нибудь другое слово, например, транспилировался - так вообще безграмотная фраза у тебя получалась.
я надеялся, что там нормальный компилятор, как в CL. Думаю, это так и есть, но дальше в это пока не буду лезть, т.к. интерес отпал.
Ну если бы там был норм.компилятор, им бы пришлось туда тащить свой маленький gcc и движок должен знать кучу платформ. Зачем это надо? Можно просто написать какие-то часто используемые функции, передать им туда указателей и дёргать их по очереди, вместо того, чтобы интерпретировать js код. Я тоже не знаю наверняка как там, но думаю, что так. Экспертов бы по js, но их что-то почти всех залошили.
Собственно, лисп в своё время не нравился, потому что был очень большим. Но если сравнить CL (с нормальным компилятором на борту) и современный браузер, то браузер гораздо больше.
Ты удивишься, но аббревиатура JIT означает лишь Just In Time. Чтобы какой-то смысл был, к ней добавляют compiler. Так что «наличие jit» это «наличие jit компилятора». Ну и конечно же там должен быть register allocator. А иначе как вообще?
Зачем? mmap + mprotect дают возможность сгенерировать код в памяти, а потом его запустить. Даже в ситуации, когда используется W^X, можно сначала генерировать код, потом убрать возможность записи, добавить возможность выполнения. И прыгнуть туда.
Ты что ли пытаешься JIT сделать? Если так, то вряд ли стоит начинать с копирования v8. Они там всё-таки до предела производительность выжимают. Возможно, стоит взять какой-нибудь готовый инструмент, вроде LLVM.
Но для этого, я понимаю, на борту нужен какой-то 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>
Спасибо! На самом деле, это не так интересно. VLIW архитектура - это, на мой взгляд, попадалово, мне жаль эльбрусовцев, но ничего сделать тут нельзя.
И сам JS не особо интересен. Сначала сделали каку, а потом пытаются от этого спастись. Не вникая в детали, почти уверен, что вокруг этого и крутятся их оптимизации. Вместо этого надо просто сделать нормальный ЯП, который будет не так враждебен скорости, и пользоваться им :)
По сути, от идее что-либо делать с движками JS я уже отказался - в JS всё изначально не так, как надо.
Не. Я просто знаю, как надо. Я на протяжении более чем 10 лет наблюдаю. как «мейнстрим» языки мигрируют в направлении Common Lisp. Но раз за разом промахиваются :)
Сверхчеловеком быть не нужно. Просто узнай что-нибудь про Common Lisp и обрати внимание на то, когда он появился. В нём предсказано будущее. Но не потому, что его делали пророки. А потому, что умные люди его вовремя закопали, как клад. Потом стали по одной монетке откапывать и в розницу продавать. На данный момент уже почти всё откопали и продали, но кое-что ещё осталось. Например, в JS ещё нет аннотаций типов. А в CL они уже были в 1990-м году. В Питон их кое-как криво впилили.
Ну есть ещё некоторые вещи, которые пока не спешат откапывать. Smalltalk в JS тоже в каком-то пародийном виде есть. А Prolog даже в намёках отсутствует.