Кроме того мой комментарий был про то, что прежде чем в очередной раз изобретать велосипед, то есть придумывать самыйбыстрый интерпретатор байт-кода стекового представления, прежде хорошо изучите устройство и принципы работы таких интерпретаторов, как интерпретатора байт-кода в OpenJDK.
Хотя должен также предупредить, что в виде C++ или даже asm-кода его в исходных кодах проекта Вы не найдете :), там есть только C++-код генерации кода интерпретатора :))). Но когда это останавливало нас, профеcсионалов :))?
Запуск java-машины очень дорогой процесс. Сравните время "gcc --version" и "java --version". При старте java-машины выполняется инициализация контекста. Как-то делал замер, и у меня получилось что-то вроде ~20 млн. байт-код инструкций - это только инициализация. Обработка "--version" потребует все несколько десятков инструкций. Причем много функций исполняется 1-2 раза. Однако jit-компилятор пытается многие из них оптимизировать. В итоге время компиляции не окупается, так как нативная версия функции может вообще не исполнится ни разу. Поэтому действительно "java --version" работает медленнее, чем "java --version -Xint". Но это классическая проблема любой jit-системы, выигрыш от исполнения оптимизированной версии должен перевесить время, затраченное на компиляцию. А это бывает не всегда. Для любой jit-системы можно найти анти-патерн.
С позиции сугубо "практики" - есть куча книжек, где берется элементарный вибратор, к нему подводятся гармонические колебания. И затем выводится Э.М. волна в дальней зоне. Но лично мне (сразу замечу - в физике полный профан) не удалось найти книжку, где бы ставилась задача приема, когда на антенный вибратор под азимутально-угломестными углами приходит плоская волна, и решается вопрос, а какие токи будут возбуждены в проводнике антенны. И соответственно какая функция напряжения будет в кабеле. При этом все знакомые физики, и знакомые физики знакомых (выпусники разных физфаков и физтехов) только при слове электродинамика шарахаются как черт от ладана. А так да, на каждом углу написаны системы уравнений.
Термояд? Холодный? Так на него уже вроде за 70 лет, 80 лет уже столько "украли"/"распилили", что нам всем наверное и не снилось. Так что нет. А вот разобраться, что такое понятие тока в (тех самых) уравнениях, имеет ли значение только среднее в единицу времени количество зарядов в заданном направлении через элементарную площадку. Или крайне важна еще и скорость движения зарядов. Это да.
Ничего не понимаю в электродинамике. И принципе не в основною тему статьи. Но в таких трубках "течет" электрический ток? Если две прямых трубки разместить рядом друг с другом, то между трубками по закону Ампера возникнет притяжения при одинаковом направлении тока?
Можно ли в трубку накачать электрически заряженный газ? Если сделать две трубки в форме колец и начать одновременно вращать, то газ будет вращаться вместе с трубками? Механическое вращение колец с заряженными газами будет эквивалентно электрическим токам. Будет ли тогда проявляться сила Ампера между двумя кольцами?
Упоминаемых 6 абстракций - это по аналогии с gcc/llvm 6 pass'ов, которые постепенно выполняют lowering от входных операций к выходным операциям? Выполнили lowering для циклов, выполнили lowering для call'ов и т.д., попутно выполняя некоторые арх.-независимые оптимизации? И все это на представлении MLIR, причем после очереднного lowering-pass'а получаемое состояние называется диалектом MLIR?
А собственно тензорный компилятор для RISC-V на базе OpenVINO/MLIR/DNNL/llvm, которому посвящена данная статья, - это opensource-проект? Под какой он лицензией? Добавляется или свой диалект для RISC-V в рамках тензорного компилятора? Оптимизации разрабатываемые в MLIR будут работать только для RISC-V или и для x86/arm/mips?
Кроме того мой комментарий был про то, что прежде чем в очередной раз изобретать велосипед, то есть придумывать самыйбыстрый интерпретатор байт-кода стекового представления, прежде хорошо изучите устройство и принципы работы таких интерпретаторов, как интерпретатора байт-кода в OpenJDK.
Хотя должен также предупредить, что в виде C++ или даже asm-кода его в исходных кодах проекта Вы не найдете :), там есть только C++-код генерации кода интерпретатора :))). Но когда это останавливало нас, профеcсионалов :))?
Увеличил счетчик в цикле в 2 раза (i < 2*
100000)$ time java Main > /dev/null
real 0m6,139s
$ time java -Xint Main > /dev/null
real 0m22,493s
Нативный код из-под java-компилятора быстрее java-интерпретатора. Вы ожидали иного результата?
Запуск java-машины очень дорогой процесс. Сравните время "gcc --version" и "java --version". При старте java-машины выполняется инициализация контекста. Как-то делал замер, и у меня получилось что-то вроде ~20 млн. байт-код инструкций - это только инициализация. Обработка "--version" потребует все несколько десятков инструкций. Причем много функций исполняется 1-2 раза. Однако jit-компилятор пытается многие из них оптимизировать. В итоге время компиляции не окупается, так как нативная версия функции может вообще не исполнится ни разу. Поэтому действительно "java --version" работает медленнее, чем "java --version -Xint". Но это классическая проблема любой jit-системы, выигрыш от исполнения оптимизированной версии должен перевесить время, затраченное на компиляцию. А это бывает не всегда. Для любой jit-системы можно найти анти-патерн.
Вывод - учите матчасть.
Попробуйте сравнить скорость самогобыстрого интерпретатора со скоростью интерпретатора в OpenJDK. Многие гениальные идеи отпадут сами собой.
С позиции сугубо "практики" - есть куча книжек, где берется элементарный вибратор, к нему подводятся гармонические колебания. И затем выводится Э.М. волна в дальней зоне. Но лично мне (сразу замечу - в физике полный профан) не удалось найти книжку, где бы ставилась задача приема, когда на антенный вибратор под азимутально-угломестными углами приходит плоская волна, и решается вопрос, а какие токи будут возбуждены в проводнике антенны. И соответственно какая функция напряжения будет в кабеле. При этом все знакомые физики, и знакомые физики знакомых (выпусники разных физфаков и физтехов) только при слове электродинамика шарахаются как черт от ладана. А так да, на каждом углу написаны системы уравнений.
Термояд? Холодный? Так на него уже вроде за 70 лет, 80 лет уже столько "украли"/"распилили", что нам всем наверное и не снилось. Так что нет. А вот разобраться, что такое понятие тока в (тех самых) уравнениях, имеет ли значение только среднее в единицу времени количество зарядов в заданном направлении через элементарную площадку. Или крайне важна еще и скорость движения зарядов. Это да.
Ничего не понимаю в электродинамике. И принципе не в основною тему статьи. Но в таких трубках "течет" электрический ток? Если две прямых трубки разместить рядом друг с другом, то между трубками по закону Ампера возникнет притяжения при одинаковом направлении тока?
Можно ли в трубку накачать электрически заряженный газ? Если сделать две трубки в форме колец и начать одновременно вращать, то газ будет вращаться вместе с трубками? Механическое вращение колец с заряженными газами будет эквивалентно электрическим токам. Будет ли тогда проявляться сила Ампера между двумя кольцами?
Упоминаемых 6 абстракций - это по аналогии с gcc/llvm 6 pass'ов, которые постепенно выполняют lowering от входных операций к выходным операциям? Выполнили lowering для циклов, выполнили lowering для call'ов и т.д., попутно выполняя некоторые арх.-независимые оптимизации? И все это на представлении MLIR, причем после очереднного lowering-pass'а получаемое состояние называется диалектом MLIR?
Верно ли, что для riscv был создан транслятор OpenVINO -> MLIR и ранее MLIR вместе с OpenVINO не использовался?
А собственно тензорный компилятор для RISC-V на базе OpenVINO/MLIR/DNNL/llvm, которому посвящена данная статья, - это opensource-проект? Под какой он лицензией? Добавляется или свой диалект для RISC-V в рамках тензорного компилятора? Оптимизации разрабатываемые в MLIR будут работать только для RISC-V или и для x86/arm/mips?