Правильно ли я понимаю, что в JavaScript есть многопоточность,

но wasm обязательно придёт в production

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

Тем, что он как питон, только хуже. Стандартная библиотека - говно.

Но там нет стандартной библиотеки.

В репах тонны мусора, npm тормозит, node_modules жрёт иноды.

Но это проблема ноды.

Тридцать три разных версии язычка

Не больше, чем версий плюсов.

Так нафига его тащить из браузера?

Встраивать легко, например. Движки есть маленькие, жрут не много.

Всегда забавляют подобные темы.

Кто нибудь упирался в проблему многопоточности python так, что приходилось перелезать на js ?

Если да, то можно посмотреть на замеры скорости и тестовый код ?

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

ну дык всё - не могут больше ускорить джаваскрипт. google даже немного разуплотнил свой многоступенчатый V8, ибо накладные расходы оптимизатора стали слишком высоки.

Но там нет стандартной библиотеки.

Да, там есть пародия на неё.

Но это проблема ноды.

Ну ты даёшь! Откуда у неё проблемы? Она же - программа. Это будет твоя проблема, когда ты захочешь использовать чужие либы.

Не больше, чем версий плюсов.

Кому и кобыла - невеста.

Встраивать легко, например. Движки есть маленькие, жрут не много.

Ну может быть, в полкит вроде встроили.

ну дык всё - не могут больше ускорить джаваскрипт. google даже немного разуплотнил свой многоступенчатый V8, ибо накладные расходы оптимизатора стали слишком высоки.

JS https://danilw.github.io/cputests/js/render_mini.html

wasm https://danilw.github.io/cputests/wasm/render_mini/render_mini.html

что еще расскажешь про оптимизации джаваскрипта(которые работают на 10 строчных хеловордах)

забыл сказать в chrome(его движке) в 2018 в последнем обновлении

так

и

не реализовали лямбды(они работают в 20 раз медленнее чем в файрфоксе) тестик под это я тоже писал

есть, в теории...

в firefox 0 fps против 3 fps

я хз что тут нужно рассказывать

а в chromium 0 против 4

а я думал у chromium более тормознутый wasm

а я думал у chromium более тормознутый wasm

это один из тестиков, вот с лямбдой

wasm https://danilw.github.io/cputests/wasm/terrain/terrain.html
js https://danilw.github.io/cputests/js/terrain.html

сейчас отставание хрома всего в 2-5 раз от файрфока, после выхода 69 версии, до этого было 10-20 раз

Как будто что-то плохое. Поднял GIL и вперед.

JS https://danilw.github.io/cputests/js/render_mini.html

Смотри-ка. https://codepen.io/pen/PdBygr
Может дело все же в руках?

Смотри-ка. https://codepen.io/pen/PdBygr

я так понял ты переместил все в «одну область видимости» и насувал типов? применив какойто автматический оптимизатор?

так утверждение остается на месте

оптимизации джаваскрипта(которые работают на 10 строчных хеловордах)

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

Никакой автоматики

земля тебе пухом осилишь это? https://danilw.github.io/cputests/js/render/render.html

Надо знать язык под который пишешь

я знаю почему он тормозит-тот код что написан не компилируеся браузером, твой код компилируется
писать «скриптовый код который может компилироваться»-это рак скриптового языка(компилятора), как ни посмотри

А если это результат автогенерацри у тебя, то тем более, куда ты лежишь с такими бенчмарками.

это полуручная конверция GLSL рейтрейсеров на Си, и с Си на javascript

при том что java скопипащенный javascript код прекрасно обрабатывает https://github.com/danilw/cputests/tree/master/java

такшо я лезу туда куда надо с корректными бенчмарками(по моему скромному мнению конечно)

Я тебе ещё раз говорю, вся ключевая оптимизация в том, что иы на каждый инчоанс Vec создаешь ещё с десяток объектов - его методов. Новых! Каждый раз. По шестьдесят миллионов раз за итерацию. Вместо шести. В сишном коде ты этого чего-тоине делаешь. Ровно как рендеришь иы в сищном коде в сдловский буфер, а не конвертишь на каждый пиксель числа в строки. У тебя не эквивалентные коды. Более того, никтов здравом уме не написал бы такого. Иааое мог сделать либо очень тупой транслятор, либо очень тупой программист, не знающий языка.

Вынеси из конструктора в своём коде инициализации методов и ты получишь 2х тысячное ускорение своего кода за раз. Это чёрт возьми азы.

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

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

Ты или сравнивай эквивалентные реализации, или никакого смысла в таких бенчмарках нет.

Ты серьезно не видишь, чем код на js и на java у тебя не эквивалентен, при чем в крайней степени?

Vec.prototype.x;
Vec.prototype.y;
Vec.prototype.z;
function Vec(x, y, z) {
    this.x = x;
    this.y = y;
    this.z = z;

    Vec.prototype.length = function () {
        return Math.sqrt(this.x * this.x + this.y * this.y + this.z * this.z);
    }

    Vec.prototype.dotProduct = function (v) {
        return this.x * v.x + this.y * v.y + this.z * v.z;
    }

    Vec.prototype.add = function (v) {
        return new Vec(this.x + v.x, this.y + v.y, this.z + v.z);
    }

    Vec.prototype.subtract = function (v) {
        return new Vec(this.x - v.x, this.y - v.y, this.z - v.z);
    }

    Vec.prototype.multiply = function (a) {
        return new Vec(this.x * a, this.y * a, this.z * a);
    }

    Vec.prototype.normalise = function () {
        return this.multiply(1.0 / this.length());
    }

    Vec.prototype.crossProduct = function (v) {
        return new Vec(this.y * v.z - this.z * v.y, this.z * v.x - this.x * v.z, this.x * v.y - this.y * v.x);
    }
}

