Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А по факту, там где нужна скорость, биты таки выжимают везде (это можно дать ускорение на порядок, а то и несколько), в том числе и на Java. Вот конкретный пример, ручная нарезка массивов на структуры через байт-буфера, отказ от GC, и прочие кактусы радости: EP>http://www.youtube.com/watch?v=Q-7y1u9kZV0
Случается... редко, правда. Это примерно как оптимизации на С++. Когда прижимает начинают ими заниматься, а до этого пишут в гражданском стиле.
Собственно в дотнете нарезать ничего не надо, так как есть структуры. К экономией выделения памяти прибегают, но тоже в исключительных случаях. На С++ точно так же пытаются изворачиваться. Например, прибегают к пулам (регионам) и т.п. В Розлине (новом, менеджед-компиляторе шарпа) этим занимаются, чтобы не отставать от прошлой (плюсовой) версии. Вроде как результат получился сопоставимый по скорости с плюсовым. Причина перехода на шарп с плюсов банальна. Поддержка разросшегося языка стала дикой болью и стал препятствовать развитю языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
совсем не давно был конкретный простейший пример (отставание C# в 7 раз!),
Треп это все. Всегда можно найти какие-то вырожденные случаи, но они никак не будут влиять на общее положение дел. Одно узкое место занимающееся битодроблением можно и вручную оптимизировать (вплоть до ансэйфа или сишной/ассемблерной функции). А, вот 90% гражданского кода работающего с моделью проще писать на более высокоуровневом языке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EP>>А по факту, там где нужна скорость, биты таки выжимают везде (это можно дать ускорение на порядок, а то и несколько), в том числе и на Java. Вот конкретный пример, ручная нарезка массивов на структуры через байт-буфера, отказ от GC, и прочие кактусы радости: EP>>http://www.youtube.com/watch?v=Q-7y1u9kZV0 VD>Случается... редко, правда. Это примерно как оптимизации на С++. Когда прижимает начинают ими заниматься, а до этого пишут в гражданском стиле.
Вот в C++ из "гражданского стиля" получается быстрый код, за счёт дешёвых абстракций.
"The going word at Facebook is that reasonably written C++ code just runs fast, which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu
VD>Собственно в дотнете нарезать ничего не надо, так как есть структуры.
Да, я показал экстремальный случай.
Тем не менее, C#'овские структуры далеко не всегда применимы из-за ограничений языка, я тебе уже показывал пример
.
VD>К экономией выделения памяти прибегают, но тоже в исключительных случаях. VD>На С++ точно так же пытаются изворачиваться. Например, прибегают к пулам (регионам) и т.п.
На C++ это намного проще и естественней, например потому что есть placement new — объект можно создать практически в любом куске памяти. Попробуй на C# сделать эффективный Variant.
Помимо памяти/структур/GC — есть и другие проблемы. Например дорогие механизмы абстракций в C# — те же ФВП и замыкания.
VD>В Розлине (новом, менеджед-компиляторе шарпа) этим занимаются, чтобы не отставать от прошлой (плюсовой) версии. Вроде как результат получился сопоставимый по скорости с плюсовым.
И на C#, и даже на Java, можно написать код сопоставимый по скорости с кодом на C++ — я с этим не спорю, и даже постоянно это утверждаю.
Вот только уровнем такой код будет намного ниже чем аналог на C++, и этого кода будет намного больше. Например придётся вручную пилить все циклы, в то время как на C++ можно взять высокоуровневые ФВП+замыкания и дать компилятору их заинлайнить.
VD>Причина перехода на шарп с плюсов банальна. Поддержка разросшегося языка стала дикой болью и стал препятствовать развитю языка.
Их старый компилятор скорей всего использовал старые/плохие технологии, и это было основной проблемой. Например их компилятор C++ кода вообще не имел AST (а может и не имеет до сих пор).
Здравствуйте, VladD2, Вы писали:
_>>А у Nemerle есть свой аналог Boost'а? ) VD>Все что есть в Буст у немерла или реализовано в виде макросов, или уже имеется в стандартной библиотеке дотнета. Она, к твоему сведению, раз в 100 больше буста.
А где там например аналоги:
1. Boost.Heap: Fibonacci Heap, Binomial Heap
2. Boost.Geometry, Boost.Polygon
3. std/boost::deque
4. Boost Generic Image Library
5. Boost.Graph
6. Boost Interval Container Library
7. Boost Multi-index Containers
8. Boost.Odeint
9. Boost.Sort
?
Здравствуйте, VladD2, Вы писали:
_>>Что касается метапрограммирования на платформах jvm и .net, то на мой взгляд это не имеет большого смысла из-за самой ориентации этих платформ. VD>Зачем тогда придуманы и широко используются T4? И что тогда народ трахается с реализацией разных INotifyPropertyChanged? VD>Как раз задач которые требуют кодогенерации море. Просто часть людей не доросла до их решения с помощью МП, а часть готова возиться с текстуальной кодогенерацией без удобств, лишь бы не пользоваться ничем "левым".
Вопрос ведь не о том есть ли хоть кто-то кто пытается использовать то или иное МП на .NET, а грубо говоря о количестве таких разработчиков по сравнению например с тем же C++.
Здравствуйте, VladD2, Вы писали:
_>>Что касается метапрограммирования на платформах jvm и .net, то на мой взгляд это не имеет большого смысла из-за самой ориентации этих платформ. VD>Зачем тогда придуманы и широко используются T4? И что тогда народ трахается с реализацией разных INotifyPropertyChanged?
T4 — это такое метапрограммирование уровня PHP. Ну да, PHP вполне покорил массы...)
VD>Как раз задач которые требуют кодогенерации море. Просто часть людей не доросла до их решения с помощью МП, а часть готова возиться с текстуальной кодогенерацией без удобств, лишь бы не пользоваться ничем "левым".
О том в общем то и речь. ) Что не доросла и при этом не имеет никакого желания расти в эту сторону. )))
Здравствуйте, VladD2, Вы писали:
_>>Ты не согласен с самими цифрами или с их источником? VD>Цифры высосаны из пальца. Их обсуждать — себя не любить.
Ты не понимаешь о чём я говорю? ) Как разница откуда взяты эти цифры. У тебя же есть некое внутреннее представление (на базе многих разных источников) о состояние индустрии? Так вот твоё внутреннее представление разве не совпадает с этими цифрами (в самом грубом приближение)? )))
VD>Немерл без МП (если в нем будет все что сделано макросами, но встроено в язык) лучше шарпа раз в 10. МС эти фичи за 10 лет повторить не смог. И я об этом абзацем ниже написал.
Сомнительно. Потому как синтаксический сахар никогда не был ключевым преимуществом какого-то языка. Нужна именно новая возможность, а не новый способ доступа к старой возможности.
_>>Не совсем так. Речь идёт о той нише, где есть смысл в переходе с C# на Nemerle. VD>В переходе есть смысл в любой нише. Если убрать проблемы присущие "самопальной" реализации, то у Шарпа просто нет ни одного приемущества, а у Немерла их масса. Он просто очень серьезный суперсет шарпа.
Главное преимущество Шарпа сейчас (внутри мира .net) — это историческое первенство. Соответственно теперь любому другому конкурирующему языку в этой области надо быть не просто не хуже Шарпа, а намного лучше.
VD>Все что есть в Буст у немерла или реализовано в виде макросов, или уже имеется в стандартной библиотеке дотнета. Она, к твоему сведению, раз в 100 больше буста.
Смешно. )))
VD>>>Плюс это не совсем так. На дотнете и яве пишут различнийший софт. Тот же ReSharper и IDEA тому отличный пример. Вы бы назвали эти задачи "системными". _>>Не стоит выдавать явные исключения за правило. ) VD>Какие исключения? IDE на С++ — вот это исключение. И поверь мне на слов — сервисы IDE офигеть как требовательны к производительности.
Ты вот даже не понял о чём я говорил (совсем о другом) и при этом умудрился оспорить это полной ерундой. )))
Я имел в виду, что в мире Java разработка IDE занимает незначительную долю от всего этого мира. А большинство там занято гораздо менее продвинутыми вещами.
Однако если уж ты захочешь поговорить об IDE, да ещё и количественно, то боюсь тебя ждёт больше разочарование. Как раз C/C++ реализаций намного больше на рынке. Просто несколько лидирующих продуктов написано на Java и всё. Но если ты захочешь посчитать все, то... )))
_>>А если попробовать реализовать скажем фронтенд к gcc? ) VD>Подключайся, реализуем. У нас на все сил не хватит. У нас получается офигительный генератор фронтэндов, но для каждого бэкэнда нужно приложить не мало усилий. И прикладывать их должны люди знающие эти бэкэнды, так как там очень важны детали.
я уже частично согласился, что на самом деле .net является правильным выбором для вас. Только вот это моё согласие является не совсем комплиментом...
VD>Думаю, что где-то к сентябрю мы начнем работу на новой версии Немерла (или чего-то очень близкого к нему по духу) на базе Нитры. Нитра принципиально подразумевает поддержку нескольких бэкэндов. Присоединяйтесь и создадим вместе нативные бэкэнды. Я, правда, думал сделать бэкнд для LLVM, но можно и для GCC. Лично я и в том, и в другом примерно одинаково не разбираюсь .
Я вообще то тоже))) В смысле в роли создателя языков (для GCC/Clang'a, DSL разные есть на моём счету). А вот как пользователь этих компиляторов очень даже разбираюсь. )))
Clang более привычен для яблочного мира. А gcc для мира HPC и встраиваемых систем (как на линухе, так и вообще без ОС). Под виндой же ситуация вообще очень забавная. Clang долгое время был там крайне глючным и кривым (сейчас вроде исправился, но не гарантирую) и при этом это была официальная версия. А gcc под винду уже много лет как стабилен и удобен, но при этом все варианты являются какими-то неофициальными сборками (кстати самую лучшую делает человек с нашего форума).
совсем не давно был конкретный простейший пример (отставание C# в 7 раз!), VD>Треп это все. Всегда можно найти какие-то вырожденные случаи, но они никак не будут влиять на общее положение дел. Одно узкое место занимающееся битодроблением можно и вручную оптимизировать (вплоть до ансэйфа или сишной/ассемблерной функции). А, вот 90% гражданского кода работающего с моделью проще писать на более высокоуровневом языке.
Вообще то там часть провала обусловлена особенностям работы с многомерными массивами (т.е. сюда к примеру укладывается вся 2D графика), а другая часть провала обусловлена вообще обработкой любых массивов из чисел. Трёп и вырожденные случаи говоришь? ) Похоже ты вообще не понимаешь о чём речь. Давай ка я тебе покажу все цифры в деталях, чтобы ты оценил масштаб трагедии:
Python - 17 c //динамический язык, для сравнения
JavaScript - 13 с //динамический язык, для сравнения
C# - 8,7 с //я считаю это ужас для компилируемого языка со статической типизацией
Java - 7,3 с //не сильно лучше, но немного неожиданно (никаких теоретических предпосылок обгона тут C# я не знаю)
C# unsafe - 5,0 с //используем арифметику указателей (многие алгоритмы невозможно эффективно записать без неё)
D - 4,9 с //полностью нативный язык с указателями, но не выдающимся оптимизатором (оригинальный компилятор)
C++ no-simd - 3,5 c //мощный оптимизатор проявляет себя, даже если ему запретить использовать все возможности процессора
C++ - 1,3 с //базовый результат C++ с абсолютно тупым кодом (без малейшей оптимизации в исходном коде) не плох, но simd оптимизатор ещё не идеален
C++ opt. - 0,6 c //после минимальной ручной оптимизации мы достигаем теоретически возможного максимума быстродействия для данного процессора (на одном ядре).
Ты действительно считаешь, что подобное (а оно будет всплывать во всех вычислениях на массивах) — это ничего страшного? )
P.S. Такими темпами я совершенно не удивлюсь, если через пару лет (как раз WebAssembly подоспеет) Microsoft вообще плюнет на .Net и начнёт развивать только JS. Потому как разницы в быстродействие особой нет, а разница в кроссплатформенности и простоте разработки на лицо (и не в пользу .net'a). Вот как раз в последний релиз VisualStudio добавили Cordova (обычный принцип MS: "не можешь победить — возглавь")...
VD>Не знаю. В начале, по наивности, я думал, что людям достаточно просто наличия более совершенного языка. Что недоработки в компиляторе, документации, IDE и переносимость можно будет побороть силами комьюнити. Но сейчас я уже понимаю, что это все наивные представления. В жизни так не происходит. По сему у меня нет иллюзий на этот счет. Плюс Немерл — это не мой язык. Я всего лишь его пользователь.
Очень рекомендую вот это видео. Оно рассказано сильно с точки зрения javascript-программистов, но он говорит достаточно общие вещи, которые применимы к любому языку программирования. Ну и да, Crossing the Chasm я тоже советую.
Здравствуйте, WolfHound, Вы писали:
I>>Хрен его знает. У конккурентов ничего такого нет и тем не менее доминирует на рынке никак не jetBrains WH>А кто?
Ну вот есть youtrack, в котором применяется хитрый язык, что, кстати, уже само как бы намекает Но везде засилье инструментов навроде джиры.
У меня пока что ощущение, что котлины-немерле-нитры нужны для рекламы, а 95% продакшна пилится на мейнстримных языках мейнстримными программистами. Оставшиеся 5% это скорее всего древнейший дсл которым хвастались еще до котлина.
Здравствуйте, VladD2, Вы писали:
VD>Не знаю. В начале, по наивности, я думал, что людям достаточно просто наличия более совершенного языка. Что недоработки в компиляторе, документации, IDE и переносимость можно будет побороть силами комьюнити. Но сейчас я уже понимаю, что это все наивные представления. В жизни так не происходит. По сему у меня нет иллюзий на этот счет. Плюс Немерл — это не мой язык. Я всего лишь его пользователь.
VD>Кое что Немерл уже сделал. Шарпа с каждой версией впитывает его фичи (хотя открыто это не признается). Лет через 15, возможно, большая часть современных фич (за исключением макросов) будет и в Шарпе.
Ох. Я понял, что мне напоминает этот диалог.
Сергея «Синтаксический оверхед» Губанова с его твёрдым убеждением, что Java/C# всё содрали из Оберона, а на самом-то деле никто не знает, что Оберон лучший в мире язык, весь мейнстрим вырос из идей Н.Вирта но подло это скрывает, а мы просто слишком тупы все, чтобы оценить красоту Великого Оберона.
«Долгая память — хуже, чем сифилис, особенно в узком кругу»
Здравствуйте, Гест, Вы писали:
Г>Сергея «Синтаксический оверхед» Губанова с его твёрдым убеждением, что Java/C# всё содрали из Оберона, а на самом-то деле
на самом-самом деле, все фичи C# делятся на два класса — которые тупые микрософтовцы содрали с хаскела, и которые даже не смогли правильно содрать
Здравствуйте, VladD2, Вы писали:
VD>Нормальный язык. Есть пара странностей, но она как раз из-за наследия Обжектив-С (например, отсутствие перегрузок).
Исключений нет, например. ARC без возможности создать объект на стеке (вроде).
VD>Моментального успеха и не бывает.
Дык, я об этом и говорю.
VD>В этом нет смысла. Им важно только лишь осложнить кросплатформную разработку. Конкуренция между своими языками их не волнует. От того, что все останутся на Обжектив-С им ни горяче, ни холодно.
Ну посмотрим. Тем более, что они как раз обещают "открыть" язык и какую-никакую кроссплатформенность.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>на самом-самом деле, все фичи C# делятся на два класса — которые тупые микрософтовцы содрали с хаскела, и которые даже не смогли правильно содрать
Вопрос "зачем?" не раскрыт.
Я конечно представляю возможные варианты, и вначале доклада даже есть список ограничений C# — но чёткая область применения всё же не очерчена.
По реализации:
* Для инициализации by-default там генерируется специальный код конструкторов для классов содержащие такие поля. Проще было бы сделать отдельный тип default_initialized<T>.
* Управление памятью — предлагается использовать shared_ptr и подобные (каждый C# new заворачивать в make_shared ), как будут решаться циклически ссылки — непонятно (упомянул weak_ptr, но это не 100% решение). Про GC сказал мол "смысл совсем не в этом" — непонятно почему. Например есть готовый консервативный Boehm GC, либо можно поискать точный, либо даже сделать свой (я делал простой библиотечный копирующий GC для C++ — было что-то около двухста строк).
Говорится что это демонстрация того что Roslyn работает быстро, при этом ничего похожего на замеры не было в докладе.
Про LINQ сказал что никаким образом в контексте C++ не предусмотреть и обход структур и генерацию SQL из одного кода
Был вопрос про обратную задачу, т.е. C++ -> C#, на что дан ответ — мол нет готового аналога Roslyn. Вообще-то есть Clang+LLVM, которые как раз успешно используются для подобного проекта — Emscripten.
В конце упоминается статья про Вазу на habrahabr — вообще-то оригинал это доклад Майерса.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вопрос "зачем?" не раскрыт. EP>Я конечно представляю возможные варианты, и вначале доклада даже есть список ограничений C# — но чёткая область применения всё же не очерчена.
Ну началось всё, как я понял, просто как тест Roslyn'а. А в итоге может выйти инструмент, позволяющий "не погружаться в страшные плюсы". )))
EP>По реализации: EP>* Для инициализации by-default там генерируется специальный код конструкторов для классов содержащие такие поля. Проще было бы сделать отдельный тип default_initialized<T>.
Как мне кажется, это не принципиально — замена одной кодогенерации на другую.
EP>Говорится что это демонстрация того что Roslyn работает быстро, при этом ничего похожего на замеры не было в докладе.
Нууу типа успевает парсить в реальном времени со вводом текста. )))
EP>Был вопрос про обратную задачу, т.е. C++ -> C#, на что дан ответ — мол нет готового аналога Roslyn. Вообще-то есть Clang+LLVM, которые как раз успешно используются для подобного проекта — Emscripten.
Комплимент в сторону Roslyn понятно почему был. ))) Но и основную причину отсутствия такого инструмента он тоже назвал — ненужность на рынке, т.к. это скорее плюсы сейчас на подъёме...
Здравствуйте, alex_public, Вы писали:
EP>>Вопрос "зачем?" не раскрыт. EP>>Я конечно представляю возможные варианты, и вначале доклада даже есть список ограничений C# — но чёткая область применения всё же не очерчена. _>Ну началось всё, как я понял, просто как тест Roslyn'а.
Если так — то конечно тогда вопросов нет.
_>А в итоге может выйти инструмент, позволяющий "не погружаться в страшные плюсы". )))
Не погружаться чтобы получить что?
* Скорость? — не получится, точнее разве что самый минимум — семантика ведь вся остаётся, а именно она и ответственна за большую часть тормозов. Если на C++ писать в Java-style то мы и получим те же тормоза.
* Большую переносимость кода? Возможно, вот только портировать VM (а-ля Mono) было бы и мощнее, и надёжнее, и возможно проще.
EP>>По реализации: EP>>* Для инициализации by-default там генерируется специальный код конструкторов для классов содержащие такие поля. Проще было бы сделать отдельный тип default_initialized<T>. _>Как мне кажется, это не принципиально — замена одной кодогенерации на другую.
Это на порядок проще. Вместо того чтобы отслеживать все места где нужно не забыть сгенерировать инициализацию, можно просто заменить int32_t на default_initialized<int32_t> — и проблема решена.
EP>>Говорится что это демонстрация того что Roslyn работает быстро, при этом ничего похожего на замеры не было в докладе. _>Нууу типа успевает парсить в реальном времени со вводом текста. )))
Цифры нужны, без них это всё сферически. Подобный код и Clang моментально пережёвывает.
Здравствуйте, alex_public, Вы писали:
_>Ты действительно считаешь, что подобное (а оно будет всплывать во всех вычислениях на массивах) — это ничего страшного? )
А сколько таких задач встречается для обычного программиста? Вконце концов всегда можно использовать унсейв код для оптимизации по скорости.
Мало того многие используют неоптимальные классы для решения своих задач. И при выборе правильного алгоритма скорость может достигать в разы. http://rsdn.ru/article/alg/tlsd.xml
_>P.S. Такими темпами я совершенно не удивлюсь, если через пару лет (как раз WebAssembly подоспеет) Microsoft вообще плюнет на .Net и начнёт развивать только JS. Потому как разницы в быстродействие особой нет, а разница в кроссплатформенности и простоте разработки на лицо (и не в пользу .net'a). Вот как раз в последний релиз VisualStudio добавили Cordova (обычный принцип MS: "не можешь победить — возглавь")...
В этой статье мы расмотрим расширение для Visual Studio под наванием 'C#/XAML for HTML5'. Данное расширение позволяет транслировать имеющийся код на C# и XAML в код HTML5+JavaScript. Благодаря подобной трансляции мы сможем создавать на C# приложение, которое после трансляции в JavaScript будет запускаться и на тех платформах, где .NET по умолчанию не поддерживается и где есть поддержка HTML5 и Javascript — Android, iOS, Mac, Chromebooks, Linux, Windows и т.д. То есть по сути у нас получается гибридное приложение.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Ты действительно считаешь, что подобное (а оно будет всплывать во всех вычислениях на массивах) — это ничего страшного? ) S> А сколько таких задач встречается для обычного программиста? Вконце концов всегда можно использовать унсейв код для оптимизации по скорости.
В приведённом примере есть замеры и для unsafe — всё равно ничего хорошего.
S>Мало того многие используют неоптимальные классы для решения своих задач. И при выборе правильного алгоритма скорость может достигать в разы. S>http://rsdn.ru/article/alg/tlsd.xml
Ну так это же уже вопросы, не зависящие от выбора платформы разработки.
S> Я думаю, что будет развиваться в двух направлениях. S>Компиляция C# и XAML в JavaScript
Просто компилятор C#/XAML в JavaScript ничего особо интересного не приносит. Такого добра вообще полно на всех языках, от TypeScript до C++. И оно может имеет какой-то смысл только в виде разработки особо сложных сайтов, но не мобильных приложений. Потому что весь смысл Cordova (или скажем Qt) как раз в кроссплатформенном доступе к нативным возможностям платформы (к тому же акселерометру скажем).
Ну да, PHP вполне покорил массы...)
.
