Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Это всё к тому, что твой пример с copy&paste вот этого: V>>>
V>>>where(x => x > q)
V>>>
V>>>в общем случае является плохой практикой. V>>>Но язык позволяет только такую. S>> Чем это плохо?
V>Тем, вестимо, что в каждом конкретном месте можно допустить ошибку. V>По сей причине и рождается "матрица специализаций", типа этой. V>По ссылке автогенерённый код. В этом смысле С++ позволяет выполнять такую кодогенерацию прямо в исходниках.
И ты тудаже. Ты мои ссылки вообще игнорируешь? По приведенной ссылке прежде много кода генерится всего из за того, что код не инлайнится.
Я привел тебе ссылки где методы инлайнятся и нет разницы между value и ref типами
S>>В С++ зря штоли ввели Лямбды?
V>Моя рука потихоньку тянется к лицу. ))
V>Давай сделаем паузу и посмотрим на это всё повнимательней. Лямбды хороши исключительно и только для уникальных случаев, в этом и состоит их ЦЕЛЕВАЯ фишка — они же захватывают текущий контекст! Т.е., твоё x => x > q — это ж вовсе не лямбда (вот почему рука дрогнула в направлении лица), это ж у тебя просто некая "маленькая процедура", которая использует возможность локального объявления процедур (лямбд), не используя при этом их основной механизм. Вполне же можно было объявить такой предикат вне контекста использования, верно? Т.е., получилась лишь некая экономия сугубо на "оформлении" такого предиката в виде отдельной ф-ии.
А что же это такое? Лямбда, замыкание, который может захватывать и внутренние переменные например
var f=5;
roslyn-linq-rewrite
This tool compiles C# code by first rewriting the syntax trees of LINQ expressions using plain procedural code, minimizing allocations and dynamic dispatch.
Example input code
public int Method1()
{
var arr = new[] { 1, 2, 3, 4 };
var q = 2;
return arr.Where(x => x > q).Select(x => x + 3).Sum();
}
Allocations: input array, array enumerator, closure for q, Where delegate, Select delegate, Where enumerator, Select enumerator.
Decompiled output code
public int Method1()
{
int[] arr = new[] { 1, 2, 3, 4 };
int q = 2;
return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
if (_linqitems == null) throw new ArgumentNullException();
int num = 0;
for (int i = 0; i < _linqitems.Length; i++)
{
int num2 = _linqitems[i];
if (num2 > q)
num += num2 + 3;
}
return num;
}
V>Т.е., речь о том, что неуникальный случай в C# описать не так-то просто (тем паче с должной эффективностью).
S>>То есть я могу использовать любой дженерик делегат .
V>Не можешь. В теле дотнетной лямбды происходит автовывод типов, поэтому ты вызываешь методы конкретных типов. А для реализации предиката в виде генерика исходные типы должны поддерживать некие данные ЗАРАНЕЕ ограничения на шаблонах или использовать т.н. "объекты-словари операций", навроде IComparer<T>, который в свою очередь может оперировать лишь типами, над которыми ПРЕДВАРИТЕЛЬНО заданы некие ограничения в виде опять и снова интерфейсов.
И что мне мешает объявить метод?
bool MyMetod<T>(T x)
S>>Просто лямбды удобнее как для написания так и для чтения, а так же для оптимизации компиляции
V>Конечно удобны. Но я на это тоже уже отвечал заранее: V>
V>Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.
V>С++ позволяет комбинировать технику шаблонов и лямбд, используя каждую из техник по прямому назначению, т.е. заставляя их выполнять исключительно "свою" часть работы.
Это же все можно делать и на C#
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Встречается часто, и вносят значительный вклад, но для типичных корпоративных "операционных дней" и "всё в базу упирается" это действительно не критично.
Да если бы оперднями все ограничивалось
Зайди на любой веб сайт — там тоже "все в базу и хттп упирается". Вон, даже на мобильных девайсах жава и замарин отлично себя чувствуют, андроид так тот весь на жаве написан. А если посчитать сколько человекочасов сохраняют управляемые языки, так уж действительно оказывается что С++ нужен в очень ограниченных случаяъ. А если нужен то проще сделать длл-ку дял критического куска и прикрутить ее к управляемому решению, чем городить целый огород на этом убожестве.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, lpd, Вы писали:
lpd>>Соглашусь, что ее нужно учитывать — в тех случаях, когда доступ последовательный и когда задержки обращения к памяти вносят значительный вклад в общее время. Однако, если говорить о типичных клиент-серверных приложениях на C#/Java, то там подобное встречается не столь часто
EP>Встречается часто, и вносят значительный вклад, но для типичных корпоративных "операционных дней" и "всё в базу упирается" это действительно не критично.
Все-таки думаю, что ты несколько переусложняешь. Я тут перевел на java функцию, вычисляющию DCT(Исходный код java и C++ в конце поста). В данном случае я не старался получить правильный алгоритм — это лишь является тестом вычислений.
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
c++ -O3 -std=c++14 -o dct dct.cpp (clang++ почему-то дал плохой результат)
C++:
1083590667ns
68
Java:
java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
javac dct.java
java dct
2870287311ns
68
И без всякой индирекции на одних float'ах, int'ах и массивах получил разницу в 3 раза. Могу поверить, что косвенность вносит свой вклад, но решающий не он.
Здравствуйте, itslave, Вы писали:
I>Хосспади, вы про эту про эту долбаную производительности числодробилок заманали писать в каждом мосте. Не нужна эта производительность в реальной жизне чуть менее чем никогда. Понимаешь — оно не нужно, даже забесплатно.
Во-первых, это ложь.
Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен.
Re[29]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>Во-первых, это ложь.
что именно ложь? Потрудитесь высказывать свои мыли яснее (с)
ARK>Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен.
Проблема кора в том, что он сырой. И ее достаточно оперативно решают. Время покажет, нужен ли он, сейчас об этом говорить мягко говоря преждевременно.
Re[30]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
ARK>>Во-первых, это ложь. I>что именно ложь? Потрудитесь высказывать свои мыли яснее (с)
Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны.
ARK>>Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен. I>Проблема кора в том, что он сырой. И ее достаточно оперативно решают. Время покажет, нужен ли он, сейчас об этом говорить мягко говоря преждевременно.
Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет.
Re[31]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны.
имя, сестра(тьху, брат), имя...
ARK>Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет.
тройной, не пятерной фейспалм. Хинт: кроссплатформенность, есть такое слово...
Re[32]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
ARK>>Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны. I>имя, сестра(тьху, брат), имя...
Игры, например.
ARK>>Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет. I>тройной, не пятерной фейспалм. Хинт: кроссплатформенность, есть такое слово...
Нда уж. И правда фейспалм. А жаба у нас давно нативная? Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия. Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие.
Re[33]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>Игры, например.
Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет
ARK>Нда уж. И правда фейспалм. А жаба у нас давно нативная?
Она кроссплатформенная. А .NET до core таким не был. Твой КО.
ARK>Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия.
О, я то и не знал, то вот тот же самый КО подсказывает что все пофик на нативность
ARK>Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие.
Та ты шо? Прикинь, вот даже в тупом мелкософте до этого доперли и.... сделали .net core
Здравствуйте, itslave, Вы писали:
ARK>>Игры, например. I>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет
Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована.
ARK>>Нда уж. И правда фейспалм. А жаба у нас давно нативная? ARK>>Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие. I>Она кроссплатформенная. А .NET до core таким не был. Твой КО. I>Та ты шо? Прикинь, вот даже в тупом мелкософте до 4того доперли и.... сделали .net core
По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо. Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
Собственно, это и очевидно, что кор делается в первую очередь ради производительности, а все остальное — сбоку припеку.
Так шта, возвращаясь к началу беседы... Ежели
Не нужна эта производительность в реальной жизне чуть менее чем никогда. Понимаешь — оно не нужно, даже забесплатно.
то и Core нафиг не нужен тогда.
ARK>>Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия. I>О ято и не знал, то вот тот же самый КО подскащывает что все пофик на нативность
Че-то я эту фразу не распарсил.
Re[34]: Visual C# vs C++. Надо сравнить перспективы.
EP>Он плохо оптимизирует в том числе потому что управляемый код труднее оптимизировать. Например замыкания на C++ порождают обычные вызовы, а на C# косвенные.
Тут дело не в управляемом коде, а в противопоставлении "шаблоны vs раздельная компиляция". в плюсах, если хоцца отдельно скопилировать ФВП от кода её использущего — тут же скатываешся к std::function и той же самой косвенности вызовов.
Re[6]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Распространенное заблуждение. Дотнет не совсем то же самое, что джава, хотя и похож. Он, в отличие от нее, работает в среде ОС со своим рантаймом — CLR. Т.е., к примеру, без каких либо спецмостов управление может перейди из дотнетного кода в нативный и вернутся обратно в дотнетный, главное маршаллинг данных обеспечить.
Не понятно о каких отсутствующих спецмостах идет речь, если 99% "моста" это именно маршаллинг и есть. Я как-то делал эксперимент с наиболее популярным "мостом" — SWIG. JNI был ~30% быстрее. Не уверен в причинах, может явовский байндинг там лучше, может jit, может и то и другое.
AVK>Исключения тоже спокойно могут пролетать через такой смешанный стек,
Почитал здесь.Я правильно понимаю, что в .NET возможно лишь словить сам факт исключения? Понять что именно произошло в нативе возможности нет?
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
ARK>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо. Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
MS сейчас зарабатывают на Azure. А там как раз кроссплатформенность и нужна.
Кроме того .Net Core другая архитектура в том числе под Net Native.
То есть не только кроссплатформенность, но и скорость.
Из моно кстати много взято.
и солнце б утром не вставало, когда бы не было меня
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
I>>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет
ARK>Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована.
Еще раз перечитай то что я написал. Потом подумай. Повтори пока не дойдет.
ARK>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо.
Та ты просто кэп, даже не, майор, даже не, генерал очевидность. НО вот только у меня для тебя есть небольшое разочарование: никто абсолютно новый огород и не городит: просто портирует то что есть, ничо более.
ARK>Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
Ну ты хоть немного выучи матчасть, хотя бы базовые вещи, прежде чем рассуждать о танце маленьких лебедей. ARK>Собственно, это и очевидно, что кор делается в первую очередь ради производительности, а все остальное — сбоку припеку.
Главное что кроме тебя это никому не очевидно ARK>Так шта, возвращаясь к началу беседы...
Иди читай мануалы, а потом возвращайся.
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали: K>>Ну так-то Unity есть, весьма успешный...
ARK>Там C# вроде бы только один из языков, хотя на 100% не уверен. Ну и, выходит, нужна таки производительность-то, раз игры пишут.
Выходит то что производительность то удовлетворяет, раз игры пишут...
Признайся, тебе 20 лет уже исполнилось?
Re[36]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
I>>>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет ARK>>Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована. I>Еще раз перечитай то что я написал. Потом подумай. Повтори пока не дойдет.
Даже для C# нужна скорость, например для того, чтобы писать игры. Больше скорость — больше возможностей. Это как, доступно для понимания, или не совсем?
ARK>>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо. I>Та ты просто кэп, даже не, майор, даже не, генерал очевидность. НО вот только у меня для тебя есть небольшое разочарование: никто абсолютно новый огород и не городит: просто портирует то что есть, ничо более.
А новый компилятор — это не новое? Забавно.
ARK>>Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще. I>Ну ты хоть немного выучи матчасть, хотя бы базовые вещи, прежде чем рассуждать о танце маленьких лебедей.
Хм, ну и что я там должен увидеть?
Вот это?
The main point is to enable "native compilation" (so you don't need .NET framework/VM installed on the target machine.
Ну, это довольно очевидно...
To conclude:
.NET Core at present is not really portable, nor is is really cross-platform (in particular the debug-tools).
ARK>>Так шта, возвращаясь к началу беседы... I>Иди читай мануалы, а потом возвращайся.
Подредактирую изначальное сообщение и скажу более мягко. Не указывайте людям, что делать, и они не укажут вам направление движения.
Здравствуйте, itslave, Вы писали:
ARK>>Там C# вроде бы только один из языков, хотя на 100% не уверен. Ну и, выходит, нужна таки производительность-то, раз игры пишут. I>Выходит то что производительность то удовлетворяет, раз игры пишут...
Мда. А доцент-то тупой (с)
Пишут настолько, насколько язык позволяет. Будет позволять больше — будут писать и такие вещи, которые раньше писались на других языках.
I>Признайся, тебе 20 лет уже исполнилось?
Что, хорошо на корме рвануло, да?
Re[37]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>Даже для C# нужна скорость, например для того, чтобы писать игры. Больше скорость — больше возможностей. Это как, доступно для понимания, или не совсем?
Как уже мы выяснили в соседнем треде, скорей всего ты молод, а поэтому воинствующая глупость скорей всего может быть обьяснена недостатком опыта, образования, гормонами.. в общем как и у всех в молодости
Ну дык от, с учетом всего вышесказанного, разжую, как мне разжевывали.
Максимальный перфоманс может быть достигнут только в новых схемотехнических решениях. И за доказательствами ходить далеко не нужно, интегрированные процы на геймерских видеокартах на специфических задачах рвут i7 как тузик грелку. И любой дальнейший отход от схемотенических решений, как то: программирование в двоичных кодах, ассембелер, с, с++, управляемых языках — это сознательная жертва производительности в угоду другим критериям. Таким как: универсальность, скорость разработки, цена мейтененса, тестируемость и так далее. И на каждом этапе возникал вопрос о балансе: а не много ли мы перфоманса пожертвовали для того чтобы миллион тупых славян индусов смогли выдавать предсказуемый результат? И в случае с C# ответ очевиден: среда разработки, изначально таргетированная на рынок бизнес приложений внезапно стала востребованной и на рынке игр. Потому что перфоманса достаточно!
ARK>А новый компилятор — это не новое? Забавно.
Выход новой версии gcc — это канечна да, новый этап, знаменующий собой тотальный прогресс в С++7 пойду пацанам расскажу, посмеемся вместе
ARK>Хм, ну и что я там должен увидеть? ARK>Вот это? ARK>
The main point is to enable "native compilation" (so you don't need .NET framework/VM installed on the target machine.
ARK>Ну, это довольно очевидно...
Перечитай пока не дойдет.
ARK>Подредактирую изначальное сообщение и скажу более мягко. Не указывайте людям, что делать, и они не укажут вам направление движения.
о хосподи, как с вами пионерами смешно. Но впрочем, если ты не пионер, то ето уже грустно.