Здравствуйте, BoobenCom, Вы писали:
BC>Во-первых, если мы включаем Унсейф, то можно говорить что это уже не совсем шарп. А такая себе вставка Сишных команд.
Да ну ? Это все в спецификации C#.
С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.
А если еще __emit(machine code) то вообще.
BC>Во-вторых, ключевой момент — в пару машинных комманд. Вызов функции Marshal.AllocHGlobal это уже пару сотен машинных комманд с длинными джампами. BC>Так что код выше может работать и в 20, а может даже в 100 раз медленей чем на Си.
Хотите стек? Есть stackalloc , проблема то.
Точно также я и про malloc против стека могу сказать.
Здравствуйте, _NN_, Вы писали:
_NN>С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.
Если ты в код Си вставляешь ассемблерную вставку то да, это не Си, это кусок ассемблера.
Разве это не очевидно ?
Re[45]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>Здравствуйте, _NN_, Вы писали:
_NN>>С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.
BC>Если ты в код Си вставляешь ассемблерную вставку то да, это не Си, это кусок ассемблера. BC>Разве это не очевидно ?
Однако от этого программа не перестает быть написанной на C .
Я так понимаю недовольство в том, что в С# можно работать напрямую с памятью
Здравствуйте, BoobenCom, Вы писали:
BC>Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой. BC>Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю.
Так иди и займись своим образованием, а не неси пургу по форумам демонстрируя свое невежество.
Открой для себя безопасные приведения типов, классы, вариантные типы, ансэйф (в конце, концов).
BC>А фича очень удобная в низкоуровневом программирование.
Фича нужная очень редко и чреватая серьезными багами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>Я эти сказки уже давно слышу. Но при попытках сравнить парсеры или скорости работы, сразу банят.
Банят тебя потому что ты правила форума не уважаешь. Вот здесь развел офтопик, например.
Я не хочу трать время на невежд и недоучек. Иди в КСВ, создавай там тему и получай удовольствие от того, что над тобой будут смеяться. А здесь все это разводить не надо. Будешь продолжать — за баню.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
EP>>Может тогда исправить ссылку в nemerle.org/About, которая ведёт на wiki? VD>По хорошему нужно восстановить старую вики или перенести ее контент на новый сервер, так как, иначе, много информации оказывается потерянной.
На эту wiki много внешних ссылок (видел на rsdn, stackoverflow, dlang.org. подозреваю что таких мест очень много) — они все сейчас "битые". Это может отбить всякое желание к изучению (типа "а оно ещё живое?"), или как минимум оставить осадочек ("да там даже wiki не работает").
Re[15]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>На эту wiki много внешних ссылок (видел на rsdn, stackoverflow, dlang.org. подозреваю что таких мест очень много) — они все сейчас "битые". Это может отбить всякое желание к изучению (типа "а оно ещё живое?"), или как минимум оставить осадочек ("да там даже wiki не работает").
Согласен. Не хорошо. Постараюсь толкнуть этот вопрос в понедельник.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>Ничего не преувеличение. BC>В Си можно делать вот например такие финты: BC>... BC>Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой. BC>Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю. BC>А фича очень удобная в низкоуровневом программирование.
Какие ещё пара машинных команд для преобразования типа? Для процессора не существует никаких типов, так что подобное "преобразование" занимает ровно 0 команд. Причём на любом языке, дающем прямой доступ к памяти. В том числе и на C# в unsafe режиме.
Если говорить о преимуществах по быстродействию над .net'ом языков типа C, то очевидно надо рассматривать нормальную работу с данными на стеке, оптимизацию работы с памятью и вообще оптимизацию кода (полноценный инлайн, развертки и т.п.). По последним параметрам .net очень далеко отстаёт от современных компиляторов C/C++. Ну и если взять C++, то ещё дополнительно добавится МП времени компиляции, которое позволяет делать вообще не представимые в мире C# вещи. В итоге это всё сводится к существенному преимуществу в быстродействие. Бывает до 3-4 раз. Но никак не 20. Собственно большинство современных компилируемых языков укладываются в рамки отставания где-нибудь раз в 5... А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.
А вообще, выдвигая абсолютно правильный тезис об ущербности платформы .net в плане производительности (естественно в сравнение с C/C++), но при это аргументируя его такими странными цифрами и такими странными примерами, ты по сути дискредитируешь сам этот тезис...
Re[42]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_> Бывает до 3-4 раз.
Очень точное замечание. Бывает 3-4, а бывает и -2. В среднем немногим медленее, так как большая часть кода укладывается в тупой вызов методов по указателям. Дотнет не стоял на месте последние годы и кое-какие оптимизации сделали.
Остается основной гандикап — различные безопасные точки и барьеры записи которые снижают быстродействие на несколько процентов и которые никогда не получится устранить. С другой стороны выделение памяти в хипе тоже в разы быстрее. В итоге преимущество становится иллюзорным и слихвой покрывается существенно больше безопасностью кода и простотой программирования.
Что до МП времени компиляции, то тут Немерл рвет С++, как Тузик грелку. Так что это преимущество тоже стоит забыть.
_>А вообще, выдвигая абсолютно правильный тезис об ущербности платформы .net в плане производительности (естественно в сравнение с C/C++), но при это аргументируя его такими странными цифрами и такими странными примерами, ты по сути дискредитируешь сам этот тезис...
В целом готов согласиться, только твоя оценка тоже приукрашена. 3-5 раз — это в худшем случае. Возможно, есть совсем клинические случаи, где можно и больше отставание получить. У плюсов и сей действительно есть некоторые преимущества в области оптимизации, но чем за это приходится платить? Надежность, временем необходимым на доведение кода до качественного состояния, сложностью в дизайне и т.п. В среднем же, если не заниматься вылизыванием каждой строчки кода, то оставание дотнета не превысит и двух раз. Реальный средний гандикап измеряется процентами. Ну, а там где нужно вылизать есть ансэйф и даже С/С++. Но код на них, лично я, предпочитаю не писать вручную, а генерировать по модели. А модель и генератор кода куда удобнее делать на Немерле.
Кстати, в нашем текущем проекте производительность очень критична. Возможно кода-то мы прибегнем к генерации сишного кода, или даже к генерации машинных кодов (так как там гибкость еще больше выходит, а что генерировать особой рояли не имеет. Но, как всегда бывает, есть куча куда более важных задач. Так что когда мы этим займемся, и займемся ли вообще, неизвестно. В конце концов инкрементальный парсинг даст куда более стабильное и существенное ускорение при редактировании файлов, нежели оптимизации которые может выжать хороший компилятор С++.
В общем, призываю разумно подходить к вопросу производительности генерируемого кода. Скорость дотнета не айс, но ее вполне хватает для вычислительных задач.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Очень точное замечание. Бывает 3-4, а бывает и -2. В среднем немногим медленее, так как большая часть кода укладывается в тупой вызов методов по указателям. Дотнет не стоял на месте последние годы и кое-какие оптимизации сделали.
Вообще то даже если бы и просто в 2 раза, то это тоже более чем серьёзно для многих задач, но на самом деле картина совсем другая. Я делал разные тесты... C# и Java дают существенное стабильное отставание. А вот unsafe C# даёт совсем другие цифры, которые достаточно близки к цифрам C++ (т.е. на самом деле отставание совсем небольшое, заметно меньше даже коэффициента 2).
Кстати, а в Nemerle unsafe работает?
VD>Остается основной гандикап — различные безопасные точки и барьеры записи которые снижают быстродействие на несколько процентов и которые никогда не получится устранить. С другой стороны выделение памяти в хипе тоже в разы быстрее. В итоге преимущество становится иллюзорным и слихвой покрывается существенно больше безопасностью кода и простотой программирования.
А вот насчёт выделения памяти — это точно миф. Причём довольно известный и старый. Он был придуман ещё любителями Java, когда они типа нашли один специфический пример, на котором Java код опережает C/C++. На самом деле фокус конечно же заключается в оригинальном написание C/C++ примера, которое ни один профессионал в нём не сделает. Сейчас поясню в деталях. В большинстве случаев в реальных задачах мы встречаем или выделение отдельных небольших объектов (в C++ принято для этого использовать стек — обычно на голову быстрее всех остальных) или же сразу больших блоков/массивов (тут у большинства нормальных языков будут одинаковые цифры). Однако есть ещё один довольно специфический случай — выделение (и главное удаление!) большого числа отдельных мелких объектов. Если решить эту задачу с помощью банального new/delete, то она действительно будет несколько отставать от реализации на Java/C#. Только вот фокус в том, что никто в своём уме не будет писать подобный код на C++, а применит для этой задачи аллокатор на пуле (который опять же окажется на голову быстрее варианта на Java/C#). Да, для тех, кто не особо в курсе C++ и подумал сейчас о каких-то проблем с нестандартным выделением памяти, написанием велосипедов и т.п., напомню, что все стандартные библиотеки C++ поддерживают указание пользовательского аллокатора. Ну и готовая эффективная реализация такого алллокатора на пуле тоже уже давно имеется в стандартных библиотеках. В общем в итоге, стандартные средства C/C++ заметно эффективнее на большинстве задач. А для одной специфической задачи, где это не так, тоже имеется готовое решение (которое опять же заметно эффективнее). Но некоторые "умные" товарищи проводят тестирование понятно как и соответственно получаем данный известный миф.
VD>Что до МП времени компиляции, то тут Немерл рвет С++, как Тузик грелку. Так что это преимущество тоже стоит забыть.
Это безусловно так, но мы же сравниваем один мейнстрим язык (C++) с другим мейнстрим языком (C#) и здесь у C# вообще нечего предъявить для сравнения. А если сравнивать уже не мейнстрим, то сразу же вспоминается D, у которого тоже весьма не плохое МП и при этом быстродействие на уровне unsafe C#.
Но на самом деле и C++ понемногу продвигается вперёд. Как тебе например такой http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc примерчик?)
VD>В целом готов согласиться, только твоя оценка тоже приукрашена. 3-5 раз — это в худшем случае. Возможно, есть совсем клинические случаи, где можно и больше отставание получить. У плюсов и сей действительно есть некоторые преимущества в области оптимизации, но чем за это приходится платить? Надежность, временем необходимым на доведение кода до качественного состояния, сложностью в дизайне и т.п.
Нет, это всё касается языка C. А современный C++ совсем другой. Он позволяет писать код с такой же скоростью и удобством, как и C# и при этом даже более надёжный (за счёт стремления к проверкам времени компиляции, а не времени исполнения). Но и конечно же цена за всё это тоже есть, только у современного C++ она заключена совсем в ином. Его проблема в том, что для решения одной и той же задачи требуется программист на C# одного уровня (допустим невысокого) и программист на C++ совсем другого уровня (заметно выше). Ну а в современном мире гораздо чаще оказывается дешевле купить железо помощнее, чем найти высокоуровнего специалиста.
VD>В среднем же, если не заниматься вылизыванием каждой строчки кода, то оставание дотнета не превысит и двух раз. Реальный средний гандикап измеряется процентами. Ну, а там где нужно вылизать есть ансэйф и даже С/С++. Но код на них, лично я, предпочитаю не писать вручную, а генерировать по модели. А модель и генератор кода куда удобнее делать на Немерле.
Генерация — это уже совсем другое дело. И я пока не встречал инструмента с эффективной реализаций подобного. Т.е. просто какие-то генераторы периодически встречаются (ну скажем какие-нибудь там доступы к БД по xml схемам и т.п.), а вот чтобы с упором на быстродействие...
VD>Кстати, в нашем текущем проекте производительность очень критична. Возможно кода-то мы прибегнем к генерации сишного кода, или даже к генерации машинных кодов (так как там гибкость еще больше выходит, а что генерировать особой рояли не имеет.
Тут разница заключается в том, что для второго варианта надо обладать знаниями о всячески нюансах работы каждого поколения ведущих процессорных архитектур. Вот например лично я бы не взялся за решение такой задачи, хотя более менее в курсе многих железячных нюансов.
VD>В общем, призываю разумно подходить к вопросу производительности генерируемого кода. Скорость дотнета не айс, но ее вполне хватает для вычислительных задач.
Нууу это кому как. Я тебе ещё несколько лет назад говорил, что в принципе Nemerle может быть интересен нам, но только при условие наличия полноценной нативной реализации — .net нам не походит вообще никак по целому ряду причин. Ты тогда ещё сказал что в принципе Nemerle не завязан на .net, так что в недалёком будущем такое возможно. Однако насколько я понимаю, за все эти годы подобное будущее ещё даже не начало приближаться?
Re[41]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.
Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз".
И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим.
Re[12]: Nemerle через 5 лет - выстрелит или скончается?
ARK>>Просто высказал свое мнение. VD>А кому здесь нужно мнение человека не знающего предмета обсуждения? VD>Как бы, люди говорящее — "не нужен" ненужны.
Да ты просто бог маркетинга
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[43]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>Здравствуйте, alex_public, Вы писали:
_>>А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.
BC>Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз". BC>И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим.
Да, будет быстрее, но какой ценной ?
Ценной возможных трудноуловимых ошибок !
У всего есть эффективность затрат.
Есть места, где мы готовы пожертвовать производительностью в пользу легкого сопровождения, а есть места где мы готовы на возможность ошибиться, лишь бы работало быстро.
Здравствуйте, VladD2, Вы писали:
VD>С другой стороны выделение памяти в хипе тоже в разы быстрее.
В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++
VD>В итоге преимущество становится иллюзорным и слихвой покрывается существенно больше безопасностью кода и простотой программирования.
VD>У плюсов и сей действительно есть некоторые преимущества в области оптимизации, но чем за это приходится платить? Надежность, временем необходимым на доведение кода до качественного состояния, сложностью в дизайне и т.п. В среднем же, если не заниматься вылизыванием каждой строчки кода, то оставание дотнета не превысит и двух раз. Реальный средний гандикап измеряется процентами. Ну, а там где нужно вылизать есть ансэйф и даже С/С++.
Вот только нужно не забывать, что C++ это не только преимущества в скорости, но ещё и в гибкости.
На C# — шаг влево, шаг вправо и упираешься в забор
auto add = [](auto x, auto y)
{
return x + y;
};
auto sub = [](auto x, auto y)
{
return x - y;
};
auto apply = [](auto f, auto... args)
{
return f(args...);
};
print(apply(apply, apply, apply, add, 1, 2));
print(apply(apply, apply, sub, 11, 2));
На C# будет облом.
И, что-то мне подсказывает, если это и получится на Nemerle, то не так складно, ибо система типов .NET — примитивней
Ожидаю блаб-объяснений что это и не нужно, потому что можно без этого
Здравствуйте, _NN_, Вы писали:
BC>>Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз". BC>>И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим. _NN>Да, будет быстрее, но какой ценной ? _NN>Ценной возможных трудноуловимых ошибок !
Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.
Re[45]: Nemerle через 5 лет - выстрелит или скончается?
_>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.
К сожалению, чтобы этого добиться в С++ нужно гораздо больше понимать чем в C#.
И научить людей всем нюансам гораздо сложнее, ведь многое в понимании приходит только с опытом.
Например я нигде не видел у нас в коде использование vector::at для проверок границ.
А вот ошибка потенциально имеет место быть если не будет ревью или обработки статического/динамического анализатора.
