А что можно написать на асемблере, что заметно будет быстрее

работать чем на шарпе?)

Почти всё.

Смотря кто пишет)

C# использует байткод, чистый машинный код будет исполняться всегда быстрее.

шарп в виртуалке работает Конечно, JIT всех спасает, но это сначала нужно проjitтиться + оверхед всё-равно где-то есть

И тут тоже не всегда всё однозначно Цепочка виртуальных вызовов, к примеру, может преобразоваться в прямые вызовы с условием по типу JIT умеет разное, но если сравнивать просто код алгоритма напрямую, не думаю, что натив будет отставать

Есть пример, в котором JIT будет быстрее простого скомпилированного машинного алгоритма?

Вряд ли такое будет. Разницы то нет особой. Кроме способа. Разве что можно учитывать то что среда dot net позволяет определить некоторые характеристики проца и джит может это использовать во время компиляции.

Да, такие примеры есть. Почти всегда можно подобрать пример и контрпример

Как это нет? Когда исполняется через виртуальную машину, а когда через процессор. Первое всегда будет медленнее, его цель не в скорости, а в отсутствии зависимости от архитектуры.

Жду.

Ну я в контексте генерации асаемблерного кода обычным компилятором и джит. А не выполнении всей программы.

В своё время были в интернете. У меня есть из собственной практики. Если интересно, могу рассказать, почему такое происходит

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

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

Хм, что-то я был слишком высокого мнения о JITе шарпа Провел бенч виртуального вызова (коллекция однородных объектов по интерфейсу, чередование двух разных, соединение коллекций двух разных, вложенные вызовы) на шарпе и на расте через ThinBox (виртуальный вызов примерно как в ООП на плюсах), второй оказался быстрее, я ожидал обратного У меня еще надежда есть, что на Java будет все-таки быстрее, но страдать этим я не очень хочу))

На расте пишешь? По приколу?

Я нахожу раст удобным для мелких задач по типу cli утилит + инструменты для бенча там из коробки Для веба юзаю шарп, т.к. уже привык

Очень интересно!

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

Спасибо

Идея ясна, но разве jit смотрит на данные? А если в следующий заход в этот код данные будут совсем другими? Он что его перекомпилирует?

Всё в теории, а пример реальный где?

Да. (если мы про достаточно продвинутый жит)

Реальный пример я встречал, когда нативные тесты на Эльбрусе работали медленнее, чем в режиме трансляции x86 ->эльбрус

Пф... Да Эльбрус сейчас это нестабильная и сырая архитектура, про оптимизацию и тесты на нём говорить как-то странно.

а линтел разве как jit работает?

Когда это она стала нестабильной, и почему странно?

Да, причём многоуровневый

на эльбрусе скады для аэс делают)

Всегда была. Её недоработали, сейчас заморожен проект.

Это просто бред. Она стабильна несколько десятков лет и постоянно развивается

а где приобрести это чудо, хотя бы 2х ядерное, так сравнить хочется с амд апу процом

Откуда информация? Вот я знаю, что в Тайване их заказы больше не принимают. Схемки есть - а производства нигде нет. Как тестировать будут?

2с3 насколько знаю в зеленограде на 90нм выпускать могут

Это если у них ещё остались https://bitblaze.ru/

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

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

То, что проект заморожен - более вероятно, чем то, что там в секрете новые инструкции пилят, баги исправляют и оптимизацию делают. Вот когда последние новости у Эльбруса были?

Вы о переводе кода в микроопы, макроопы и всякое такое?

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

вот интересно, ценника нет чтобы психика целее была? :)

Нет. В житах уровень оптимизации - это что-то вроде области видимости оптимизируемого участка и его сложности

Тогда Видимо я не в курсе что такое линтел....погляжу

Короче, я понял. Примера, где JIT быстрее, чем машинный код - не будет. Так и скажи.

Ну, т.е. за пределами x86 жизни нет

Машинный код у нас не зависит от архитектуры? В корне неправильно сравнивать машинный код, который работает на одной архитектуре, с платформонезависимым кодом, запуская его при этом на другой архитектуре и процессоре.

В смысле? Оба случая - исполняемый код соответствующей архитектуры. Тест из одного исходника собран. Просто в одном случае он в жит трансляторе работает

Нет. Запускаем машинный код на x86, запускаем байткод на x86. Быстрее будет машинный код. Другие случаи неправильные будут. Другая архитектура и процессор тут не причём.

так тут же x86 для e2k выступает как байткод

и в связи с особенностями влив процов линтел преобразует более оптимизирование чем компиль

Чуть позже скину примеры на шарпе и расте, пойдёт? И подскажу как тюнить и то и то

Rust разве исполняется в байткоде?

Раст для сравнения с нативом, который может сгенерить llvm в расте

Лучше С и C#.

Классы в плюсаъ и виртуальные методы не подойдут?)

Не, вообще без ООП.

Вообще я сравниваю там виртуальные вызовы

Может, я не на то отвечаю? Я думал, мы про скорость исполнения говорим.

Вызов функции из таблицы функций по данным вроде тоже исполнение Ты хочешь что-то другое предложить?

Если мы про скорость исполнения, то такие задачи можно протестировать: 1. Окно на WinAPI (С) и на WinForms (C#) 2. Вывод в консоль (printf, C) и на Console.WriteLine (C#) 3. Чтение файла (fread) C и (File.Read) C#

Если мы про скорость, то надо и мерять скорость. FFT какое-нибудь написать, где IO нету, и библиотек нету, чистые вычисления.

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

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

Да сколько можно-то. Байткод там в сборках. Свои либы система компилирует в натив заранее. Посмотри, у тебя в процессах висит ngen. Остальное тоже компилируется. В самом худшем случае и в джаве, и в шарпе у тебя будет относительно медленный старт из-за JIT, потом это всё кэшируется, потом оно потенциально (потенциально!) может обогнать и си, и плюсы, просто потому что у компилятора в рантайме данных больше. И вот где-то тут теория сталкивается с практикой, но всё равно будет очень быстро.

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