private class Vec {

        double x;
        double y;
        double z;

        Vec(double x, double y, double z) {
            this.x = x;
            this.y = y;
            this.z = z;
        }

        double length() {
            return Math.sqrt(x * x + y * y + z * z);
        }

        double dotProduct(Vec v) {
            return x * v.x + y * v.y + z * v.z;
        }

        Vec add(Vec v) {
            return new Vec(x + v.x, y + v.y, z + v.z);
        }

        Vec subtract(Vec v) {
            return new Vec(x - v.x, y - v.y, z - v.z);
        }

        Vec multiply(double a) {
            return new Vec(x * a, y * a, z * a);
        }

        Vec normalise() {
            return this.multiply(1.0 / length());
        }

        Vec crossProduct(Vec v) {
            return new Vec(y * v.z - z * v.y, z * v.x - x * v.z, x * v.y - y * v.x);
        }
    };

Вынеси из конструктора в своём коде инициализации методов и ты получишь 2х тысячное ускорение своего кода за раз. Это чёрт возьми азы.

чето я обосрался на этом моменте

толи когдато читал толи уже не вспомню, но я точно посчитал конструкцию с прототипом эквивалентной объявлению класса, которая инициализируется единожды

спс что прояснил

Да, там есть пародия на неё.

Ну, если кусок vm вообще можно считать библиотекой языка.

Откуда у неё проблемы?

Проблему несёт в себе она. Но нода (v8) не единственный js движок.

Кому и кобыла - невеста.

Ну, там можно понаделать своих методов хоть для примитивов. Были бы еще перегрузки операторов, вот была бы пляска.

Были бы еще перегрузки операторов, вот была бы пляска.

Некоторые операторы (например instanceof, и даже частично оператор нестрогого сравнения ==) перегружать можно. В каких-то местах, можно использовать знания неявного приведения типов, и засунуть логику в вызываемые при этом под капотом вещи. Если же позволить перегрузку абсолютно всего (арифметические операторы, логические, операторы посылки сообщений объекты и прочие) - были бы лютейшие тормоза, ибо позднее связывание. Хотя есть вариант, позволить перегрузку методов по дефолту, а в блоке кода с определенной декларацией (что-то типа «not use override») перегрузку не задействовать, но подобное можно вполне реализовать и на уровне препроцессора.

Есть веб-воркеры, для них выделяется отдельный поток.

но не хочу раскрывать используемые алгоритмы\построение результирующих данных

Чуууувак. Это зашквар. Твой алгоритм никому не нужен, а уж тем более никому не нужно ковыряться в твоем js коде чтоб его оттуда достать

Плюс в бэкэнде есть самописные алгоритмы заказчика ... плюс есть вещи которые написаны по документам полученным под NDA.

Наполовину беру свои слова назад. Но самописные алгоритмы заказчика не меньший зашквар чем самописные алгоритмы среднестатистического ЛОРовца

Да вы батенька некропостер.
Если тебя смущает слово «алгоритм», то могу тебя успокоить - математической ценности они не имеют и это не уникальный™ сорт\хэш\структура данных. В сути своей просто способ преобразования данных из одних проприетарных протоколов в другие и паттерны общения по этим протоколам.

Поверь, это почти такая же многопоточность, как запуск пачки процессов питона.

Как оно спасёт, если его к DOM не пускают??

В питоне есть нормальные потоки, просто они на одном ядре крутятся. Если тебе не хватает 50 или 25 процентов твоего ядра - используй другие средства, или яву там, или с#..

Эх, некропостить так некропостить, вдруг кто-то ещё найдёт этот тред...

Правильно ли я понимаю, что в JavaScript есть многопоточность, а в Python её практически нет из-за GIL ?

Нет, это не так. В python из коробки всегда были настоящие потоки, они могут работать на разных ядрах, параллельно выполнять вычисления, одновременно ждать данных из разных сокетов и т.д.

Да, любая работа с питоновыми объектами или апи блокирует GIL. Остальные операции, ввод-вывод, вычислительные расширения вроде numpy/scipy — могут работать одновременно в разных потоках.

Поэтому. Если многопоточность в питоне нужна для параллельного ввода-вывода — она там есть и работает сразу.

Если многопоточность нужна для параллельных вычислений, то вычислительный код не должен использовать питоновые объекты. Например, нужно расставить переменным сишные типы cython-ом (у него на такой случай есть разные специальные модули). Либо вообще вынести весь вычислительный код в расширение на си.

Наконец, если хочется только питон, без примеси си, то в стандартной поставке есть модуль multiprocessing. Он парой строк кода может распараллелить вычисления на все ядра процессора. Это проще. Но производительность будет в несколько раз медленнее cython-а.

Правильно.