Здравствуйте, criosray, Вы писали:
C>и это заметно. Чистота вообще не шибко кого заботит в мире С++ и появляются на свет уродливые творения, где над каждой строкой кода надо раздумывать так же долго, как при чтении Ницше...
Лишь только NDA останавливает меня от постинга особо смачных кусков проекта на C# писанного индусами с гринкартой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
. S>Обращение не конкретно к ГВ, а к тем, кто пожелает защитить честь неуправляемого кода, или просто помочь человеку разобраться с тем, что он делает не так.
Да что там защищать-то? Там одна fprintf чего стоит — она сама по себе тормоз ещё тот.
S>Кстати, это далеко не первый случай выбора платформы по бенчмарку Дело даже не в бенчмарке, а в том, _какие_ специалисты делают эти бенчмарки и принимают потом решения.
[шутка on]
Да-да! Вот у _таких_ специалистов-то .Net и оказывается шустрее всего вокруг.
[шутка off]
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
ГВ>>Э... Тогда поясни, что имеется в виду под низким уровнем? __asm, void*, арифметика указателей или вообще любые упоминания указателей? G>1)Ручное управление памятью, надо следить чтобы указатель нигде не повис. Использовать умные указатели или следить чтобы везде вызывался delete G>2)Арифметика указателей, надо следить чтобы использовались STL-ные итераторы вместо указателей G>3)Даже с бустом сложные лямбды надо формировать кучей методов bind. G>4)Небезопасные приведения типов G>продолжать можно долго...
Понятно. Справедливости ради:
— арифметикой указателей можно и не пользоваться;
— bind — это уже не низкий уровень;
— правильные приведения типов (не через static_cast<void*>) никаких нежданных побочных эффектов не имеют.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Э... Тогда поясни, что имеется в виду под низким уровнем? __asm, void*, арифметика указателей или вообще любые упоминания указателей? G>>1)Ручное управление памятью, надо следить чтобы указатель нигде не повис. Использовать умные указатели или следить чтобы везде вызывался delete G>>2)Арифметика указателей, надо следить чтобы использовались STL-ные итераторы вместо указателей G>>3)Даже с бустом сложные лямбды надо формировать кучей методов bind. G>>4)Небезопасные приведения типов G>>продолжать можно долго...
ГВ>Понятно. Справедливости ради:
Ты опыть не понял о чем тебе толкуют.
ГВ>- арифметикой указателей можно и не пользоваться;
Можно и С++ не пользоваться.
А если пользоваться С++, то постоянно следить чтобы нигде не накосячить, чтобы не использовать арифметику указателей вмето итераторов, чтобы не использовать обычны указатели вместо умных итп.
В нормальных языках за этим следит компилятор и рантайм. В C# для работы с указателями программист должен описать это явно. А вызывающий код может отказаться вызывать, то что небезопасно.
ГВ>- bind — это уже не низкий уровень;
Очень низкий. Связыванием должен заниматься компилятор, а не программист. Для простых типов и арифметических операция в C++ этого удалось добиться, а для всех остальных — нет.
ГВ>- правильные приведения типов (не через static_cast<void*>) никаких нежданных побочных эффектов не имеют.
Введение дополниельных конструкций для "правильного приведения типов" уж точно не свидетельствует о высокоуровневости языка.
В остальном аналогично указателям.
?
Хочу. Код также свидетельствует о черезмерной низкоуровневости С++. Метаинформацией о типах дожен заниматься рантайм, а не программист.
Все остальное — действительно задача, которая решается неочень опытным программистом в короткое время.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Я писал такой тест в этой теме, смотри выше, C++ слил в 3-6 раз. Это без шаред птр G>>А потом прибежали другие и начали рассказывать что они динамическую память не выделяют и создают все на стеке CC>Ты мерял там на самом деле разницу в производительности GC и WinAPI функции HeapAlloc. CC>А никак не работу с shared ptr.
Ну а shared_ptr вносит дополнительный оверхед.
G>>Ответь на вопрос, нафига MAPI в .NET? CC>Вот хочется ему. Представь что он заказчик и ему надо именно MAPI.
Если заказчик диктует технические решения, то я с таким не связываюсь. И другим не рекомендую.
G>>Возьми DLL, скомпилированную Intel C++ Compiler и напиши в visual studio код, который создает объект из этой либы — придет понимание. CC>ICC манглит имена так же как и визжалка. Так что никаких проблем не ожидается.
И что, можно прямо так просто взять и создать объект, реализация которого лежит в другой DLL?
Здравствуйте, gandjustas, Вы писали:
ГВ>>Понятно. Справедливости ради: G>Ты опыть не понял о чем тебе толкуют.
Понял, только не согласен с оценкой перечисленных фич, как низкоуровневых.
ГВ>>- арифметикой указателей можно и не пользоваться; G>Можно и С++ не пользоваться. G>А если пользоваться С++, то постоянно следить чтобы нигде не накосячить, чтобы не использовать арифметику указателей вмето итераторов, чтобы не использовать обычны указатели вместо умных итп. G>В нормальных языках за этим следит компилятор и рантайм. В C# для работы с указателями программист должен описать это явно. А вызывающий код может отказаться вызывать, то что небезопасно.
Мне кажется, ты дуешь на воду. Проблема выбора, конечно, существует, но я не склонен считать её чем-то слишком трудным. Но, в любом случае, твоё мнение мне теперь понятно.
ГВ>>- bind — это уже не низкий уровень; G>Очень низкий. Связыванием должен заниматься компилятор, а не программист. Для простых типов и арифметических операция в C++ этого удалось добиться, а для всех остальных — нет.
Ну вот уже ты, по-моему, путаешься. Описанием связывания в любом случае занимается программист. И потом, bind — это, в общем-то, не полноценные лямбды, как ни крути. Показательно то, что на C++ их можно реализовать.
ГВ>>- правильные приведения типов (не через static_cast<void*>) никаких нежданных побочных эффектов не имеют. G>Введение дополниельных конструкций для "правильного приведения типов" уж точно не свидетельствует о высокоуровневости языка. G>В остальном аналогично указателям.
Как раз строго наоборот. xxxxx_cast потому и сделаны такими, чтобы указать на неправильность подобных приведений. Естетсвенные приведения (от наследника к родителю) выполняются прозрачно, без дополнительных инструкций.
ГВ>>P.S.: Не хочешь высказаться по IoC
? G>Хочу. Код также свидетельствует о черезмерной низкоуровневости С++. Метаинформацией о типах дожен заниматься рантайм, а не программист.
А где ты там метаинформацию нашёл?
G>Все остальное — действительно задача, которая решается неочень опытным программистом в короткое время.
+1
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>>>Ответь на вопрос, нафига MAPI в .NET? CC>>Вот хочется ему. Представь что он заказчик и ему надо именно MAPI. G>Если заказчик диктует технические решения, то я с таким не связываюсь. И другим не рекомендую.
Заказчик сам может быть вынужден диктовать технические решения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>- арифметикой указателей можно и не пользоваться; G>Можно и С++ не пользоваться. G>А если пользоваться С++, то постоянно следить чтобы нигде не накосячить, чтобы не использовать арифметику указателей вмето итераторов, чтобы не использовать обычны указатели вместо умных итп. G>В нормальных языках за этим следит компилятор и рантайм. В C# для работы с указателями программист должен описать это явно. А вызывающий код может отказаться вызывать, то что небезопасно.
В пору, когда я писал на C++ мне были абсолютны чужды и непонятны лозунги о безопасности управляемого кода. У меня в руках был мощный инструмент, использовать который я знал как (к сожалению, в прошедшем времени). Тогда казалось: неумеешь писать надежный код на небезопасном языке — не берись, а умеешь — так если что, все под рукой.
Теперь я немного другого мнения о безопасности кода: Это как ABS! Если умеешь эффективно пользоваться тормозами и регулярно оттачиваешь свои навыки — ABS не нужен. Если ездишь из точки A в точку B без жажды адреналина, или за руль эпизодически садится жена — лучше бы ABS иметь чем не иметь. Пристегиваешь ремень безопасности, потому как не уверен за джигитов, которые носятся вокруг.
И убеждать водителей, не привыкших к ABS, что они без ABS не смогут ездить, дохлый помер...
Так и с unsafe кодом. Боишься не за себя, а за соседа, у которого нет нужных навыков. А раз компилятор ограничивает от потенциально опасных действий всех одинаково, можно внимание, необходимое для контроля за этим, направить в другое русло.
Здравствуйте, COFF, Вы писали:
S>>Дело не в том как написано и что тестируется и даже не в конкретном экспериментаторе (который думает что разница в контроле типов в рантайме), а в интерпретации результата. S>>Победил C# — недоумение S>>Победил С++ — значит C# — тормоз
COF>Не, ну все правильно. Победил C# значит надо разбираться где в C++ коде косяк
Совершенно верно. И пока программисты С++ ищут очередной косяк, программисты С# сдали проект в продакшн и занялись другим, получив свою денюжку.
Здравствуйте, COFF, Вы писали:
ГВ>>>Да он почти всегда к одному сводится: к куче вложенных вызовов "абстрактных слоёв". G>>И что? 2-3 виртуальных вызова вообще незаметны будут ни при каком раскладе. G>>Давай конкретно, о каком penality идет речь?
COF>Так скажем, не будут заметны в большинстве случаев. Однако, опираясь на практику как критерий истины , я могу однозначно сказать, что не только виртуальные, но и обычные вызовы влияют на производительность. Проверяется это очень просто — я интенсивно использую инлайны в проектах на C++, так вот время отклика для релизной версии в несколько раз (если не на порядок) лучше чем в отладочной — скажем 40-50 мс и 300-400 мс. Что это значит для пользователя я думаю объяснять не надо. Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает. На C++ так извращаться не надо — в итоге программы получаются эффективными, но асбсолютно не теряют в читаемости.
Сложно потерять то, чего изначально не было.
COF>В принципе, это была изначальная цель при создании C++ и она с успехом достигнута.
Достигнута.
COF>У C++ конечно есть недостатки и наверное можно придумать язык лучше, но по моему проблема в том, что вместо лучшего навязывается другое. Скажем, лисп — это отличный язык, но он не лучше и не хуже C++, он просто другой. То же самое с C# и явой.
Ну давайте разовьем мысль:
С++ не лучше Паскаля — он просто другой
С++ не лучше Бейсика — он просто другой
...
Вы хоть понимаете, что это демагогия и софистика? Да С++ не лучше лиспа, а хуже. С++ не лучше С#, а хуже. С++ не лучше явы, а хуже. Если Вы скажете что это тоже демагогия, то будете правы потому, что любое сравнение не имеет смысла, если проводится в отрыве от контекста реальных задач программиста, и если не указаны критерии сравнения.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Кто это тут защищал использование C++ там, где он не подходит должным образом? По-моему, тебе померещилось. Разговор идёт о гротескной преувеличенности недостатков C++ и о том, что в некоторых ситуациях он оказывается наилучшим выбором. G>>Очень мало таких ситуаций. На практике оказывается что там где подходит С++ на самом деле нужно что-то вроде C_ _ классами. Высокоуровневые абстакции С++ идут лесом, упор делается на вычисления.
ГВ>По чьей практике так оказывается?
Здравствуйте, COFF, Вы писали:
COF>Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает.
А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций?
А то страшно стало! Быстрее всё всё всё в main переношу...
Здравствуйте, MxKazan, Вы писали:
COF>>Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает. MK>А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций?
+1 Сколько лет на дотнет пишу, а впервый раз слышу такое.
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, COFF, Вы писали:
COF>>Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает. MK>А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций? MK>А то страшно стало! Быстрее всё всё всё в main переношу...
Продолжу: вместо свойств публичные поля, использовать только структуры (на классы и GC — табу), которые выделять только на стеке, или в крайнем случае распределенные с помощью самописного аллокатора (массив структур тоже не пойдет, т.к. проверяет диапазон индекса). Все методы только статические, в них структуры передавать через ref параметр, дабы избежать копирований на стеке, ну и на всякий случай все под /unsafe компилить.
Чуть не забыл выкинуть все циклы foreach, а все остальные переписать в манере
for (i/*глобальная переменная*/ = items.Count -1; i >= 0; --i /*непременно префиксная форма*/)
Если кто так не сделает, то его код будет работать медленнее, чем C++ и ему никак не догнать плюсы по перфомансу, что означает конец карьеры программиста
Здравствуйте, MxKazan, Вы писали:
MK>А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций? MK>А то страшно стало! Быстрее всё всё всё в main переношу... :user:
Пожалуйста, не поленился и специально нашел такой пример
Здравствуйте, samius, Вы писали:
S>Если кто так не сделает, то его код будет работать медленнее, чем C++ и ему никак не догнать плюсы по перфомансу, что означает конец карьеры программиста :(
На самом деле, это все (и еще много чего другого) я делаю когда пишу на C++, если надо написать действительно быстрый код. То что Вас это забавляет показывает только то, что с задачами, критичными по скорости Вам сталкиваться не приходилось. Увы...
Здравствуйте, COFF, Вы писали:
COF>Здравствуйте, MxKazan, Вы писали:
MK>>А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций? MK>>А то страшно стало! Быстрее всё всё всё в main переношу...
COF>Пожалуйста, не поленился и специально нашел такой пример
COF>http://www.cnblogs.com/jerryzhao/archive/2007/08/29/873986.html
COF>One of the ways in which you can improve the performance of loading a form is by reducing the number of method calls made during form initialization.
Оттуда же
This application was built using the Release profile and deployed to the Pocket PC 2002 emulator, where it was run 5 times.
Под покетом походу надо и на длине названий методов экономить
Здравствуйте, COFF, Вы писали:
MK>>А можно ссылку на эту рекомендацию писать как можно меньше маленьких функций? MK>>А то страшно стало! Быстрее всё всё всё в main переношу...
COF>Пожалуйста, не поленился и специально нашел такой пример
COF>http://www.cnblogs.com/jerryzhao/archive/2007/08/29/873986.html
COF>One of the ways in which you can improve the performance of loading a form is by reducing the number of method calls made during form initialization.
Раз: Improving Microsoft .NET Compact Framework-based Application Form Load Performance
Два: March 2002
Три: Microsoft® .NET Compact Framework 1.0
S>>Если кто так не сделает, то его код будет работать медленнее, чем C++ и ему никак не догнать плюсы по перфомансу, что означает конец карьеры программиста
COF>На самом деле, это все (и еще много чего другого) я делаю когда пишу на C++, если надо написать действительно быстрый код. То что Вас это забавляет показывает только то, что с задачами, критичными по скорости Вам сталкиваться не приходилось. Увы...
Быстрый код получается не тогда, когда Вы тратите 90% времени на техническую оптимизацию кода и 10% на алгоритмизацию, а 90% на алгоритмизацию, 10% на техническую оптимизацию.
Здравствуйте, COFF, Вы писали:
COF>Здравствуйте, samius, Вы писали:
S>>Если кто так не сделает, то его код будет работать медленнее, чем C++ и ему никак не догнать плюсы по перфомансу, что означает конец карьеры программиста
COF>На самом деле, это все (и еще много чего другого) я делаю когда пишу на C++, если надо написать действительно быстрый код. То что Вас это забавляет показывает только то, что с задачами, критичными по скорости Вам сталкиваться не приходилось. Увы...
Возможно не в той степени, что Вам...
Предпочитаю другие методы оптимизации. В тех задачах, с которыми я сталкивался их хватало. До экономии на минимизации кол-ва методов не доходило. (Заменять вызовы через интерфейс в дотнете на другие вызовы — приходилось)
Дело даже не в бенчмарке, а в том, _какие_ специалисты делают эти бенчмарки и принимают потом решения.
