Здравствуйте, BlackEric, Вы писали:
BE>Список фич еще не объявлен же. BE>Вот их беклог: dotnet/csharplang. А скорость всегда пробуют улучшать.
Это же список изменений исключительно для C#?
А коллега выше приводил в основном предложения для Runtime.
Я понимаю, что они часто взаимосвязаны, но всё же это разные зоны и команды
Здравствуйте, _NN_, Вы писали:
_NN>Никто не хочет обсудить ? _NN>Похоже в .NET 10 нас ждут серьёзные улучшения производительности.
Появятся, обсудим. Обсуждать новости из будущего смысла нет. Несомненно оптимизации (не ломающие семантику) лишними не будут. В Яве это все давно сделано. Пора и в дотете сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Codealot, Вы писали:
C>Все сильнее становится ощущение, что чуваки пытаются переизобрести C++.
А можно пояснить откуда это ощущение и что вы вообще вкладываете в понятие "переизобрести C++"?
Я пробежался по ссылкам коллеги, но увидел только вполне себе логичные предложения по оптимизации JIT. Да, есть некая специфика .Net, но это и логично.
Здравствуйте, rudzuk, Вы писали:
R>Догнат и Перегнат!
Ну перегнать, наверное, пока нет.
Там в первой же ссылке они пишут, что тот же Interprocedural Analysis (IPA) — это фишка, в первую очередь, для AOT, но они хотят хотябы некоторые элементы сделать доступными JIT.
Т.е., в моем понимании, техники доступные классически компиляторам (производящим сразу исполнимый код — те же C++ компиляторы) для JIT будут слишком дорогими, а значит он заведомо в проигрышной ситуации.
Но с другой стороны, а все ли компиляторы (даже того же C++) реализуют весь набор оптимизаций?
Здравствуйте, rudzuk, Вы писали:
R>Есть списки оптимизаций в GCC и LLVM, насколько они соответствуют "всему набору"
То, что в конкретном компиляторе сделано максимум возможного, я не сомневаюсь.
Мой вопрос немного о другом. Фраза о переизобритении C++, как по мне, намекает, что благодаря неким особенностям языка все перечисленные оптимизации получаются сами собой, а значит во всех более-менее известных компиляторах они есть по определению
Иначе я в принципе не понимаю этой фразы — идут вполне рутинные работы по улучшению JIT-компилятора (даже не идут — пока обсуждаются), при чем тут C++?
Здравствуйте, Михаил Романов, Вы писали:
МР> R>Есть списки оптимизаций в GCC и LLVM, насколько они соответствуют "всему набору"
МР> То, что в конкретном компиляторе сделано максимум возможного, я не сомневаюсь.
LLVM, в данном случае, упоминается не столько, как конкретный компилятор, сколько, как распространенный бэкенд для различных компиятров других языков (кажется, это относится и к GCC). Например, МЦСТ делает поддержку архитектуры своих процов (Эльбрус) именно через LLVM, и таким образом любой компилятор использующий LLVM становится Эльбрус-совместимым (теоретически).
МР> Мой вопрос немного о другом. Фраза о переизобритении C++, как по мне, намекает, что благодаря неким особенностям языка все перечисленные оптимизации получаются сами собой, а значит во всех более-менее известных компиляторах они есть по определению
Я понял это по-другому. Из мильенького шарпа делают очередное чудище, впихивая все, что удается впихнуть (не конкретно данная новость, а общее движение вокруг). Возможно, я не прав, и автор подразумевал что-то другое.
МР>> Мой вопрос немного о другом. Фраза о переизобритении C++, как по мне, намекает, что благодаря неким особенностям языка все перечисленные оптимизации получаются сами собой, а значит во всех более-менее известных компиляторах они есть по определению
R>Я понял это по-другому. Из мильенького шарпа делают очередное чудище, впихивая все, что удается впихнуть (не конкретно данная новость, а общее движение вокруг). Возможно, я не прав, и автор подразумевал что-то другое.
Ну из шарпа хотят сделать многофункциональный — кроссплатформенный язык с поддержкой AOT, WebAssembly
C++ в том же AOT и WebAssembly играет промежуточную роль. Зачем изобретать новые сущности если уже есть инструменты в виде С++ который все и делает.
Проще скомпилировать в С++, а уже используя разные настройки скомпилировать все в AOT или WASM или еще куда
Программисту C# разбираться со всякими настройками С++ компилятора не нужно. Ему просто нужно выствить куда его код скомпилируется в итоге.
Как раз миленький шарп в итоге остается той же милотой!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rudzuk, Вы писали:
R>Я понял это по-другому. Из мильенького шарпа делают очередное чудище, впихивая все, что удается впихнуть (не конкретно данная новость, а общее движение вокруг). Возможно, я не прав, и автор подразумевал что-то другое.
Возможно.
Вот только автор исходного поста про изменения в C# вообще ни словом не упомянул. Он привел ссылки исключительно на предложения по улучшению JIT.
Здравствуйте, Serginio1, Вы писали:
S> Ну из шарпа хотят сделать многофункциональный — кроссплатформенный язык с поддержкой AOT, WebAssembly S> C++ в том же AOT и WebAssembly играет промежуточную роль. Зачем изобретать новые сущности если уже есть инструменты в виде С++ который все и делает. S> Проще скомпилировать в С++, а уже используя разные настройки скомпилировать все в AOT или WASM или еще куда
S> Программисту C# разбираться со всякими настройками С++ компилятора не нужно. Ему просто нужно выствить куда его код скомпилируется в итоге.
Дядя Сережа, ну ты базворд ходячий, блин...
S> Как раз миленький шарп в итоге остается той же милотой!
S>> Ну из шарпа хотят сделать многофункциональный — кроссплатформенный язык с поддержкой AOT, WebAssembly S>> C++ в том же AOT и WebAssembly играет промежуточную роль. Зачем изобретать новые сущности если уже есть инструменты в виде С++ который все и делает. S>> Проще скомпилировать в С++, а уже используя разные настройки скомпилировать все в AOT или WASM или еще куда
S>> Программисту C# разбираться со всякими настройками С++ компилятора не нужно. Ему просто нужно выствить куда его код скомпилируется в итоге.
R>Дядя Сережа, ну ты базворд ходячий, блин...
S>> Как раз миленький шарп в итоге остается той же милотой!
R>Милота-милота...
Здравствуйте, Михаил Романов, Вы писали:
МР>вполне себе логичные предложения по оптимизации JIT
Изначально, приоритет отдавался простоте кода и удобству, а не скорости. А сейчас они делают оптимизации в ущерб нужным вещам, которые никак не могут сделать уже почти десяток лет.
МР>>вполне себе логичные предложения по оптимизации JIT
C>Изначально, приоритет отдавался простоте кода и удобству, а не скорости. А сейчас они делают оптимизации в ущерб нужным вещам, которые никак не могут сделать уже почти десяток лет.
Изначально C# был сложнее Java за счет struct. В 2005 появились дженерики и главное это yield с энумераторами, плюс появились деревья выражений и самое главное из этого это Linq!
Так что приоритет отдавался не простоте, а удобству и функциональности.
Что касается скорости, то появление ref struct и ref Поля
это совместимость с нативным кодом и ускорение, без лишних копирований.
Что же касается Jit, то он никакого отношения к коду не имеет.
Его можно оптимизировать независимо от языка.
Здравствуйте, Serginio1, Вы писали:
S>В 2005 появились дженерики и главное это yield с энумераторами, плюс появились деревья выражений и самое главное из этого это Linq!
Писать проще, а не фич меньше.
S>Что же касается Jit, то он никакого отношения к коду не имеет. S>Его можно оптимизировать независимо от языка.
Только если у тебя бесконечные ресурсы. Которых на самом деле нет.
Здравствуйте, Codealot, Вы писали:
S>>Что же касается Jit, то он никакого отношения к коду не имеет. S>>Его можно оптимизировать независимо от языка.
C>Только если у тебя бесконечные ресурсы. Которых на самом деле нет.
Зачем бесконечные ресурсы. Производительность Jit по сравнению с С++ постоянно растет.
и солнце б утром не вставало, когда бы не было меня
