Только надо добавить, что на месте этого "языка высокого уровня" на самом деле выступало не какое-то поделие C++-ненавистников, а самый что ни на есть Lisp. А разброс между возможностями Lisp и языками вроде Java, C++, C# гораздо больше, чем разброс внутри этой троицы. Так что, с технической точки зрения результат был бы одним и тем же, перепиши Яха свой магазин на C++ или на Java (C#, AFAIK, тогда ещё не было, но это ничего не меняет).
VD>Трансляции в С++ тут вообще не причем. Это не более чем способ оптимизировать производительность разных интерпретируемых сред. Для дотнета и явы он имеет мало смысла. К тому же при этом глупо генерировать С++-код. Куда разумнее генерировать С-шный код. Переносимость выше и практически нет неявного оверхэда. А все возможности С++ для генерированного кода на фиг не упали.
Оверхэд C++ по сравнению с C — это миф, тут, скорее, всё обстоит ровно наоборот: например, декларации inline в C нет, сгенерировать шаблонный код для C тоже нельзя. Так что, выбор выглядит не таким уж неразумным. Впрочем, деталей я не знаю, могу только догадываться.
VD>Так что не обольщайся. С++ популярнее не станет. Он живет по инерции.
Популярность C++ меня, прямо скажем, не волнует. А что до инерции — так это очень большой плюс языка, если он обладает такой инерцией: это означает, что программы, разработанные на нём, удовлетворяют многим требованиям на протяжении долгого времени, а новые языки не дают настолько значимых преимуществ, чтобы кинулись всё на них переписывать. Отличный знак, надо сказать!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
В догонку, для дотнета существует еще одно ограничение, которое я даже не представляю, как обойти. Например, после оптимизации link-time codogeneration в С++ полученная программа в некоторых местах будет очень не похожа на исходную, целые типы и даже иерархии с виртуальными вызовами растворяются в небытие и структуры данных корежатся до неузнаваемости после этого акта зачаточной суперкомпиляции. А в дотнете встанет проблема привязать имеющуюся метаинформацию к такой "другой" оптимизированной программе, что может создать сложности для доступа к объектам через рефлексию. Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.
Т.е. сама необходимость обеспечивать рантайм рефлексию накладывает серьезные ограничения на трансформацию кода и данных в процессе компиляции. Не зря когда-то в рамках Singularity пришли к тому, что в их специализированном компиляторе поддерживается только compile-time рефлексия.
Здравствуйте, AndrewVK, Вы писали:
KP>>А почему тогда приложения на плюсах работают быстрее?
AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++.
По крайней мере, .NET уже сколько существует, а приложений все нет и нет. Единственное приличное, что могу вспомнить, это Paint.NET, все остальное встреченное было, как правило, УГ
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>К разговорам о ренессансе C++.
ГВ>Чертовски любопытное выступление Герба Саттера "Why C++".
Это старые новости. Их уже давно обсосали, а ты только проснулся.
По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии.
В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией.
MS рванул из огня да в полымя. XAML и Silverlight не смогли дотянуть, давайте все на свете перепишем на С++ и HTML5. Ну и понятно, чем это закончится. Очередным рывком обратно в огонь, как показывает уже 20-летняя история развития MS технологий.
Здравствуйте, Геннадий Васильев, Вы писали:
I>>XML и большая часть языков в конфигах не обладают полнотой по тьюрингу. I>>99% софта не является нативным. В понятие "софт" включаем и все модули-плагны-аддоны-расширения и все сайты-сервисы и тд и тд какие только были написаны по сей день.
ГВ>Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?
Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.
Здравствуйте, Klatu, Вы писали:
K>Я пока что не встречал более пафосных говнокодеров, чем на С++. Вот это — точно медицинский факт. Каждое нубло, которое накропало пару примитивных программок на С++ — уже считает себя гуру
Брысь зелёный, еды не будет. Тоньше надо троллить, тоньше!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Видео не ахти и пока что я не смог найти расшифровки, может, кто знает, где она есть?
Вкратце, о чём оно.
— В 1999-2009 акцент в индустрии смещался с энергопотребления и энергоэффективности на производительность программистов и абстрактные игры (я бы назвал это явление A Momentary Lapse Of Reason — бывает, что там);
— Начиная с 2010 всё возращается на круги своя — начинают считать циклы/ватт потребляемой мощности (Саттер называет это Return of The King);
— Ну и собственно, о том, как возвращаются позиции C++ и в мобильных устройствах, и на серверах;
— И да, о том, как C++ поможет в борьбе с глобальным потеплением (ну куда ж без трололо? правда, это уже Страуструп).
По ходу он, конечно, проезжается по поводу того, что "All Windows API will be managed", ну и там ещё много такого троллинга, одно только "Coffe-based languages" чего стоит.
Есть ссылка на любопытный документ, озаглавленный, ни много ни мало: Dark Silicon and the End of Multicore Scaling (см. здесь). Там авторы делают не слишком утешительные выводы относительно перспектив роста производительности многопроцессорных систем в ближайшее время, что как бы символизирует.
В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Don Reba, Вы писали:
DR>>Был Evernote 3.5 написанный на WPF
AVK>С WPF разговор отдельный.
WPF/SL- единственная прогрессивная технология под зонтиком .NET (+ Mono конечно же). Все остальное- унылый веб к БД и обертки над доисторическим WinAPI, обертки над SQL, обертки над обертками над обертками
The JIT establishes write barriers that are triggered every time there is a write into a reference field in an object. If the value of the reference (which is basically a pointer, after all) is in the ephemeral segment (which is where gen0 and gen1 reside), the write barrier knows that it must update a global data structure, called a card table, with a bit that indicates that we might have a condition where a young object is referenced by an old object.
If every old object would have a bit in the card table, the card table would have been too big. Consider that the minimum object size is 12 bytes, and assuming that we can access about 1.6GB of memory for gen2, we can have up to 143 million objects, which would require almost 18MB of memory just for the card table to be properly synched. Therefore, the card table contains a bit for every 128-byte range, which requires a single DWORD for every page (4KB) on x86.
When a GC occurs, at a later point, it consults the card table to see whether there were any "dirty" writes to objects in an older generation, thus not allowing objects that are still referenced from an older generation to be incorrectly sweeped.
...
Every time the JIT sees that an update to a reference field is about to be emitted, it emits a call to the write barrier thunk. It can be examined using the SSCLI in the jithelp.asm file (for the x86 implementation). The code ensures that the address being written to (the destination) is in the GC heap, and then checks whether the address being written (the source) is within the ephemeral segment.
Note that whenever the ephemeral segment is moved, the JIT thunk must be updated to contain the correct segment low and high addresses.
...
The question I was talking about, then, is why doesn't the .NET GC use this built-in memory watch mechanism, supplied by the Win32 API? The following blog entry notes this possibility (in section 3.2.4), but does not elaborate regarding the reasons behind the particular choice made in .NET. I have several speculations (which are just that — speculations) and am still pursuing a more definitive answer:
* The aforementioned API is not supported on Windows 95 (which is, perhaps, not so surprising), but it is not supported on Windows 2000 as well. This would limit the .NET framework's compatibility with these platforms (although in those particular cases the JIT-thunk approach could be adopted).
* The aforementioned API is Windows-specific and does not provide any compatibility with other platforms. The JIT-generated write barrier is generic and theoretically can work on any platform.
* The performance penalty of using the MEM_WRITE_WATCH flag for writing to a region of memory is bigger than the thunk generated by the JIT. Note that a very primitive measurement I've performed indicates an 8% performance penalty when writing to memory protected by a write watch as opposed to writing to memory that is not protected by a write watch (don't quote me on this .
Эта механика, кстати, указывает на еще одну разновитность тормозов, связанную с GC — он не любит, когда очень много и часто пишутся ссылки. Но это, надо понимать, очень небольшие тормоза, вылазящие в весьма специфичных ситуациях.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
G>Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.
Тут одно утверждение и одно предположение. Оба неверные. Толпы в EverNote никогда не было это точно.
По поводу WPF и .NET UI вообще.
UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap.
При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл.
Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.
Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.
Здравствуйте, gandjustas, Вы писали:
G>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.
Не, это уже дебри.
Весь хрен до копейки сводится вот к чему:
1. Бывают ошибки некорректного доступа к разделяемому состоянию
2. В С++ эти ошибки быстро ловятся потому, что программа зрелищно падает.
3. А в дотнете они ловятся долго потому, что программа падает незрелищно.
С пунктом первым спорить бессмысленно. В некоторых, особо упрощённых случаях, у нас есть способ поставить ограждающий забор — например, все контролы winForms выкидывают внятное исключение при попытке обращения не из того потока.
И стоило бы задуматься о способах построения такого ограждающего забора в более общем случае.
Но вместо этого оппоненты начинают обсуждать совершенно неинтересные вещи. Ну повезло г-ну ГВ с тем, что в его случае в двух потоках пробовали сделать delete, и это привело к зрелищному падению. Но ведь это — уникальное стечение обстоятельств; полагаться на него в диагностике багов — это как раз занимать позицию "сферического дотнетчика", который якобы преувеличивает частоту ошибок, связанных с проходом по памяти.
Значительно более весёлый класс ошибок случается тогда, когда никаких delete и в помине нет.
Вот, к примеру, был в моей давней java-практике случай, когда наша программа глючила совершенно неподетски. У матёрых разработчиков глаза лезли на лоб.
Оказалось, что в разных потоках использовались объекты, у которых один мембер (_socket) по ошибке оказался статиком.
И всё было в полном порядке — потому, что каждый поток думал, что сокет его, и спокойно писал себе в него свои данные. И сильно удивлялся, когда приходил всякий мусор.
Причём, понятное дело, в низкой нагрузке всё работало великолепно — даже если работало несколько потоков, каждый диалог с POP3-сервером успевал закончиться до того, как сосед влезет.
И вот такого рода баги не ловятся ни в плюсах, ни в дотнете — потому что нечему зрелищно ломаться.
Это возвращает нас к п.1 — как статически гарантировать отсутствие неверного доступа к разделяемому состоянию.
Ошибки реинтерпретации и прохода по памяти мы победили в самом начале.
Потом победили ошибки, связанные с опечатками в SQL-запросах и некорректной конкатенацией (см. тж. linq)
Теперь давайте займёмся этим отловом shared state access violation. Подход C++ — "если что и случится, то мы быстро это обнаружим по крэшу". Подход managed code — давайте придумаем среду, в которой такие ошибки невозможны в принципе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
Ткнешь в любой массовой продукт — везде дырки. Один только Геннадий Васильев красавчик и непризнанный лидер программизма, у которого все проблемы решаются на раз
Здравствуйте, Cyberax, Вы писали:
C>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью.
Здравствуйте, gandjustas, Вы писали:
G>в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью.
О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Ну это в unmanaged так, а в .NET как раз правильное использование immutable позволяет увеличить быстродействие слегка увеличив расход памяти, а также сделать код многопоточным.
К сожалению, когда код действительно многопоточный и выполняется на многих ядрах, то shared state опять зло, рулят только локальные, по отношению к потоку, данные. Причем, эти данные надо расположить в памяти так, чтобы их страницы не пересекались. На плюсах в таких структурах я использую padding м/у разделяемыми данными, который заведомо больше размера страницы памяти.
Возвращаясь к shared state. Прямое его использование, без padding, на моем 6-ти-ядернике как раз показывает почти 3-х-кратную разницу в минус (!!!), если случайно на той же странице лежат мутируемые данные. А если на каждый shared state заводить с обоих сторон большой padding, то слишком жирно по памяти, чаще всего проще получить и сохранить локальные копии данных.
V>>А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей? G>Может и там был, ведь пример не я придумал, а ГВ, а он как раз рассказал и показал все, кроме того места где собственно была ошибка.
V>>Какие ты еще знаешь способы реализации архитектур СМО, интересно? G>Что такое СМО?
А это такая штука, лишь для которой очереди в классике и нужны.
G>См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.
Где ты видел выставление за правило? Это был лишь контраргумент насчет того "а у вас программы падают!". Дык, плюсист всегда рад, когда нерабочая программа падает, а не продолжает делать вид, будто честно работает, как это принято в джаве и дотнете.
...посреди многослойной, переплетенной из еаров, сервисов,
коннекторов и пулов структуры сервера приложений, органично
врастая в сеть модульной архитектуры, выставив наружу
красивые интерфейсы, посылая и получая сообщения,
отвечая на эрэмай запросы, словно кипящий поток создавая
и уничтожая сотни ентити бинов в десятках распределенных
транзакций, мудрый сессионый бин срал в лог эксепшенами.
Смех-смехом, а сессионные объекты, как уже говорил рядом, это уровень 0 сложности, бо всё самое интересное делает низлежащая инфраструктура.
К тому же, наблюдал случай у коллег, что программа работала с ошибкой при какой-то там смене ситуации и клиент потерял энное кол-во тыщ нерусских денег за несколько минут... Лучше бы она просто упала нафик тогда. Но, к сожалению, ошибкой был не "проход по памяти и прочее из ада С++", а сугубо логическая ошибка.
G>Нет, баги еще бывают когда неправильно поняли что нужно сделать на каком либо этапе передачи данных от заказчика программисту. Но их тут мы не рассматриваем.
Не льсти себе. Баги просто "бывают", даже при идеальной спецификации и идеальном процессе. Даже у самых что ни на есть мегакрутейших сферических программистов. А у нас с тобой и подавно. Поэтому-то интерес предоставляют не сами баги или причины их появления (кроме систематических причин), а гораздо интереснее пути попадания багов в продакшн. Прочувствуй разницу.
И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию.
G>Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.
Да не расшаришь ты никакое состояние с требованием отклика в единицы микросекунд. Между процессорами и то сложно, разве что м/у ядрами получается. И да, узел, обрабатывающий информацию и принимающий решения, работает не так, как узел, выдающий информацию по запросу — поток информации тут противоположный.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Пользовал и пользую; писал и пишу; применяю, где имеет смысл и не применяю, где не имеет смысла. S>Верю. Всем остальным — тоже верю. Я же говорю: на форумах — все гуру. А в реальности закрытый С++ код, который я видел, в среднем намного хуже того Open-source, который вроде написан непонятно кем.
ГВ>>Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++. ГВ>>Ни ногой, так ни ногой, только зачем шуметь, если кто-то констатирует объективные недостатки того же дотнета, не зависящие от программистов? S>Да вроде никто не плюётся. Средний дотнетчик редко затевает топики типа "оппа, плюсам-то капец!".
А можно узнать, где в топикстарте есть что-нибудь про "шарпу капец"? Топик называется, напоминаю: "Конец нересурсов".
S>Всё как раз наоборот: начинаются какие-то наезды на управляемый код (без малейшего желания хотя бы выяснить, что вообще такое управляемый код.
По ссылкам из топикстарта всё-всё сказано. Ни о каких "шарпу — конец" там даже близко речи не идёт. Собственно, грызня началась из-за любимой шарпистами темы — изобилия ошибок в плюсовом коде.
S>Признайся честно — ведь не читал определение из ECMA-335, да?), вопросы типа "а как вы будете писать драйвер" и прочее, навязшее уже в зубах.
У тебя, я так думаю, это определение тоже не на стене в рамочке висит:
managed code: Code that contains enough information to allow the CLI to provide a set of core services. For example, given an address for a method inside the code, the CLI must be able to locate the metadata describing that method. It must also be able to walk the stack, handle exceptions, and store and retrieve security information.
Если ему следовать, то managed-кода за пределами CLI вообще не существует.
S>Работаете вы на С++ — так и работайте, кто ж вам не даёт?
Встречный вопрос: в топикстарте есть ссылка на бумажку про Dark Silicon, можешь что-нибудь сказать по ней? (Попытаемся вернуться к исходным вопросам)
ГВ>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. А если их нет, этих преимуществ по каким-то критериям? S>Это у вас комплекс такой.
Есть две группы: условно "шарписты" и условно "плюсовики". Плюсовики утверждают, что количество ошибок можно снизить до некритичного уровня (во всяком случае, далёкого от той химеры, про которую рассказывает шарписты). Шарписты чуть не в один голос орут что-то в духе: "это невозможно!" Тут, знаешь, у случайно оказавшегося рядом плюсовика не то, что комплекс, а просто раздвоение личности развиться может: ты видишь суслика? А его нет!
S>Вот, к примеру, в этом топике никто ни разу не высказался про "возможных и невозможных случаев".
Я немного приукрасил, да и мне сейчас лень копаться и предметно восстанавливать контексты, но по общему впечатлению неоднократных столкновений: достаточно только краем фразы зацепить .Net или сказать, что C++ не так уж и плох, как о нём говорят (а не ровён час — вообще сравнить его с C# не в уничижительном контексте), как немедленно прискачут шарписты и сразу загалдят всё своими сайтами, индусами, морями ошибок, тупыми студентами, управляемыми ОС, которые вот-вот захватят мир и т.п.
S>Зато с другой стороны идут какие-то постоянные намёки на некомпетентность С#-девелоперов.
Понимаешь ли в чём нюанс: плюсовики обычно ругают шарп (и не только) за объективные технические недостатки, как, кстати, это происходит и здесь. А шарписты ругают C++ за недостатки программистов. Отсюда получается более или менее одинаковая картина почти любого такого конфликта: плюсовик апеллирует к объективному (технике), тогда как шарпист — к субъективному (человеку). Естественная ответная реакция плюсовика — встречная апелляция к человеку (неправомерно, но по-человечески понять можно). Ну а дальше я раз от раза наблюдаю нечто всё более феерическое. Вон, как здесь уже договорились до того, что аллокатор=гуру, скоро до указателей дойдёте.
Так что, всё закономерно. В вычислениях, у кого тут какой комплекс на самом деле и чем он вызван, можешь поупражняться самостоятельно.
S>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
Вот, то самое, о чём я выше сказал. Недостатки C++ так же не зависят от программиста, и достоинства дотнета (вернее, комплекса: C#+.Net) не в меньшей степени зависят от программиста.
S>А нам, дотнетчикам, хочется, чтобы от программистов зависело поменьше. Потому что программисты — компонент самый ненадёжный.
Здесь у тебя есть очень серьёзный логический изъян. Попробуй найти его сам.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Пользовал и пользую; писал и пишу; применяю, где имеет смысл и не применяю, где не имеет смысла.
Верю. Всем остальным — тоже верю. Я же говорю: на форумах — все гуру. А в реальности закрытый С++ код, который я видел, в среднем намного хуже того Open-source, который вроде написан непонятно кем.
ГВ>Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++. ГВ>Ни ногой, так ни ногой, только зачем шуметь, если кто-то констатирует объективные недостатки того же дотнета, не зависящие от программистов?
Да вроде никто не плюётся. Средний дотнетчик редко затевает топики типа "оппа, плюсам-то капец!". Всё как раз наоборот: начинаются какие-то наезды на управляемый код (без малейшего желания хотя бы выяснить, что вообще такое управляемый код. Признайся честно — ведь не читал определение из ECMA-335, да?), вопросы типа "а как вы будете писать драйвер" и прочее, навязшее уже в зубах.
Работаете вы на С++ — так и работайте, кто ж вам не даёт? ГВ>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. А если их нет, этих преимуществ по каким-то критериям?
Это у вас комплекс такой. Вот, к примеру, в этом топике никто ни разу не высказался про "возможных и невозможных случаев".
Зато с другой стороны идут какие-то постоянные намёки на некомпетентность С#-девелоперов. Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
А нам, дотнетчикам, хочется, чтобы от программистов зависело поменьше. Потому что программисты — компонент самый ненадёжный.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
ГВ>>Ты их по скорости сравнивал? G>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.
А я сравнил. Соотношение времени выполнения примерно такое:
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
G>>Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?
ГВ>По-видимому, я всё-таки невнятно это как-то обозначил: приведённый код принципиально однопоточный. Многопоточным он "становился" только из-за ошибки в управлении потоками.
Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Don Reba, Вы писали:
DR>>Был Evernote 3.5 написанный на WPF
AVK>С WPF разговор отдельный.
А как кто-то приводит конкретный пример, дотнетовцы сразу говорят что вот уж в данном случае разговор отдельный. Тут должно тормозить, а вот в целом все очень быстро. Очень знакомо
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>Ну ты привел проекты очень давние, во-первых, во-вторых, опен-сорс по большей части студенты (или вчерашние студенты) пишут. Опен-сорс, это такая площадка для набития руки. V>Я тебе целиком в личку свежие коммерческие проекты на С++ могу закинуть, на предмет поиска голых указателей вне private кода.
V>И да, многое поменялось. Например, boost уже не тот, чтоб был в 2002-м (накануне принятия стандарта C++03), можно смело пользоваться.
Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ!
Куча тактов процессора и байтов памяти зазря тратятся.
Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
Здравствуйте, FR, Вы писали:
I>>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
FR>Прикол в том что точно также падают и глючат и программы на шарпе и яве.
Не точно так же. Если сиплюсники утверждают что RAII и тд и тд спасает, то это все сказки.
Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики. ГВ>>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию. G>>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.
V>По-моему, тут все проще. Называется недостаток воображения.
V>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.
Еще как в состоянии. Достаточно сделать данные immutable.
V>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь?
Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.
V>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.
Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.
По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан.
V>Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение.
Это отличный сценарий, особенно если учесть еще два фактора: распределенность и client state. Такая архитектура на десктопе в принципе не встречается.
С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
V>>>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов. G>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
ГВ>Ты их по скорости сравнивал?
Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот уж на инициализацию вряд ли влияет скорость сборки мусора. AVK>Основные причины тормозов весьма традиционны для МС — медленный рендерер.
Мне всегда казалось, что тормоза старта WPF связаны с большим количеством статической инициализации. Ошибался. Сварганил небольшое приложеньице:
var stackPanel = new StackPanel();
for (int i = 0; i < 500; i++)
{
var combobox = new ComboBox();
var treeview = new TreeView();
var listview = new ListView();
var titems = new List<DependencyObject>();
titems.Add(new Button());
titems.Add(new RadioButton());
titems.Add(new CheckBox());
titems.Add(new FlowDocumentPageViewer());
titems.Add(new TextBox());
titems.Add(new TextBlock());
titems.Add(new ListBox());
titems.Add(new ListBoxItem());
treeview.Items.Add(new TreeViewItem() { Header = "T", ItemsSource = titems, IsExpanded = true });
listview.Items.Add(new ListViewItem() { Content = "L" });
stackPanel.Children.Add(combobox);
stackPanel.Children.Add(treeview);
stackPanel.Children.Add(listview);
}
var scrollViewer = new ScrollViewer() { Content = stackPanel };
(new Window { Content = scrollViewer }).Show();
Поглядел профайлером. Получается, что большую часть времени на старте WPF тратит на подключение шаблонов контролов. При этом само чтение XAML очень быстрое и, с учетом кеширования, не зависит от числа контролов. Что 500, что 100, что 50 итераций — всегда чтение ресурсов занимает около 500 мс. 40% времени программа потратила на измерение размеров контролов, основную часть которого заняло присвоение шаблонов — то бишь построение визуального дерева. Далее, что выглядит вопиющим разгильдяйством, 20% WPF занималась оповещением о том, что изменилась доступность команд. Ну, а GC за время до взятия профайлером снапшота, отработал 5 раз, суммарно 147 мс, что меньше времени вычисления размеров контролов более чем на 2 порядка.
Опыт работы с профайлером у меня не так уж велик, так что если чего не учел и кому интересно, пишите — померяю еще.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе.
Скорее, как глисты, а не мифические зверьки
Все предпочитают думать, что у них-то уж точно такого нет. А по факту — один раз грязными руками за код взялся, и привет.
K>И ты за всем пустословием упустил самое главное. В управляемом коде надо еще постараться, чтобы получить наведенную ошибку.
Легко! Наведенная ошибка — это практически любая неправильно обработанная ошибка или пропущенная где-то ранее ошибка. Самый очевидный пример — когда-то ранее null сохранили без проверки, а в момент использования получи ошибку. Вот тебе классическая наведенная ошибка, найти которую не поможет никакой стек-трейс, т.к. в момент возникновения ошибки ее предыстория неизвестна. Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. По-сути ты называешь главной причиной наведенных ошибок ту, которая составляет доли одного процента от всех причин для наведенных ошибок. Сие нелепо.
K>А в С++ надо очень постараться, чтобы их не получить.
Разве?
И ты за всем пустословием упустил самое главное.
Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
Откуда же такое внимание к ошибкам именно в нейтиве? Наверно от того, что из нейтива можно сделать гораздо больше, чем из дотнета, в плане злонамеренно навредить, т.к. все АПИ ОС всё еще нейтивные. А ты тут на весь интернет путаешь частоту проявления ошибки с ее важностью. К тому же, сам факт спора о технологии, которой недостаточно владеешь, профанирует весь спор. Я постоянно последние почти лет 10 (еще с первых бет) использую как С#, так и C++. И какой аспект не возьми, но организовать на С++ статическую проверку всегда проще, чем на C#, на котором каждую мелочь, отсутствующую в стандартных либах, надо писать вручную. Дотнет хорош своей огромной функциональностью, данной на халяву, а так же визуальными редакторами GUI. Но в плане кол-ва словленных ошибок... если не касается использование имеющихся библиотек, а нужно некую функциональность делать практически с 0-ля, то программисты C# допускают намного больше ошибок, чем программисты на C++. Как раз из-за более бедных языковых ср-в. Причем, это медицинский факт, который я подметил еще в первые 3-4 года дотнета. Хотя, всякие FxCorp и Resharper помогают (частично), но тогда этих инструментов не было, и прелести технологии были видны во всей красе. Из-за этого что-то делать с 0-ля на дотнете в те времена можно было только в явовском стилее TDD, ввиду невозможности обложить код достаточными статическими проверками, нивелирующими надобность в ~90% этих тестов. А если брать ситуацию на сейчас, то под С++ уже полно ср-в как статического анализа кода, так и динамического. Серьезных, прямо скажем ср-в, аналогов которых под дотнет еще ждать и ждать.
В общем, повторю, возможность писать безопасно на С++ есть, и эта возможность на этапе компиляции всяко пошире, чем на C#. Возможность писать небезопасно тоже есть, но это считается хакерством, как беспричинный unsafe в дотнете, полностью аналогично. Ну и тыкать плюсовиков ошибками в старом С-коде — это надо совсем не разбираться в технологиях.
Здравствуйте, Banned by IT, Вы писали: BBI>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои. Голые указатели, если верить форумам, вообще никто уже десять лет не применяет. И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.
Ок, давайте возьмём какой-нибудь современный проект, существующий в реальности, а не в хвастливых рассказах.
Вот, первое, что мне попалось при поиске — Миранда. http://code.google.com/p/miranda/source/browse/trunk/miranda/src/modules/history/history.cpp
Что мы тут видим? Умные указатели?
Как бы не так!
По-прежнему незамутнённые memcpy(), C-style cast (кто там мне рассказывал про обязательность reinterpret_cast?), и явные вызовы mir_free(). О да, последнее явно говорит о собственном аллокаторе. Да вот же он: http://code.google.com/p/miranda/source/browse/trunk/miranda/src/core/memory.cpp
Упс, это всего лишь тонкий враппер вокруг malloc и free. Никаких чудес производительности от него ждать не стоит. Скорее наоборот: помимо обычного дорогого free он ещё и занимается обкладкой освобождаемой области 0xDEADBEEF.
Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.
Добро пожаловать в реальный мир, Нео.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
T>Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. А ошибки, связанные с нарушениями инвариантов могут быть абсолютно в любом коде — managed, unmanaged, свой, чужой — без разницы.
V>>Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
T>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
Мои сугубо практические наблюдения говорят о том, что managed в состоянии подкинуть сюрпризы покруче. Чуть пониже расскажу одну историю.
V>>Откуда же такое внимание к ошибкам именно в нейтиве? T>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
Некоторое время назад (не прошло и эм-м-м... примерно тридцати месяцев с тех пор) мне довелось лечить одну ошибку в комплексе managed+unmanaged. Классика жанра: AVE, чёрт-те что на выходе из unmanaged и далее по списку. Я когда увидел — ну всё, думаю, вот оно, тайное колдунство unmanaged. Добегался по форумам за "дотнетчиками", задавака хренов — вот сам теперь по носу своему задранному и получил. А ведь говорили, предупреждали хором: тайные ошибки — это вотчина unmanaged, и делают их не только вчерашние студенты. Короче, сел на измену, долго и тщательно копал — ничего. Ну, думаю, страус твои перья — и правда, пора C++ выкидывать, раз даже я в нём разобраться не могу. Короче, дня два или три я просидел на этой, довольно крутой измене, но как я ни искал ошибку в unmanaged — ни-фи-га. Поскольку код был мой, осознание этого факта добавляло мне острых ощущений.
Потом думаю: не, что-то тут не то. Сильно не то. А, там ещё был нюанс: unmanaged-код был спроектирован исключительно под single-thread, а защиты от параллельного доступа предусмотрено не было (ради оптимизации, конечно). Естественно, были подозрения, что дело в параллельном доступе, но как-то... В общем, просматривали мы тот managed-код, но ничего подозрительного не обнаружили. Да и в остальном он работал без особых нареканий, так что, подозрения казались безосновательными.
Короче, в качестве последней надежды я поставил блокировку параллельного обращения на входе в unmanaged. Так, на всякий случай, чем чёрт не шутит?
Продолжать рассказывать или уже ясно? Да, через пару минут я получил диагностику параллельного обращения. В общем, в этом корректно работающем managed-коде была классическая concurrency-ошибка параллельного вызова того, что так вызывать в принципе нельзя, да никогда и не планировалось. Особую пикантность всей ситуации придавало то, что в остальном код работал, скажем так, вполне нормально — ну, может быть, кое-какие странности были, но мы их списывали на трудности "реальных условий". Короче: тишь, гладь, AVE, злобный C++, ухмылка Страуструпа на фоне клубов серного дыма.
Дальше всё пошло своим чередом: разобрались, поправили, вытерли пот со лба, облегчённо вздохнули. Однако я вынес из этого несколько очень полезных для себя уроков.
1) Нельзя вестись на поводу у дурацких стереотипов, что в AVE всегда виноват unmanaged. Да-да, не удивляйся, я тоже в некоторой степени подвержен этой беде: хомячий гундёж вокруг опасностей unmanaged нет-нет, да и действует даже на таких самоуверенных и упёртых ретроградов. То есть ни в коем случае нельзя полагаться на некую априорно более высокую надёжность managed. На молчаливость в случае ошибок рассчитывать можно, и на тихий омут, в котором... Конечно, само AVE кинет именно unmanaged, но далеко не факт, что из-за ошибок внутри себя;
2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так.
3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше;
4) Ошибки в unmanaged-коде, действительно, неимоверно сложно искать... В особенности, когда их там нет и ты точно знаешь, что их там нет.
Спешу упредить возможные спекуляции: я далёк от рассуждений о чьей-то "низкой квалификации". Автор того managed-кода на самом деле весьма квалифицированный специалист и когда увидел всё это, схватился за голову, но... Не буду вдаваться в подробности, но были вполне объективные исторические причины, чтобы сложилась такая ситуация, да и вообще, настоящий профи должен лично составить полную карту граблей.
В общем, факт остаётся фактом: если бы на хвосте managed не висел сквалыга-unmanaged, ошибку пришлось бы искать гораздо дольше, а то и вообще она проплыла бы мимо. Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг. В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged.
У меня даже закралась крамольная мысль, что атомарность обновления ссылок в управляемом коде — не столь уж однозначно хорошая вещь. С одной стороны — дело благое: ссылка ведь не может указывать в неизвестность, правильно? Она всегда содержит либо null, либо ссылку на корректный объект. Но с другой стороны, если бы ссылки в самом деле "рушились" при несинхронизированном параллельном доступе (или ещё как-то могли быть испорчены, по крайней мере, в каком-нибудь отладочном режиме), искать ошибки было бы легче. Забавный размышлизм, верно? Гарантия корректности ссылок приводит к тому, что в некоторых ситуациях концы в буквальном смысле прячутся в воду — и хорошо, если в этой воде будет сидеть unmanaged, который добавит драйва к этому сонному царству... А иначе программа запросто может пойти в эксплуатацию с очень трудновоспроизводимой плавающей ошибкой. Managed-программа, заметь, будет управляемо и очень честно гнать пургу время от времени. И никаких тебе AVE или подозрительных падений — тишь, гладь, управляемость.
T>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
Заблуждение. С неимоверной лёгкостью при concurrency-ошибках можно получить совместное владение одним объектом вместо двух, никто и слова худого не скажет. Один объект будет при этом ухлопан, а второй окажется в обоих потоках. И никакого шума, поскольку: а) для обновления ссылок синхронизация не требуется, б) клиент не управляет удалением объекта и там, где unmanaged непременно даст диагностику двойного удаления, managed — стоически промолчит.
Потом, например, параллельный доступ к тому же Dictionary может привести к весьма загадочным ситуациям (по этому поводу тут Klatu как-то возмущался). А поиски причин могут быть очень нетривиальными, в особенности, если этот Dictionary уедет ещё куда-то.
T>2) Наличие коллстеков у всех исключений.
Не надо преувеличивать: сам по себе коллстек показывает лишь на место возникновения сбоя, но ничего не говорит о той цепи причин, которые привели к его возникновению (кроме непосредственной). Об этом было говорено-переговорено лет семь-восемь назад.
T>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
Ещё раз повторяю для дотнетчиков: ошибки типобезопасности вычисляются и лечатся на раз. Во-первых, потому что они на самом деле встречаются нечасто; во-вторых, потому что быстро себя проявляют; а в третьих — места, где играются с приведением типов, как правило, хорошо известны и на них в случае чего напрыгивают с проверками в первую очередь (вычурные конструкции вроде reinterpret_cast придуманы не с бухты-барахты).
Исключение, как это правильно заметил vdimas, составляет legacy-код, вот там — да, свистопляска может быть какая угодно. Но я имею в виду настоящий legacy, у которого история где-нибудь лет десять или поболе, а не то, что им иногда называют (C++? Значит — legacy!) Для примера можешь скомпилировать тот же ACE (или ещё какую-нибудь старую библиотеку) — там одних только предупреждений о приведении целочисленных типов — попой ешь. Справедливости ради, других ошибок в нём тоже хватает, он же написан ради воплощения паттернов борьбы со сложностью, ну вот и... Хе-хе-хе. Но с новыми библиотеками всё намного легче: даже у такого монстра, как boost и то, предупреждения связаны в основном с использованием deprecated-функций.
Так что, всё, что ты перечислил — оно, конечно, правильно, но практика — вещь такая...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
V>>Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит. G>Агащаз.
Быстрая сортировка. Нарисуй-ка inplace без foreach.
V>>Например, попарный перебор элементов коллекции. G>.Zip
Опять read-only.
V>>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам. G>Снова бред. Ты просто не в теме.
Пока что я вижу, что это ты не в теме даже в базовых вещах.
G>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
На сегодня Linq сливает даже традиционным функциональным языкам по эффективности времени выполнения... а те, в свою очередь, во все времена были руганы за тормознутость и требования к памяти. Да и полно таких технологий, в сравнении с которыми Linq и по выразительности — ничто... Одна засада, тормозит это так же нехило, как и LINQ, а то и похлеще.
G>Ты бы лучше выглянул из своей норы, увидел бы что в .NET есть много способов априори избежать тех ошибок, которые постоянно случаются в unmanaged.
Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов.
G>Но если для тебя stl является пределом, то вряд ли стоит тебе что-то тут писать.
А в Киеве дядька.
G>Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются.
На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно. Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. Слабоватый ты оппонент с такой позицией... Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили).
V>>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом. G>Не, в C# такой код просто не будет написан.
Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить?
G>Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.
А почему я должен понимать твои неуемные фантазии? Я этой ньювасюковщины наелся еще в 2002-м, а потом в 2005-м. Но сужу по реальным проектам, которых насмотрелся достаточно. А ты тут пытаешься говорить "сахар, сахар", и удивляешься, как у нас до сих пор во рту не сладко.
Такого уровня программист, которого ты подразумеваешь на C#, сможет на плюсах сделать то же самое и быстрее и эффективнее. Проверено многократно на задачах, где для дотнета нету львиной доли конечного решения в готовых библиотеках, т.е. много надо делать с 0-ля. Но если брать спецов, скажем так, не очень высокого уровня, то у них плюсовые проги даже не заработают, согласен, но шарповые заработают хоть как-то... Тут C# всяко эффективнее, да... Со всеми этими регулярными глюками, о которых я говорил выше. Прямо отсюда можешь начинать заходить на 5-й круг, но результат будет тот же, гарантирую.
G>Именно, вот managed позволяет сконцентрироваться на логике, а в unmanaged ты вынужден и за памятью следить.
Ну так не везде же нужна голая логика без эффективности, правда? Иначе бы никто не искал программистов С++ сегодня. Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? Тебе ведь невдомек выделить время и прикинуть такой момент, что политика работы с памятью (а есть и такое вне дотнета) — это всегда часть процедур при работе над эффективностью кода. Более обще — сама основа эффективности ПО — это суть эффективное использование ресурсов. Не только памяти, смотри шире.
G>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
В каком месте?
Даже в самых требовательных к производительности самых нейтивных аппликух, оптимизации требует лишь часть кода, вот в чем цимус. Но даже в этих местах вся оптимизация сводится порой к назначению объекту уже имеющегося кастомного аллокатора и назначению другого смарт-поинтера. И это уже писали тут не раз, ты невнимательно читаешь.
V>>Именно. G>Это тоже бред. Ни один толковый менеджер не позволить такое сделать.
А посадить 100 тестеров на 10 программистов толковые менеджер позволит?
Ты просто не в курсе, как организуется тестирование ГУИ-приложений. В общем, негативных тестовых сценариев (в основном автоматических) подавляющее большинство. Именно у грамотных менеджеров QA. Наблюдал самолично в крупных штатовских компаниях. Оттуда эту полезную практику и вынес.
G>Нет, то что не происходт — не проверяется. Нет смысла писать тесты для наборов входных данных, которые не появляются в работе. Лучше такие места заткнуть ассертами (или code contracts), любое срабатывание которых очевидно говорит о баге, который надо править.
Вот ты и попался. Я неделю ждал, когда же ты, наконец, проговоришься и назовешь вещи своими именами, без твоих обычных обтекаемых "тут всё ИНАЧЕ!!!".
Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших.
G>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит.
Детсад.
G>Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе.
Детсад.
G>Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская.
Потому что не требуется точность, т.е. каждое изменение этой величины не надо сбрасывать транзакционно в базу, можно это делать с некоторой периодичностью. Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, пусть это будет "анализ состояния памяти". Хотя большой разницы нет: проанализировать и принять решение на основании анализа, считай, то же самое, что и: "проверить и принять решение на основании результата проверки". Разница в оттенках.
Нет никакого "решения", нет никакого "анализа".
Есть процедура "спасение живых объектов". Нет процедуры "удаление мёртвых объектов".
В классическом менеджере памяти нет процедуры "спасение живых объектов", зато есть процедура "удаление мёртвых объектов".
Этих несложных соображений пытливому уму должно быть достаточно для того, чтобы прикинуть, где должна пролегать граница между "GC эффективнее" и "классика эффективнее".
И уж тем более достаточно для того, чтобы навсегда отказаться от заблуждений вроде "классика всегда эффективнее".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
ГВ>>- Начиная с 2010 всё возращается на круги своя — начинают считать циклы/ватт потребляемой мощности (Саттер называет это Return of The King); DG>Остается ключевой вопрос: DG>в каком именно году весь код facebook-а и все приложения android-а перепишут на C++? а также все тонкие приложения (например, gmail)?
В Android'е сейчас с помощью NDK можно на С++ писать. А тонкие приложения у себя Гугл переписывает на Go, из тех, которые не написаны на Java.
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Хорошо, все программы — нативные, все программы — менеджед, все программы — интерпретируемые
ГВ>Ну, поскольку процессор умеет исполнять только нативный код, то, думаю, можно ограничиться первым.
Отлично. Все программы — нативные. А следовательно быть никакого ренесанса и конца нересурсов быть не может.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Скажем более общо: вызов операций удаления объектов определяется политикой управления памятью, которая, в свою очередь зависит от выбранной архитектуры, от задач приложения и кучи других соображений. Часть приложения может работать под одной политикой, часть под другой, часть — под третьей...
Все эти песни мы уже слышали в 1996 году, при появлении Java. На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++. Не говоря уже о том, чтобы заниматься поддержкой множества политик управления памятью в пределах одного приложения.
На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, AndrewVK, Вы писали:
AVK>>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
DR>Был Evernote 3.5 написанный на WPF и заметно более тормозной чем нативные 3.1 и 4.0.
Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.
Здравствуйте, Sinclair, Вы писали:
ГВ>>"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит. S>Это любые, где требуются явные операции освобождения памяти.
Один мой такой "любой" аллокатор в КСВшном сраче на спор порвал GC в тесте производительности, предложенном .NETчиками.
Так что аллокаторы они пц какие разные бывают.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, samius, Вы писали:
S>Рекомендую сналчала поинтересоваться об источнике этой информации
Тьфу, блин! Так это Plutonia переименовался... В бытность плюсовиком его слог был дружелюбнее гораздо... вот до чего дотнет разработчиков доводит! Никакой антирекламы не надо.
Здравствуйте, Banned by IT, Вы писали:
ГВ>>Вон, как здесь уже договорились до того, что аллокатор=гуру, скоро до указателей дойдёте. BBI>Этот момент нереально повеселил. Шарпист добровольно по сути признал меня гуру, цирк на конной тяге!!!
Господа Шарписты, я не понимаю, для чего вы тратите силы и время на спор с такими людьми. Стоит завязать, причем насовсем.
Здравствуйте, gandjustas, Вы писали:
G>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики. ГВ>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию. G>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.
По-моему, тут все проще. Называется недостаток воображения.
Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации. А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь? Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.
Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
G>>И ты сходу привел решение, далекое от оптимальности
CS>Пора переходить к конкретике.
CS>Можешь привести пример WPF приложения которое работает соизмеримо с аналогичным native?
WPF — нет, WPF тормоз зам по себе, независимо от .NET.
Хотя именно 3d графика и шейдерные эффекты позволяют сделать быстрые и "богатые" интерфейсы, которые на native с теми же трудозатратами хрен повторишь.
А вообще чего сразу WPF? Ты покажи сайт написаный на native, который работает соизмеримо с сайтом на ASP.NET?
CS>Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично.
Это не значит что они умеют и знают WPF
CS>И у которых была и есть железная мотивация сделать хорошо.
Тут уже был пост о времени запуска WPF. Посмотри что там тормозит. Независимо от того насколько кто хочет как сделать это все равно будет тормозить. ПТИ для задач evernote было бы отличным решением просто не выгружать программу. Тем более так делают и другие аналогичные приложения.
Здравствуйте, gandjustas, Вы писали:
V>>Эээ... Ты сейчас понял хоть, что сказал? Управляемая среда не может "не допустить ошибку" выхода за пределы, например, она честно выплюнет баг... И если повезет — во время тестирования. Но в плане "недопущения" — это фантазии. G>Не говори глупости. Я использую foreach у меня вообще нет ошибок выхода за пределы массива, их в принципе не может появится.
"Не говори глупостей", "это хрень" и т.д. Думаешь, эти "заклинания" работают?
ИМХО, прошли те времена, когда на RSDN оппоненты понимали что пишут не поставлялись в каждом втором абзаце строчке...
Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит. Например, попарный перебор элементов коллекции. Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам.
Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.
Пишу эти банальности не для тебя, разумеется, бо с тобой уже по 3-му кругу пошли на одно и то же... как том анекдоте, про очень пылкого в постели дедушку со склерозом. Это я для "независимых" читателей пишу, которые добрались до сюда и надеются вынести толику информации.
V>>К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет. G>Дык есть codecontracts, кроме того есть unit-тесты, которые проверяют утверждения, которые в свою очередь невозможно вычислить статически.
Мы уже не раз тут соглашались в разных спорах, что объем юнит-тестирования не может превышеть объем целевого кода на порядки. Ну кроме пресловутых программ для атомных электростанций и прочих сферических вещей. Если ты обложишь юнит-тестыми абсолютно все места, где идет динамическое приведение типов, используются банальные if, идет оперирование массивами и т.д. до бесконечности, то получить превышение объема тестового кода над целевым на пару порядков- как два пальца об асфальт. И я бы не видел регулярные падения дотнетных более-менее крупных программ. К джаве это так же относится.
Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом.
G>>>Процент багов, связанных с неправильным кодированием, попадающими в production очень низок. V>>Процент от объема логики или от чего? G>Процент от всех потенциально возможных.
Опять ошибаешься, и уже делился информацией не раз. Например, открыть нашу JIRA, и там багов, связанных с порчей памяти, будет всяко меньше одного процента. Далеко не у каждого проекта хотя бы раз, при общем кол-ве фиксов на каждый проект за несколько лет жизни в сотни. Т.е. ошибки в логике происходят примерно в тысячу раз чаще, чем ошибки собственно кодирования. Да, разумеется, юнит тестирование используется. Как раз чаще всего для проверки граничных условий и соблюдения инвариантов. Надо просто понимать, что стоит проверять в первую очередь. Все подряд, естественно, мы не проверяем.
G>>>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна). V>>Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования. G>Ну давай вернемся. Ты серьезно предлагаешь затратить 70% времени тестирования на тестирование результатов не нужных пользователю?
Именно. Даже озитивные юнит-тесты, проверяющие граничные случаи, фактически проверяют те сценарии, которые никогда не происходят (или крайне редко). Если же алгоритм сильно зависит от внешних условий, то не имеет смысла писать для него юнит тесты без проверки его поведения в случае неадекватных этих внешних условий. Т.е. вообще не стоит, ибо без этого это будет профанация тестирования, сугубо "для галочки".
Почему именно так? Помнишь, про относительную надежность? У вас в продукте тысячи таких примитивных мест, и если надежность каждого из них жалкие ~99.9%, достигнутые через код ревью и проверку только позитивных моментов, то программа ваша в большинстве случаев будет падать. Всё просто. Поэтому тут и пишут некоторые, что у них огромный отдел "ручных" тестировщиков. Их задача как раз "тупо" запускать программу в различных условиях, что бы вылазили боком те самые непокрытые негативные сценарии в различных комбинациях. А что еще можно проверять в ручном режиме? Помедитируй на эту тему... И как приговор: ручное тестирование — это аналог тыканья пальцем в небо. Можно попасть, а можно нет — как повезет.
G>>>А разницы между потоком и запросом почти нету на самом деле. Можно одно свести к другому и наоборот. V>>Нельзя. Каждый запрос — локален, независим от остальных. G>Это зависит от того как напишешь.
Это зависит исключительно от предметной области. Например, доступ к справочным или историческим данным масштабируется теоретически произвольно. А доступ к оперативной информации масштабируется ровно настолько, насколько интересует именно оперативность данных. Чем оперативнее данные нужны, тем меньше возможности масштабирования по узлам. Совсем оперативные мы даже не можем масштабировать на соседнее ядро, такие пироги. Приходится бороться за процессорные тики принципиально однопоточного алгоритма.
V>>Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние. G>Скажу по секрету что запросы тоже могут влиять на состояние. Например форум подсчитывает количество просмотров, на каждый запрос изменяется соcтоние.
Но требования к оперативности получения этой изменяемой величины стремятся с 0-лю. Каждый запрос вполне может слать выделенному сервису тикет, который будет вставлен в неспешную очередь, которая будет разгребаться в отсутствии пиков загрузки с подходящим приоритетом и т.д. Что я тебе тут рассказываю, в общем, базовые вещи уровня 3-го курса профильной специальности...
G>Более того "поток данных" состоит из отдельных кадров, так что вопрос в том как работать с состоянием.
Изначально неправильный вопрос. Вопрос может быть лишь в том, какие требования. А ответ всегда — удовлетворить требования максимально дешевым способом, вот и всё кино.
Здравствуйте, Sinclair, Вы писали:
S>Действительно. В таких задачах, как хорошо известно, рулит Эрланг — практически интерпретатор, полностью управляемый. Дотнет слишком низкоуровневый для таких задач.
Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная. А у дотнета дорогой получился вызов нативных ф-ий, у интерпретатора Лиспа и то дешевле. Дотнет действительно, и не высокоуровневый, но и не низкоуровневый.
Здравствуйте, vdimas, Вы писали:
AVK>>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.
V>Дык, такие вещи ни от платформы, ни от языков не зависят.
Вот именно.
V>ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования
Ничего он не формировал. Это не культура, а безкультурье. Всегда имеется значительная масса неграмотных разработчиков, и они в любом случае будут использовать какую то платформу. С убиением VB они просто мигрировали на шарп.
Сам же по себе шарп — весьма непростой язык, это не VB и не PHP. Просто он позволяет писать на нем в упрощенном режиме, эдакая реинкарнация С с классами в качестве С++. И чаще прощает ошибки.
V>В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже)
А нужно чтобы было много?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
ГВ>А в чём тут отрицательное влияние выражается? В миграции ссылки на долгоживущий объект из памяти Gen2 в память Gen0?
основной ошибкой будет постоянное изменение ссылок из долгоживущих на короткоживущие.
это приведет к тому, что постоянно будет звенеть колокольчик, что произошло изменение страниц памяти с долгоживущими, и что их надо перепроверять при анализе для сборки мусора короткоживущих объектов.
соответственно, если объект просто используется из пула, то это даст ускорение, но если при этом в нем постоянно начинают меняться ссылки на другие объекты, хотя бы на строки, не говоря уже о других более сложные объектах, то может получится что такая оптимизация добавит больше работы gc, чем выиграет от повторного использования.
Здравствуйте, vdimas, Вы писали:
V>Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная.
OMG. OMG!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов. Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
Ерунда это всё. IL описывает ту же программу, что и ЯВУ. Просто никто толком не занимается разработкой компиляторов под управляемые языки, генерирующих шустрый код. Равно как никого не колышат тормоза GC. Встанет массовая потребность — будут заниматься. А пока народ допиливает плюсы.
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
ГВ>А можно узнать возрастные характеристики этого среднего программиста?
Здравствуйте, Константин Л., Вы писали:
CS>>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
КЛ>что это за десяток things?
Каждый DOM элемент в WPF это Common Language Runtime object instance.
Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д.
Десятки GCable things и набегают.
Во всех текущих HTML DOM имплементациях включая мою собственную DOM живет в non-manageable memory space (в терминах .NET) — используется простой и эффективный ref counting.
Если script не работает или он не трогает какие-то элементы то для них GCable wrapper и не создается. Т.е. GC скрипта сканирует очень ограниченный subset объектов.
Плюс алгоритмы layout и rendering работают нативно и с нативными объектами.
Например у меня чтобы определить скажем значение overflow свойства из style элемента нужно просто прочитать значение поля struct style {...}.
Это одна машинная команда. Со всеми вытекающими.
CS>>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл. CS>>Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.
CS>>Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.
КЛ>я не знаю что такое абстрактный HTML DOM, он везде свой, конкретный. как можно сравнивать WPF OO и абстрактную OO HTML DOM мне не ясно.
HTML DOM он в общем-то стандартный и специфицировнный например http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html
Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser.
Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий.
Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.
ГВ>Я знаю, что полно, но ты сам что именно посоветуешь? http://www.rsdn.ru/article/dotnet/GC.xml
это для начала
потом CLR via C# рихтера, только последней редакции
после этого http://msdn.microsoft.com/en-us/library/0xy59wtx(v=VS.110).aspx
А дальше можно просто гуглить.
G>>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает. ГВ>По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит.
Ты еще не формализовал понятие "не хватает".
G>>3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее. ГВ>OK. Про использование защищённых страниц я не знал (разве что краем уха слышал).
Я читал о таком механизме как о возможной оптимизации поколений (ссылку к сожалению не найду), но подобный механизм точно существует иначе .NET был бы не быстрее ruby.
Причем долгое время mono не имел generational GC и дико тормозил. Также generational gc отсутствует в xbox.
G>>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#. ГВ>И в чём выражаются такие нарушения?
Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
ГВ>>Хм. А GC разве не занимается регулярными проверками состояния памяти?
DG>в managed есть лишь лишние проверки при доступе к массиву. DG>Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Популярное заблуждение, достаточно просмотреть на сгенеренный бинарный код. Наоборот, подавляющая часть проверок остается, а уходят считанные доли процента в ручном "хакерском" коде (С), имеющим дело непосредственно с массивами. Всегда, когда реальных данных меньше, чем размер массива, имеем такие проверки в рантайм. Например, внутри стандартных контейнеров, которые используются в 99.99% случаев.
Здравствуйте, mrTwister, Вы писали:
T>>>А кто тебя заставляет это делать? V>>Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы. T>Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.
Меняй круг общения
V>>Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки". T>Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов.
Что за продукт то?
T>Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!
И как она называется?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Mazay, Вы писали:
U>>>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии. C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд. M>Который надо было сделать 7 лет назад.
И что дальше-то?
U>>>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией. C>>И пофиг, зато быстро работает. M>Про переполнение буфера забыли?
Это что, такое пугало для детей?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я не спорю, языковые средства контроля выхода за границу буфера — вещь полезная. Только не надо преувеличивать её значение. Runtime-исключение, вылетающее в самый неподходящий момент ничуть не приятнее AV или эксплоитной дырки.
Действительно, какая разница. Просто выдали ошибку, в худшем случае аккуратно закрыли процесс. Или дали возможность злодею анально поиметь хозяина компа. Вообще никакой разницы
Признайся честно, ты хоть в одном серьезном проекте когда-нибудь вообще работал? Хотя бы кодером?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
Осталось понять, что ж ни Adobe, ни MS, ни Apple не выловили и не вылечили это всё на раз. А продолжают мне дважды в месяц присылать очередные апдейты, где "fixed the vulnerability allowing a remote attacker to gain a control over compromised system".
Наверное, менеджмент во всех трёх сговорился и систематически дурит с тестированием.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Klatu, Вы писали:
K>>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое? V>>>Это от технологии не зависит. K>>Чего-чего?
ГВ>Садись, два.
Ну только не тебе это решать
Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал.
Но при этом почему-то считаешь их "мифическими".
Занятная мифическость получается: в компаниях с высокой культурой разработки и значительными инвестициями в отлов и починку этих мифических зверей их извести никак не могут. Наверное, зато, в наколенных поделках самоучек эти зверьки совсем-совсем не встречаются.
ГВ>Эти факторы как раз и влияют на "дурь" с тестированием.
А-а. Ну то есть несмотря на то, что МС уже лет пять как делает "quality-based releases" и отказывается называть заранее даты выхода продуктов, чтобы избежать проблем типа "не успеваем к релизу — давайте скипнем тестирование", и вкладывает чудовищные деньги в тестирование и верификацию своих неуправляемых программ, систематически получает проблемы.
Если у них дурь с тестированием, то остальные, скажем так, вообще никаким QA не занимаются.
Каким же тогда образом мы можем полагаться на надёжность программ на C++?
ГВ>Скорее — изменение предмета обсуждения.
ГВ>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе.
С чего бы это вдруг? Нет, я буду агитировать за взвешенный подход.
Менеджед вовсе не означает гарантированного увеличения ресурсопотребления. Да, сборка мусора требовательнее к памяти, чем обычное выделение. Это не означает, что нельзя сочетать оба подхода. Более того, в высокопроизводительных серверных приложениях так и делают — выделяют часть памяти "статически". И таки память сейчас значительно менее ресурс, чем даже во времена начала дотнета.
Для роста затрат остальных ресурсов объективных причин нет.
ГВ>Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
Угу. Вот только пока что основные результаты в компайл-тайм верификации достигнуты как раз для управляемого мира. А так как я целиком за статическую верификацию, то, естественно, моё мнение склоняется в управляемую сторону.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Продвинутые аллокаторы используют локальные для потоков арены, там блокировка не нужна.
Тем не менее, независимо от степени продвинутости аллокатора, при убийстве 100к объектов нужно 100к раз вызвать код возврата памяти в кучу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Неправильно. Это аргумент в пользу отказа от классических менеджеров памяти. Ещё варианты есть?
Хорошо, сформулируем по-другому: фрагментация свободной памяти возникает в ручном подходе к выделению памяти. И является, таким образом, аргументом для отказа от ручного распределения в пользу автоматического выделения памяти, т.е. GC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0: S>>
S>>Выделение памяти без синхронизации
S>>В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
V>Это касается только маленьких объектов. Для больших, по-прежнему пулы показывают оч. высокую эффективность, в сравнении с GC. Например пуллы массивов байт/символов.
Я не против пулов, лишь уточнял по поводу interlocked. Очень большие объекты в дотнете выделяются в Large Object Heap, которая не дефрагментируется сборщиком. Поэтому, во избежание фрагментации пулы могут использоваться и в дотнете.
Здравствуйте, Sinclair, Вы писали:
S>На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++.
Хм... Много найдешь разработчиков С++, старше 5-ти лет опыта, которые никтогда не писали или не поддерживали/использовали в проекте уже писанные кем-то аллокаторы. Боюсь, у тебя неверное представление. Я еще не видел ни одного более-менее большого проекта на С++, в котором не использовалась бы целая россыпь различных аллокаторов.
S>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Неправильно. Это аргумент в пользу отказа от классических менеджеров памяти. Ещё варианты есть? S>>Хорошо, сформулируем по-другому: фрагментация свободной памяти возникает в ручном подходе к выделению памяти. И является, таким образом, аргументом для отказа от ручного распределения в пользу автоматического выделения памяти, т.е. GC.
ГВ>Снова неправильно. Фрагментация возникает тогда, когда реализованная в программе политика управления жизненным циклом объектов подразумевает такую фрагментацию. Ещё варианты?
И много ты знаешь людей, которые способны реализоваь качественную политику управления жизненным циклом объектов ? Из Сиплюсников таких единицы
Здравствуйте, vdimas, Вы писали:
ГВ>>Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно. V>Ес-но не бесплатно, но оказалось в тему для неравномерных нагрузок. Тут говорили, что GC запускается только тогда, когда памяти не хватает — это малость не так (вернее, не только так), по крайней мере с тех пор, как в ход пошел фоновый GC, потому как шедуллер GC ориентируется еще на счетчики производительности. В этом случае GC поможет выровнять, например, нагрузку на сервер. ГВ>>Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр. V>Да, но тоже неплохо работает в фоне.
В контексте топика важно только то, что эти затраты есть. Понятно, что в фоне, но источник питания один и бесконечно понижать энергопотребление единичного вентиля на кристалле тоже нельзя...
ГВ>>Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
V>Ну... для таких задач в дотнете полно еще помех, помимо GC. Например, в C++ мы куски памяти непосредственно можем интерпретировать, в дотнете в safe-режиме это невозможно, а зачитка нативной памяти (десериализация) как показывают замеры — вещь очень и очень постепенная.
Тем более.
V>[...] Загвоздка, как постоянно говорю, лишь в большой разнице кач-ва генерируемого кода компилятором C++ перед JIT или ngen, а с этим бороться никак.
ИМХО, это означает, что бороться с действительно острыми моментами нельзя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
Если ты это на своей работе видел, то у вас бардак, поздравляю.
Похоже, работа над эффективностью смешивается с разработкой функционала. ИМХО, конкретно технология пулов — это настолько изолированная штука... которую можно прикручивать и откручивать, не трогая ничего вокруг, что я плохо себе представляю работать над полезным функционалом одновременно прикручивая/отлаживая пул объектов... Если они и на плюсах так писали, то конкретно плюсы тут уж точно не при чем. Это классичесский бардак и хаос в махровой стадии, который всегда бывает в отсутствии регулярного взаимного ревью кода. (даже у опытных разработчиков, угу)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так у Facebook в том и прикол, что они не могли отказаться от использования PHP при всём желании.
Я знаю только об одном случае переписывания серьезного продукта с языка высокого уровня на С++ — это яховский веб-магазин. Результат был плачевным. Яху утратил позиции лидера.
Трансляции в С++ тут вообще не причем. Это не более чем способ оптимизировать производительность разных интерпретируемых сред. Для дотнета и явы он имеет мало смысла. К тому же при этом глупо генерировать С++-код. Куда разумнее генерировать С-шный код. Переносимость выше и практически нет неявного оверхэда. А все возможности С++ для генерированного кода на фиг не упали.
Так что не обольщайся. С++ популярнее не станет. Он живет по инерции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Banned by IT, Вы писали:
S>>>На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++. ГВ>>Ну что ж, спасибо за комплимент. Надо сказать, весьма неожиданно для этого форума. BBI>Обычно применяемый ими термин скорее оскорбителен.
Не знаю, я читать мысли не умею. Хотя, справедливости ради, время от времени чувствую себя, как в башне из слоновой кости: у них там какие-то хождения по памяти при Луне, мегагуры с продвинутыми техниками, которые я считаю тривиальными. Чистая фэнтезятина, ни дать, ни взять.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти.
ну это просто вранье или полная некомпетентность
V>то программисты C# допускают намного больше ошибок, чем программисты на C++
Я пока что не встречал более пафосных говнокодеров, чем на С++. Вот это — точно медицинский факт. Каждое нубло, которое накропало пару примитивных программок на С++ — уже считает себя гуру
Здравствуйте, mrTwister, Вы писали:
V>>И да, многое поменялось. Например, boost уже не тот, чтоб был в 2002-м (накануне принятия стандарта C++03), можно смело пользоваться.
T>Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ! T>Куча тактов процессора и байтов памяти зазря тратятся. T>Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
Вот это и есть проблема апологетов дотнета: если их послушать, то можно сделать предположение, что они абсолютно не верят в людей. Ну то есть люди не совершенны, это понятно, но в устах "дотнетчиков" это несовершенство приобретает какие-то гротескные черты, прямо как у Босха.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
Прикол в том что точно также падают и глючат и программы на шарпе и яве.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет никакого такого качества дотнетных специалистов. Есть просто качество специалистов. И от того, что конкретного человека ты с шарпа на плюсы пересадишь, он умнее не станет.
Все-таки написать нечто "работающее" и сопровождаемое проще на managed средствах (.NET, Java, etc), т.к. порог вхождения существенно ниже по сравнению с unmanaged.
Главная беда здесь в том, что многие после этого самого вхождения, не стараются [интенсивно] повысить свой уровень.
Чтобы на том же C++ сделать мало-мальски крупный проект, который будет грамотно использовать ресурсы, будет удобно сопровождаемым, переносимым и т.п., нужно приложить существенно больше усилий к своему образованию, как следствие опытный программист на C++, в среднем получается более “продвинутым”, по сравнению с опытным программистом использующем подавляюще кол-во времени managed-средства.
Сугубо по моим наблюдениям наиболее качественный managed-код в любом случае пишут люди с опытом работы с unmanaged-кодом (и чем он был больше, тем лучше).
Ну а так, вы конечно правы, приклеивание ярлыков тем или иным сторонникам технологий/языков/парадигм, подобно измерению средней температуры по палате.
Здравствуйте, Геннадий Васильев, Вы писали:
V>>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. K>>ну это просто вранье или полная некомпетентность
ГВ>Слушай, найди какой-нибудь другой аргумент, а?
Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил, и непонятно кто — это, пардон, п-ц. Писать в таком стиле, что это становится типичной ошибкой — полнейшая некомпетентность. Метлу в руки — и на улицу.
ГВ>Давай уж начистоту: "вы все [плохое слово по выбору], а я в белом!" Так хоть честно будет.
Здравствуйте, Banned by IT, Вы писали: S>>Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей. BBI>У тебя что, отсутствие указателей это признак качества кода?
Отсутствие голых указателей и храбрых вызовов strcpy — да.
BBI>Неужто вообще весь код просмотрел?
Нет, потыкался наугад. У меня ещё и работа есть, вообще-то. BBI>Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод.
Можно, я буду это цитировать в будущих спорах с плюсистами?
S>>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new. BBI>Operator new может быть перекрыт глобально.
Не смешите мои тапочки. Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами. Этот аллокатор не может себе позволить иметь нетривиальный delete.
А аллокатор с вырожденным delete не удастся использовать глобально.
BBI>И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
V>>И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. G>Если не ошибаюсь то для этого нужна debug сборка, которая сводит на нет все преимущества C++.
Ошибаешься.
T>>>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь. V>>Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм. G>Прикол весь в том что AV возникает не там где находится ошибка, что значительно усложняет отладку. Кроме того пропустить на тестировании outofrange и nre довольно сложно.
В 99% случаях — именно там где накосячено.
Расстрелы памяти кстати тоже ловятся достаточно просто. Мест где пишется что то в память напрямую обычно немного.
T>>>2) Наличие коллстеков у всех исключений. V>>Помогает только для примитивных ошибок, и доступно для С++ тоже. G>Ага, но только в дебаг версии.
Что, в release стек не используется что ли?
Несколько сложнее его раскручивать но тем не менее оно есть.
G>Использование только safe части C++ делает программу не быстрее (а зачастую и медленнее) чем .NET
Facepalm.
V>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII G>Которым далеко не все пользуются
Все вменяемые — пользуются.
V>>что совершенно невозможно в дотнете G>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1.
Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев.
Это синдром VladD2
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
S>А в реальности закрытый С++ код, который я видел, в среднем намного хуже того Open-source, который вроде написан непонятно кем.
Я в реальности видел C# код насколько кошмарный, что ни один говнокод на С или С++ что я видел с ним не сравнится.
И чо?
S>Всё как раз наоборот: начинаются какие-то наезды на управляемый код
Дааа. Канеееешна. Особенно два самых заядлых .net ненавистника стараются: икемфула и ганжустас.
S>Зато с другой стороны идут какие-то постоянные намёки на некомпетентность С#-девелоперов.
В общем то под подобными заявлениями есть некоторые реальные тенденции. Не в том плане что C# девелоперы тупеют, нет. Просто в силу того что на managed куда более тупорылые ошибки прощаются туда постепенно стекает всякий некондиционный кодер, ухудшая карму среднестатического managed прогера.
S>Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
С достоинствами оно всегда так. Это и для C# верно.
Одним и тем же инструментом один сделает из куска мрамора статую, другой — кучу мусора.
S>А нам, дотнетчикам, хочется, чтобы от программистов зависело поменьше. Потому что программисты — компонент самый ненадёжный.
Мда. А думать за вас тоже комп должен?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
V>>И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. G>Если не ошибаюсь то для этого нужна debug сборка, которая сводит на нет все преимущества C++.
Ошибаешься, если генерить только Program database (что достаточно для этого сценария), то оно не ограничивает возможность полной оптимизации. Ну пропадут у тебя некоторые локальные переменные, ну будут пропуски в стек-трейсе... Дык, в дотнете аналогично, при инлайне методов, как бы "скипается" частично исходный стек-трейс. Все равно видно, куда копать, т.е. область поиска резко сужается.
V>>А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек. Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях. G>Да, только наведенных ошибок в managed коде почти нет или легко отлавливаются при тестировании, а в unmanaged их полно.
Заблуждение. Если бы отлавливались при тестировании, их бы не было. А по факту на сегодня я не видел еще ни одной достаточно большой дотнетной неглюкавой программы. Хреново в дотнете со статикой-то, а в динамике не всё поймаешь, бесконечным и дейтсвительно всеобъемлющим тестирование не бывает, это миф, бо такое тестирование на пару порядков обойдется дороже собственно разработки.
T>>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. V>>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference? G>Стектрейс, хотя для nre в продакшене надо сильно постараться
Не льсти себе. Тебя послушать как в дотнете, то "надо просто контрактами обложить", а как в С++, то "обязательно нарушат контракт". Эдак можно много до чего договориться.
По моим наблюдениям за глюкавостью дотнетных программ, они ловятся на совершенно детских тестах: например часто при попытке сохранить файл в директорию, защищенную от записи или почти в 100% случаев, при исчерпании какого-нить ресурса (кол-ва сокетов, поверхностей для рисования, свободного места на диске). Такое ощущение, что дотнетчики поголовно пишут код из расчета "всё будет хорошо", проверяя максимум контракты на входные параметры методов, во всех остальных случаях тупо плюя эксепшен, который (удивительно!) никто нигде не ждет. Понятие безопасного к исключениям кода — это нечто из другой реальности, отсюда дотнет — просто рассадник наведенных ошибок (по опыту своей помощи в ловле ошибок коллег), бо после первой же обработанной (якобы обработанной) ошибочной ситуации, отваливается работоспособность в другом месте, потому как один или несколько объектов остаются в некоем промежуточном невалидном состоянии. И хоть подобные ошибки от платформы не зависят, но почему-то дотнетные программы болеют ими чаще, по моим сугубо личным наблюдениям. Да, "вы" правы, на плюсах в среднем приходится быть малость внимательней, чем на дотнете, но зато типичных детских ошибок вижу всяко поменьше. ИМХО, от рабочего настроя тоже кое-что зависит. А в дотнет диктует некий расслабон (даже по собственным ощущениям, в сравнении с писаниной на плюсах).
T>>>2) Наличие коллстеков у всех исключений. V>>Помогает только для примитивных ошибок, и доступно для С++ тоже. G>Ага, но только в дебаг версии.
Не только.
V>>Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что... G>Вот только по-умолчанию C# рождает safe код, а unsafe без необходимости даже не ошибка, а вредительство. С++ имеет тяжелое наследие C и не наказывает за попытки писать в стиле С, то есть любой код по умолчанию — unsafe.
А как меня наказвают за исопльзование unsafe в дотнете, не пояснишь? И почему хак типов в стиле C есть на твой взгляд "нормально"?
G>Использование только safe части C++ делает программу не быстрее (а зачастую и медленнее) чем .NET
Стоило бы просить обосновать, но вряд ли справишься. По моим наблюдениям — ровно наоборот, чем больше типизированной информации у компилятора, тем агрессивнее оптимизация. И да, safe С++ не означает только библиотеки STL. Это просто типизированный подход, например, набивший оскомину выход за пределы массива на стеке, стиле С это так:
void doSomething(char * array, size_t size);
char array[N];
doSomething(array, sizeof(array)); // вот здесь могут подать не тот sizeof в результате многих актов рефакторинга
V>>Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки G>Ага, только они очень часто встречаются в unmanaged.
В сравнении с остальными ошибками, в т.ч. логическими — не видно и под микроскопом. Какая разница, падает программа или неверно работает? Лажа в обоих случаях.
V>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII G>Которым далеко не все пользуются
Ну я же говорил.
Рассуждая так, и контракты в C# мало кто проверяет, это же прямо такое "хакерство" (С).
V>>и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии G>Ну это когда размер известен на этапе компиляции.
Дык, а в других случаях самописанина ничего не дает в сравнении со стандартными контейнерами. Да и эскалацию привилегий ты при проходе по куче не получишь (по стеку надо идти, чтобы передать куда надо управление в текущем кольце), т.е. не получится той самой дырки в безопасности и обсуждать сразу нечего.
V>>что совершенно невозможно в дотнете G>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1.
Это если мы по всему массиву итерируем, а если нет, то лишней проверки не избежать. Уже обсуждали 4 года назад.
V>>Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак. G>v.end()++ не?
Не. Кто мешает мне компилируемую бредятину и на C# писать с тем же успехом?
Чем не коровья лепешка?
int SomeProp {
get { return _someProp; }
set {
_somePtrop = value;
if((new Random()).Next() < 0.5)
onSomePropChanged(this, EmptryArgs.Value);
}
}
Ничуть не хуже твоей.
V>>Это надо С++ использовать как голый С, для получения наиболее обсуждаемого здесь эффекта, ну так давай и сравнивать голый С с дотнетом, при чем здесь С++? G>Весь прикол в том что С++ унаследовал все проблемы C и никто тебе не запрещает использовать небезопасный код. А если использовать только безопасный, то C++ начинает сосать.
Дважды повторился, жду обоснований с примерами. В общем, в таком стиле это натуральный flame, так что за качество ответов на твои посты не обессудь.
G>Кроме того даже если ты напишешь safe код, то менее грамотный коллега напишет unsafe, который заставит твой код работать неправильно.
Менее грамотный, это год работы. Кто ж ему даст весь код трогать? В любом проекте при хоть какой-то организации полно изолированных мест, где могут разгуляться разработчики любого уровня. Ну и code review определенно рулит.
Здравствуйте, mrTwister, Вы писали:
T>Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.
Работаешь не там, значит.
V>>Дык, это не тот класс ошибок, который действительно напрягает. T>Ну это кого как. Меня уже достало искать подобные ошибки в С++ коде.
Могу повторить.
T>2) Надо модифицировать код, бросающий исключения, а это не всегда возможно.
Бред сивой кобылы
T>3) Можно получить очень сильную просадку производительности на ровном месте.
Могу повторить.
T>А в чем смысл? Если уж клиент согласен и в состоянии воспроизвести (что далеко не всегда так), то почему бы тогда полный дамп не сгенерировать?
Оперативнее, меньше инфы туда-сюда слать, да и клиент понимает, что ошибку найдут шустро. Иногда экспресс-патч вне основной ветки высылается в считанные минуты, если это blocker.
T>Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов. Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!
Ну... местные конторы "с самыми высокими ЗП на Украине" настойчиво многократно приглашают... Только предложить ничего не могут ни в плане интересной работы, ни по перспективам. У нас ведь в больших конторах рост может быть исключительно в менеджера, напр., по линии ПМ. Ну вот есть такая поголовная инвалидность в карьерных линиях наших контор. И не рассказывай мне сказки (С), что у вас это не так, я бы знал тогда, о какой конторе речь. Ты не обратил внимание, что плюсовики, достигнув некоторого уровня, поголовно уходят из наших "больших" контор в пользу буржуинских или своих собственных, небольших, если не видят себя по линии откровенного менеджерства? Или вообще съезжают "туда". Поэтому дефицит их, опытных, однако. Да только Intel с MS всех молодых талантливых плюсовиков стараются как корова языком подчистую слизывать, и еще куча контор поменьше. К дотнетникам, прямо скажем, отношение попроще. Ну т.е. висит в и-нете резюме, где и по плюсам и под дотнету неплохо, дык предложения относительно плюсов совсем не те приходят, что по дотнету, небо и земля.
V>>И я опять утверждаю, что дотнетные программы чаще плюют баги у клиентов, чем плюсовые, по итогам наблюдений за 8 лет. T>Я этого почему-то не наблюдаю.
Т.е. открыть ваш баг-трекер и там совсем мало багов по дотнетным продуктам? Не поленись пройтись интереса ради.
T>Повлияет тем, что можно набрать больше тестировщиков благодаря тому, что программисты быстрее исправляют ошибки.
Не понял, у вас баги найти не могут что ле? Это ты точно сказки изволишь рассказывать или кто-то кого-то водит за нос (со стороны разработчиков). Есть еще вариант, что ты не в теме, что у вас там происходит.
T>В результате больше ошибок будет найдено и исправлено во время тестирования. У нас, например, тестировщиков больше, чем программистов. Если бы не С++ код, то пропорцию можно было бы еще увеличить.
Бред сивой кобылы. А кто юнит-тесты пишут, и как они интегрируются с регрессионными? А с интеграционными? Что насчет тестопригодности компонент? Какие техники для этого используются в плюсах? А дотнете? Какова доля сугубо UI-кода в общей массе? И что же именно и как именно ищут толпы тестеров, если UI-кода не подавляющее большинство? Какие инструменты автоматизации тестирования применяются? Какая доля тестеров пишет автоматические интеграционные сценарии, а какая "тупо клацает по кнопкам"? Какую долю из них ты бы увеличил?
V>>Не принципиально абсолютно. Да и не помню я, чтобы сложные в поиске баги, т.е. занявшие хотя бы пол-дня на поиски, выскакивали чаще, чем раз в несколько лет.
T>Да, кстати. Мы тут недавно Critical Fix выпускали. Buffer overrun в одном из umanaged компонентов. Но, как мне тут объяснили, таких ошибок в реальной жизни не бывает. Значит мне это все приснилось
Ну так и у меня в прошлом году по осени "чиста плюсовый" баг был, который я почти рабочий день искал, а до этого аналогичный за 3 года до, искал с коллегой его двойной delete. Я не настаиваю, что таких багов нет, но на одной чаше весов проблемы длиной в день раз в несколько лет, на другой куча компромиссов и допущений, чтобы юзать дотнет... и как-то картинка очень обсуждаемая в итоге. Чем я тут и занимаюсь.
T>Там эту константную ссылку бережно сохранят и нагадят в нее потом.
Таки предлагаешь в С++ обязательно гадить, а в дотнете исключительно всё делать правильно? Я уже пытался привести в чувство, что таким макаром можно много до чего договориться.
T>Или, например, удалить популярный в этом топике кастомный аллокатор (вместе с кучей) до того, как забыты все ссылки на объекты из этой кучи.
Т.е. применен некий grow-only аллокатор (коль можно "просто забывать" все ссылки by design), но который в итоге обслуживает не только локальные данные. Т.е. опять предлагаешь преднамеренно гадить в С++, и далее по тексту...
T>Вариантов граблей, как обычно в С++ очень много.
Немногим больше, не спорю. Но интересно не кол-во граблей, а распределение ошибок по граблям. По моим наблюдениям, основная доля граблей, вычищаемых и исправляемых, никак не связана ни с языком, ни с платформой. Т.е. "обычных" ошибок во многие разы больше, чем ошибок, специфичных для технологий, вот в чем цимус.
Здравствуйте, gandjustas, Вы писали:
G>>>Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий? V>>При оперировании состояниями в небезопасном к исключению коде это еще оптимистично, бо негативных сценариев всегда больше позитивных. Я бы сформулировал так: на каждый позитивный сценарий есть целая куча негативных. G>Не спорю. Но ты на вопрос ответь. Ты предлагаешь тестировать негативные сценарии, которые по сути не нужны пользователю. Зачем это делать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вон, как здесь уже договорились до того, что аллокатор=гуру, скоро до указателей дойдёте.
Этот момент нереально повеселил. Шарпист добровольно по сути признал меня гуру, цирк на конной тяге!!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Ну и что? I>Цитирую себя: I>"на менеджед пишется примерно 99% всех проектов"
Хорошо. Ты меня убедил, что мне не стоило лезть в эту ветку. В сущности, обсуждать тут становится нечего сразу после "99%".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>1) Зачем ты это написал?
Ты просил что-нить про безопасность к исключениям.
G>2) Где тут блокировка писателей?
Прочел бы внимательно, это было дополнение/альтернатива популярному алгоритму read-copy-update для многопоточности.
G>3) Если писать в функциональном стиле именно такой код и получается.
Это НЕ функциональный стиль, это всего-навсего один из способов управления тем самым immutable shared-state. Наличие immutable результата не делает его функциональным автоматически.
G>Еще раз, что ты хочешь сказать?
"Напомните, что я спрашивал?" (С)
G>Ты не понял мысль. В десктопе можно точно также как в вед разделить state и логику. Логика stateless, state — это данные и интерфейс.
Америку открыл? Только эта схема в чистом виде практически бесполезна для современного ГУИ. Вот что тебе надо делать в вебе при долгих операциях? Аж ничего! А на десктопе ты запускаешь асинхронную операцию, относительно долгую, в это время позволяешь делать другие операции, потом приходит результат асинхронной операции, но данные относятся уже к "прошлому" времени, и должны быть накатаны на прошлые состояния. Ну и пока происходит одна асинхронная операция, никто не мешает запускать еще, если они не конфликтуют с текущими. Асинхронно приходят еще обновления от других участников процесса, каждый тоже предназначенный для своего представления о состоянии и т.д. Под эти сценарии лишь относительно недавно в дотнете вышла хоть какая-то инфраструктура (зачатки), т.е. в современных приложениях, аналоги этой инфраструктуры реализованы самостоятельно, в меру своей испорченности.
В общем, совет твой из разряда совета пользовать юнит-тесты. Абсолютно правильный и абсолютно бесполезный для 99.99% коллег.
G>Логика будет "нейтральный по отношению к исключениям код", а изменение состояния интерфейса происходит только тогда когда отработала логика без ошибок. Естественно "сообщение которое писал 15 минут" не потеряется.
Ну логика-то асинхронная, в нормальном приложении. Сама тоже использует ресурсы... Какое состояние и в какой момент времени менять и на что именно в итоге?
Не торопись отвечать. В общем, есть такая штука, как изоляция транзакций. Этих уровней изоляции и сценариев вокруг этого достаточно много. Давать простой совет по этой теме — демонстрировать поверхностность.
G>Обработка исключений будет сконцентрировала в PL, причем её можно не писать руками, а использовать runtime aop и policy injection для обработки.
Обработка исключений ортогональна безопасности к их возникновению и мне лень эти вещи обсуждать, особенно в дотнете, где все исключения являются наследниками одного, а сами исключения не являются проверяемыми.
G>Нот, это происходит тупо потому что вставляют try\catch, который только и выводит сообщение, в итоге программа продолжает работать, но данные порушены и сразу же вылетает следующий exception итд.
Серьезно?
А я-то думаю, чего это они...
G>Причем от native\managed такое не зависит вообще, я видел подобно поведение и в программах на delphi, и на C++, и .NET или java.
Покажи мне продукты на Дельфи?
G>Даже на курсах постоянно рассказываю истории про то что я видел именно в нативном коде на делфи. Там вообще ужос был с исключениями.
А я кроме Скайпа и программ-то на дельфи не видел...
Счастливчик ты у нас.
G>В .NET не надо схем городить, во-первых сборка мусора есть, во-вторых есть IoC-контейнеры, позволяющие централизовано управлять владением жизни объектов, в третьих писать логику надо с использованием immutable.
Во-первых, "централизовано" очень плохо стыкуется с "асинхронно". Во вторых, свои "надо" лучше держать при себе. Immutable надо только там, где надо, а в других местах это будет самый что ни на есть студенческий закидон, из разряда "любимый паттерн попользовать".
G>>>Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее.
Не интересовался, для чего тщательнее всего изучают именно относительные метрики надежности? Твое "гораздо более надежное" приложение уровня калькулятора, пусть имеющее надежность ~99.9%, будучи розданным тысяче клиентов, уже упадет хоть однажды с более 60% вероятностью. А если с той же надежностью делать проект в 1000 раз объемнее, то с той же вероятностью это приложение будет падать у каждого первого клиента. В общем, о надежности давай не будем. Веб штука классная, но там каждый отдельный запрос — это такой же маленький изолированный калькулятор, с очень высокой, ввиду своих размеров, абсолютной надежностью. А всю остальную надежность обеспечивает низлежащая инфраструктура. Наверно отсюда толпы индусов в вебе и буйный цвет PHP, из-за такой особенности этой техники.
G>А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.
Делать тебе нечего, за 20% гоняться... Если уж тратить время на оптимизацию, надо получать 2-4 раза, как первое приближение. Лучше на порядок, конечно, но это не всегда получается.
Здравствуйте, c-smile, Вы писали:
CS>Каждый DOM элемент в WPF это Common Language Runtime object instance. CS>Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д. CS>Десятки GCable things и набегают.
Дык, не получается. Я приводил тест. Создано было более 5000 контролов, в каждом из которых визуальное дерево образуют еще 5-10 вложенных. GC потратил на себя ничтожное время. Да, загрузка медленная, но не из-за GC.
CS>Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser. CS>Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий. CS>Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.
Пример с Evernote скоро станет, как Fire And Motion. Конечно, WPF сольет native. Тут без вариантов. Отсутствие интеропа, наличие огромного числа наработок для native кода. Evernote делали для .Net 3.5. Сейчас в WPF шрифты не плывут, известны разные ходы для увеличения пефоманса. И я бы хотел поглядеть на код, тогда смогу сказать, что Evernote-вцы выжали из WPF всё, что смогли. Недавно я установил их клиент: не сказать, что там мега-богатый UI. Не вижу причин, почему на нем WPF должно быть медленнее (исключая запуск .Net).
Здравствуйте, Banned by IT, Вы писали:
ГВ>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. BBI>Это синдром VladD2
Угу, и у Сиплюсников он проявляется слишком остро.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Ikemefula, Вы писали:
I>>>>Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты. ГВ>>>К чему это ты? I>>Да к тому же что и раньше — нет и не будет никакого ренесанса С++ и подобной ерунды. Доля нативной разработки чуток увеличится и все. Сначала была мода на джаву и дотнет и потому многие кинулись чуть не драйвера и низкоуровненвый рендеринг писать на C#. Вот такие проекты отсохнут сами собой и за счет этого увеличится доля нативной разработки.
ГВ>Хм. Взаимопротиворечивые предложения detected.
I>>Но рассуждатели по твоей ссылке почему то не учли рост объемов памяти, воможность значительно расширения возможностей системной шины, векторную графику и тд и тд. Так что нет никакого конца нересурсов. То есть, нынче узким местом является не процессорное время, а ввод-вывод тот же.
ГВ>Рассуждатели по моей ссылке делают такие выводы:
ГВ>
Applying these conservative scaling
ГВ>projections, half of that ideal gain vanishes; the path to 8nm in
ГВ>2018 results in a best-case average 3.7 speedup; approximately
ГВ>14% per year for highly parallel codes and optimal per-benchmark
ГВ>configurations. The returns will certainly be lower in practice.
Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%.
I>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
ГВ>Производительность CPU от диска не зависит.
Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.
G>Есть тестирование чтобы предотвратить случайные ошибки, есть управляемые среды, которые просто не допускают некоторые классы ошибок.
Эээ... Ты сейчас понял хоть, что сказал? Управляемая среда не может "не допустить ошибку" выхода за пределы, например, она честно выплюнет баг... И если повезет — во время тестирования. Но в плане "недопущения" — это фантазии.
К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет.
G>Процент багов, связанных с неправильным кодированием, попадающими в production очень низок.
Процент от объема логики или от чего?
V>>И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию. G>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна).
Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования.
G>А разницы между потоком и запросом почти нету на самом деле. Можно одно свести к другому и наоборот.
Нельзя. Каждый запрос — локален, независим от остальных. Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние.
Здравствуйте, Ikemefula, Вы писали:
I>>>Отлично. Все программы — нативные. А следовательно быть никакого ренесанса и конца нересурсов быть не может. ГВ>>Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк. I>Да не вопрос. Но других то определений нет и не предвидится
А зачем оно нужно? Есть классические определения: интерпретатор, компилятор, исходный текст, p-код, код целевого процессора. Native — это сокращение для жёлтой прессы: что, мол, native development бла-бла-бла. Обозначают им программы на C и C++.
А то развели, понимаешь — указатели, работа с ОС... Осталось грамматики и аппаратные прерывания сюда приплести.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>И ты сходу привел решение, далекое от оптимальности
Пора переходить к конкретике.
Можешь привести пример WPF приложения которое работает соизмеримо с аналогичным native?
Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично.
И у которых была и есть железная мотивация сделать хорошо.
Если есть другой пример — прошу.
Хочется верить что мы тут все грамотные люди поэтому в состоянии вычислить почему что-то тормозит или наоборот летает.
Здравствуйте, Ikemefula, Вы писали:
I>Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки.
Числодробилки тоже важны. А CLR team, несмотря на давние обещания, так пока ничего в этом плане не выкатила. Хотя обещала и интринсики для SSE, и специальный, распознаваемый джитом дженерик интерфейс у числовых типов для процессорной арифметики, и оптимизации для работы с большими непрерывными кусками памяти.
Так что на данном этапе для задач, связанных с перевариванием объемных данных типа некоторых видов HPC или тех же видеокодеков CLR подходит не очень хорошо.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
V>>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов. G>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
Ты их по скорости сравнивал? Как ты думаешь, каковы различия в скоростях выполнения вот этих конструкций (чтобы уж от онтопика не отходить):
C++:
std::accumulate(v.begin(), v.end(), c);
C++ STL+лямбда:
std::accumulate(v.begin(), v.end(), c, [=](long long acc, long long v) -> long long { return acc + v; });
C# foreach:
foreach (var k in v){ c += k; }
C# Linq:
v.Aggregate(c, (acc, k) => acc += k, acc => acc);
Во всех случаях v значит "вендетта" массив 64-битных целых.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
V>>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере. G>По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код.
V>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
Какой именно сервер? MS SQL? А при чем тут дотнет-то? Это ж нубство натуральное писать такой код, который должен занимать "много ресурсов" управляемого кода. Ты профанируешь тем самым саму суть ASP.Net, которая позиционирует себя как относительно легковесное решение в пересчете на запрос.
G>Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами. Нейтивного управления, разумеется. В MS над этим голову бьют, стараясь держаться на уровне конкурентов, а некий Вася Пупкин на весь интернет считает, что его прочитанное и показанное лишь спустя секунду поле из базы данных всяко важнее. Весело в тобой.
V>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G> G>Посмотри сколько данный форум возвращает, и не говори бредятину.
И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз.
V>>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. G>Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
Мде? Покажи мне, в каком месте он не согласен? Нашел ты, однако, "ресурс", который суть текстовый формум. Ты еще социальную сетку какую-нить приведи в пример. Я тебе быстро покажу, как ее реальное быстродействие замерить.
V>>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++) G>Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить?
G>И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал?
G>И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
Как тебя почитать, так ты окромя дотнета вообще ничего не видел... А я здесь при чем?
По данным Netcraft Web Server Survey за июнь 2011 года, доля веб-сервера Microsoft IIS на всех доменах в Сети продолжила падать и с майских 18,37% опустилась до уровня 16,82%. Это самый низкий показатель с конца 1997 года.
V>>Ты просто очень далек от современной ситуации в web, судя по твоим постам... G> G>Зато ты близок... сколько ты вебовых приложений написал то?
О! Можно вынимать и демонстрировать?
Если за всю карьеру, то около десятка, из них 3 на ASP.Net. Есть с чем сравнить. А если брать не чистый веб, а всякие сервисы, просто многозвенки и распределенные архитекруты по различным протоколам (пару десятков протоколов навскидку), то, скажем так, на конкретно ASP.Net я могу посмотреть со всех сторон. Не только как "чисто-вебной" части, когда принимается решение на чем делать HTTP-часть, но и чуть раньше, как инструмент реализации GUI, когда принимается решение, делать ли веб-морду, или таки классический GUI-клиент. Например, однажды был взят ASP.Net для генерации Silverlight-приложений, которые отображаются во вкладках IE (!!!) локальным сервисом (вовсе не 80-й порт) в плагине к этому IE. Такое решение оказалось намного интересней в плане отзывчивости, чем GUI этого плагина на WPF + локальный WCF сервис. Еще пару раз брал ASP.Net как либу для нетривиального рантайм-редеринга текста (т.е. не как out-of-proc сервер, а именно как либу). Это помимо классического веба. Т.е. эту примочку к IIS раком ставить умеем вдоль и поперек, не переживай... и даже хакать и корректно юзать MS Embedded SQL с ASP.Net, чтобы сравняться по эффективности с MySQL на зачитке (смогешь так?).
Сравнить с аргуентами: "для моих задач хватает", "все пишут на ASP.Net"... и это при ~17% реальной живой доле и отрицательной первой производной.
V>>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать... G>Плати бабло — сделаю. Мне не сложно.
Так и думал...
но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность.
Здравствуйте, gandjustas, Вы писали:
V>>Быстрая сортировка. Нарисуй-ка inplace без foreach. G>.Sort
Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach.
Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой?
V>>Опять read-only. G>И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание.
Именно, в очень некоторых быстрее. В которых все остальные тоже юзают. Но где надо действительно быстрее, не катит.
G>В каких базовых вещах? Ты банально не знаешь как писать на C# и пытаешься писать на нем как на C++, а потом жалуешься. Это и называется "не в теме".
Пока ты по-существу не ответил ни на одно замечание по теме, а пытаешься снова и снова обсуждать роль С++ в формировании личности оппонента.
G>Для моих задач быстродействия linq более чем хватает
Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться?
V>>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов. G>Ага, только эта ошибка логики программы проявляется только в unmanaged
Именно, явно проявляется, о чем и речь! А в managed ее надо долго и нудно искать, и вообще сложно воспроизвести, т.к. ошибка дает себя знать не в момент, когда срабатывает ошибочный код, а по косвенным признакам.
V>>На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно. G>Практика показывает что: а) нельзя, потому что сборщика мусора нет б)не будет эффективнее
При чем тут сборщик мусора и библиотека boost::bind, например? Никакой памяти из кучи не выделяется, и никакой мега-тормозной технологии, типа создания делегатов для однократного вызова, не используется. По моим замерам, стоимость использования boost::bind сравнима со стоимостью вызова обычного метода, в отличие от процедуры создания и вызова делегата (в 5-50 раз дороже, зависит от того, сколько раз был вызван только что созданный делегат).
V>>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. G>Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
Мы пока обсудили всего две ошибки, причем, характерная для native всего одна из них (и то не факт, при таком как у вас тестировании).
V>> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили). G>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>Так вот во всех них обычный for крайне редко встречается.
Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
V>>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить? G>Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз.
G>Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
Это ты только что сам придумал? Вообще-то, эффективность нужна "лучше, чем у конкурентов", чтобы продавать коробочное ПО. И даже в заказном ПО при условии честных тендеров, как ни странно, тоже.
G>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности.
Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего.
V>>Иначе бы никто не искал программистов С++ сегодня. G>Ищут их в основном для саппорта.
Нет.
V>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>Не пишется, а саппортится, пишется на порядки меньше.
Опять мимо.
G>>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>>В каком месте? G>например умные указатели с подсчетом ссылок.
Такие указатели используются (1) редко в коде, (2) редко в рантайм, обычно для самых высокоуровневых объектов, которые живут практически столько же, столько и вся программа. Для оперативных данных это используется разве что на этапе макетирования или когда некритично быстродействие. Т.е. когда твой аргумент не работает.
V>>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших. G>А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана.
Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок.
Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента.
G>>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>>Детсад. G>Правда жизни. Ты много процесс тестирования организовывал?
Дык, нет у вас собственно процесса. Самодеятельность одна, основанная на субъективных представлениях о том, "как надо". Сорри, но к теме "качество ПО" и организации контроля ка-ва ПО ты пока в своей карьере еще не приближался.
G>>>Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе. V>>Детсад. G>См выше.
Ну что смотреть-то? Неужели нельзя хоть немного подумать самому, уже ведь все входы и выходы показал. Ты же абсолютно правильно всё написал в начале абзаца, только надо обязательно уточнить, что сей алгоритм доступен только как "private" в таком сценарии, и на него не делаются публичные бинды, типа подписки на события или просто возвращения наружу делегатов. Это принципиально! Ну а потом скатываешься на натуральную ересь, потому как проверять твой assert без негативных тестов смогут только клиенты. Нафига же ты его ставил? Да еще, в зависимости от используемой технологии ассертов, их или не будет в Release-конфигурации, т.е. понеслась любимая всеми плавающая ошибка, или они будут, но плюнут в клиента самое неудобочитаемое для него сообщение (это залет, курсант!). И что о вас подумают люди? Не надо так подставлять свою контору.
G>Тем не менее точность есть. Каждый просмотр подсчитывается.
Это не есть точность, если не каждый фиксируется в базе. Например, сбойнет чего-то на серваке и часть значений по последним полностью законченным сеансам пропадет. Здесь не страшно, но в финансовой сфере, к примеру, это недопустимо.
V>>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр. G>Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
Да понятно, кто над чем работает, у того такие представления. Мне всё время охота сказать, что "большинству нужен", но я прекрасно понимаю что это не так, або биография была бурная, делал даже автоматизацию офиса, поэтому ограничиваюсь фразой "много где нужен"...
Интересуйся больше окружающим, сходи на другие разделы этого же форума, например. Хотя бы в multimedia.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Быстрая сортировка. Нарисуй-ка inplace без foreach. G>>.Sort
V>Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach.
Зачем? Это ведь написаный, протестированный и отлаженный не мной код. Там OutOfRangeException не возникает. Я его использую и у меня не возникает.
Мы ведь говорим за код приложений.
V>Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой?
Ты удивишься но написание почти всего кроме быстрой сортировки на месте и умножения матриц не требует цикла for.
V>>>Опять read-only. G>>И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание. V>Именно, в очень некоторых быстрее. В которых все остальные тоже юзают. Но где надо действительно быстрее, не катит.
Ну а там где не быстрее можно параллелить. А если не хватает CPU, то можно и на GPU. Причем для всего есть managed средства и почти нигде не надо писать for.
G>>Для моих задач быстродействия linq более чем хватает V>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться?
Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
V>>>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов. G>>Ага, только эта ошибка логики программы проявляется только в unmanaged
V>Именно, явно проявляется, о чем и речь! А в managed ее надо долго и нудно искать, и вообще сложно воспроизвести, т.к. ошибка дает себя знать не в момент, когда срабатывает ошибочный код, а по косвенным признакам.
Не, в managed просто нет таких ошибок или сразу exception. То что привел ГВ — чистой воды совпадение, причем полученное сочетанием десятка факторов, и далеко не все они являются безошибочными сами по себе.
V>>>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. G>>Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
V>Мы пока обсудили всего две ошибки, причем, характерная для native всего одна из них (и то не факт, при таком как у вас тестировании).
Из-за ошибки реинтерпретации памяти(обращения по невалидному указателю) и отсутствия контроля выхода за границы происходит большинство проблем unmanaged.
Попытка избежать проблем ведет к резкому усложнению и\или к снижению производительности.
V>>> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили). G>>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>>Так вот во всех них обычный for крайне редко встречается.
V>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
V>>>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить? G>>Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
V>Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз.
Меня не интересуют низкоуровневые детали, пусть хоть полностью в unmanaged перепишут. Меня как раз интересует прикладной код и библиотеки прикладного кода. Linq например импользуется чаще, чем StringBuilder и внутри первого нету for и массивов, а внутри второго есть.
G>>Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
V>Это ты только что сам придумал?
Нет, это правда жизни. Не бывает медленных программ, бывают недостаточно быстрые.
V>Вообще-то, эффективность нужна "лучше, чем у конкурентов", чтобы продавать коробочное ПО.
Не-а, когда обе программы "достаточно быстрые", то уже не быстродействие является главным козырем. Причем быстродействие десктопных программ это не только и не столько скорость выполнения кода.
V>И даже в заказном ПО при условии честных тендеров, как ни странно, тоже.
В заказном ПО как раз заранее характеристики обговариваются и никто не парится сделать максимально быстрым.
Хотя как раз в обоих случаях сроки разработки важнее скорости работы программы, особенно для первых версий, потому что начав продавать можно уже работать за деньги клиентов, а не их своего кармана.
G>>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности. V>Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего.
Действительно? Только я за это время успел из рядового программиста стать преподавателем, MVP, очень востребованным специалистом и руководителем небольшой фирмы, по пути поработав и тилидом и немного ПМ.
V>>>Иначе бы никто не искал программистов С++ сегодня. G>>Ищут их в основном для саппорта. V>Нет.
Как раз да. Приведи ссылку где набирают C++ про новый проект, только не новую версию старого.
V>>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>>Не пишется, а саппортится, пишется на порядки меньше. V>Опять мимо.
Ну конечно, у тебя просто прямое подключение к богу статистики и ты все лучше знаешь.
Итого на пару NET и Java в 4 раза рвут C++. При этом если посмотреть на вакансии C++ особенно в москве, то плакать хочется. ЗП
G>>>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>>>В каком месте? G>>например умные указатели с подсчетом ссылок.
V>Приводил уже статистику: http://www.rsdn.ru/forum/philosophy/4506914.1.aspx
Ну это только твой кож, а если глянуть другие проекты...
V>>>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших. G>>А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
V>Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана.
И то и другие — инструменты.
V>Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок.
В CodeContracts тоже есть ассерты если что
V>Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента.
А если напишешь проверку то что? Кинуть exception? Ассерты говорят что какое-то условие должно выполнятся всегда, то есть вообще всегда — не выполняется, надо править программу, зачем еще что-то писать для того же резльтата? Если в процессе тестирования ассерт не выпадал, а выпал у клиента при нормальной работе, значит и процесс тестирования надо улучшать.
G>>>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>>>Детсад. G>>Правда жизни. Ты много процесс тестирования организовывал?
V>Дык, нет у вас собственно процесса. Самодеятельность одна, основанная на субъективных представлениях о том, "как надо". Сорри, но к теме "качество ПО" и организации контроля ка-ва ПО ты пока в своей карьере еще не приближался.
Смешной ты, много ты процесс тестирования организовывал? Я то как раз прекрасно знаю про качество знаю и знаю где находится граница good enough.
G>>Тем не менее точность есть. Каждый просмотр подсчитывается. V>Это не есть точность, если не каждый фиксируется в базе.
Каждый
V>>>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр. G>>Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
V>Да понятно, кто над чем работает, у того такие представления. Мне всё время охота сказать, что "большинству нужен", но я прекрасно понимаю что это не так, або биография была бурная, делал даже автоматизацию офиса, поэтому ограничиваюсь фразой "много где нужен"...
Учитывая быстродействие и дешевизну железа — почти нигде не нужен
V>Интересуйся больше окружающим, сходи на другие разделы этого же форума, например. Хотя бы в multimedia.
О, да. Тут послушать так все минимум софтом для космических кораблей занимаются. А я занимаюсь софтом, который бабло приносит.
Здравствуйте, AndrewVK, Вы писали: AVK>>>А ты смотрел? Навскидку — основные изменения в 4 рантайме? V>>Я изменения смотрю по замерам, с некоторых пор. AVK>Ясно. Т.е. не смотрел.
Описания изменений оптимизатора (коль такое есть в природе) действительно не смотрел. Потому что запускал такое:
Скрытый текст
using System;
using System.Diagnostics;
namespace ConsoleApplication6
{
struct Filter
{
float z1, z2;
public float K0, K1, K2;
public float Process(float sample)
{
var tmp = z1;
z1 = sample * K0 + z1 * K1 + z2 * K2;
z2 = tmp;
return z1;
}
}
class Box<T>
{
public T Value;
}
class Program
{
static void Main(string[] args)
{
var rnd = new Random();
const int N = 1000000;
var data = new float[N];
for (int i = 0; i < N; i++)
data[i] = (float)rnd.NextDouble();
var filter = new Box<Filter>();
filter.Value.K0 = (float)rnd.NextDouble(); // для исключения "случайных" оптимизаций
filter.Value.K1 = (float)rnd.NextDouble();
filter.Value.K2 = (float)rnd.NextDouble();
var timer = new Stopwatch();
// разогрев
timer.Start();
timer.Stop();
Test1(filter, data);
Test2(filter, data);
timer.Reset();
timer.Start();
Test1(filter, data);
timer.Stop();
Console.WriteLine("Result1: " + timer.ElapsedTicks);
timer.Reset();
timer.Start();
Test2(filter, data);
timer.Stop();
Console.WriteLine("Result2: " + timer.ElapsedTicks);
timer.Reset();
timer.Start();
Test1(filter, data);
timer.Stop();
Console.WriteLine("Result1: " + timer.ElapsedTicks);
timer.Reset();
timer.Start();
Test2(filter, data);
timer.Stop();
Console.WriteLine("Result2: " + timer.ElapsedTicks);
Console.WriteLine("Press enter...");
Console.ReadLine();
}
static float Test1(Box<Filter> filterObj, float[] data)
{
float value = 0;
for (int i = 0; i < data.Length; i++)
value = filterObj.Value.Process(data[i]);
return value;
}
static float Test2(Box<Filter> filterObj, float[] data)
{
float value = 0;
Filter filter = filterObj.Value;
for (int i = 0; i < data.Length; i++)
value = filter.Process(data[i]);
filterObj.Value = filter;
return value;
}
}
}
Результаты тестов отличаются на 1.5%, и практически одинаковы соответствующие результаты для 2-го и 4-го фреймворка (в пределах погрешности)...
Сгенеренный ассемблерный код тупой до безобразия, в цикле загружает данные в плавающие регистры каждый раз заново, вместо перемещения м/у регистрами. Про неиспользование SSE/SSE2 я уже даже не заикаюсь. Использовал клиентский профайл.
Здравствуйте, Sinclair, Вы писали:
V>>Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем. S>Осталось показать код. А то получается, что теоретически программисты владеют всеми приёмами на уровне мозжечка, а на практике пишут совершенно без них.
Только что с предыдущего проекта сделал глобальный поиск по new:
std::auto_ptr<AsyncRestartThread> thread (new AsyncRestartThread (*this));
restartMutex (new Mutex) // приватное поле
std::auto_ptr<SessionImpl> sessionPtr(new SessionImpl(this, isDefault));
impl (new Impl()) // приватное поле
boost::shared_ptr<ListenersState> state (new ListenersState);
obBroadcastQueue_.reset(new BroadcastQueue());
ordersBroadcastQueue_.reset(new BroadcastQueue());
std::auto_ptr<TradingState> statePtr (new TradingState ());
std::auto_ptr<Series> seriesPtr(new Series(makeSeriesId(item.series), *instrumentClass));
return MultithreadGuardPtr(new MultithreadGuard(callback));
std::auto_ptr<Entry> entry(new(mem) Entry()); // а это свой аллокатор, происходит inplace new
boost::scoped_array<char> tmp(new char[recvLen]);
broadcastThread_.reset(new BroadcastThread(*this));
В голый указатель шел результат new только в приватные поля объектов.
Кстати, самого сие нехило удивило (мягко сказано!!!), что в таком приличном проекте так редко используется new, приведена примерно треть от всех ситуаций (слишком "говорливые" идентификаторы был вынужден убрать, но в убранном все тоже самое). В остальных случаях объекты идут по значению в полях других объектов, либо как временные на стеке, т.е. относительно общего числа типов и сценариев, необходимость каждый объект-молекулу размещать на куче крайне и крайне редка. (хотя, некоторые идут в контейнерах, а те хранят свои ячейки на куче, справедливости ради). Но всё равно, иногда полезно собирать статистику, всё даже лучше, чем казалось.
Здравствуйте, Sinclair, Вы писали: ГВ>>И они оба сильно отстают от: ГВ>>
ГВ>>for (int j = 0; j < ArrSize; ++j)
ГВ>> for (int i = 0; i < ArrSize; ++i)
ГВ>>
S>В релизе? Не из-под студии?
Угу, x64. S>Очень, очень странно. Опубликуй, пожалуйста, программу — студии под рукой нет.
См. ниже. Бинарник. S>И, да, выкинь нахрен DateTime. Пользуйся System.Threading.Timer.
Как тут поможет Timer? ГВ>>Хотя массив создаётся в той же функции и казалось бы, можно определить константную длину. S>К месту создания массива это отношения не имеет. Ресайза массивов в дотнете нет, поэтому можно закладываться на постоянство arr.Length в любом случае.
Код под катом.
Скрытый текст
using System;
namespace ArrayOnly
{
class Program
{
const int ArrSize = 50000;
const int IterCount = 5;
static void assign(long[] arr, int index, int val)
{
arr[index] = val;
}
static void testFunc2()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0; j < arr.Length; ++j)
for (int i = 0; i < arr.Length; ++i)
{
assign(arr, i, i * j * c);
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0; i < arr.Length; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void testFunc1()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0, je = arr.Length; j < je; ++j)
for (int i = 0, ie = arr.Length; i < ie; ++i)
{
assign(arr, i, i * j * c);
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0, ie = arr.Length; i < ie; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void testFunc()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0; j < ArrSize; ++j)
for (int i = 0; i < ArrSize; ++i)
{
assign(arr, i, i * j * c);
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0; i < ArrSize; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void Main(string[] args)
{
testFunc();
testFunc1();
testFunc2();
System.Console.WriteLine("Press Enter to exit...");
System.Console.ReadLine();
}
}
}
Вывод (VC2010 -> x64, Win 7):
C# for (int i = 0; i < ArrSize; ++i): 1064,6609 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 1417,08104 ms
C# for (int i = 0; i < arr.Length; ++i): 1418,88116 ms
Press Enter to exit...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
KP>>А почему тогда приложения на плюсах работают быстрее?
AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
Уж насколько я люблю дотнет, но, пожалуй, признаю, что при равной квалификации разработчиков версия на С++ почти всегда будет работать быстрее (отбросим граничные случаи).
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?
I>Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.
;;;;
;;;; Common Lisp IDENTITY function.
;;;;
(defasm identity (obj)
{
push ebp ;; link new frame
mov ebp, esp
cmp ecx, 1 ;; check number of arguments
je short :next
callp _wrong-number-of-args-error
:next
mov eax, [ebp + ARGS_OFFSET] ;; return argument in eax
mov ecx, 1 ;; returning a single valuepop ebp ;; unlink stack frame
ret
})
Здравствуйте, FR, Вы писали:
S>>Добро пожаловать в реальный мир, Нео. FR>Посмотри лучше FR>http://stlab.adobe.com/group__asl__overview.html FR>или http://www.chromium.org/Home
Спасибо, посмотрел.
Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей.
Тем не менее, никаких умных указателей всё же нет — похоже, проще вообще обходиться без них, чем использовать.
Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.
Можно, MSIL типизированный, аннотированный и верифицируемый на предмет типобезоасности, поэтому всякие сценарии иммутабельности, распространения констант, локальности времени жизни объектов с виртуальными вызовами и т.д. выявляются уже относительно локально. А если брать технологии глобальной суперкомпиляции, то там вообще способ представления исходной информации не принципиален. Другое дело, что для дотнета к оптимизациям еще и не приступали...
ГВ>Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
GC это да, ограничение для многих оптимизаций, т.к. стек должен быть детерминированно размечен для целей GC, хотя бы "иногда". ИМХО, это и есть камень предкновения для оптимизаций GC. Сдается мне, что еще не готов теоретический аппарат, насчет того, где оптимально расставлять ловушки для GC и обеспечивать детерминированность стека, а где можно все соптимизировать нафик в безымянных SSE регистрах даже для целочисленных операций, как это делает компилятор C++.
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?
I>Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.
Для сравнения у меня вышло под x86, как и ожидалось:
C# for (int i = 0; i < ArrSize; ++i): 4134,00722 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 4056,00706 ms
C# for (int i = 0; i < arr.Length; ++i): 2892,24506 ms
Обещанная оптимизация дала профит.
Для x64:
C# for (int i = 0; i < ArrSize; ++i): 889,20154 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 2037,36356 ms
C# for (int i = 0; i < arr.Length; ++i): 1344,72234 ms
Непонятно, с чего такая разница x86/x64 в быстродействии, под С++ такой разницы нет.
Ну и расстановка результатов совсем другая.
Здравствуйте, vdimas, Вы писали:
V>Если убрать из стандарта C++ приведение в стиле С, то этого было бы достаточно. Никак не могут пойти на этот важный шаг, бо сломается туева хуча программ. Но результат, ИМХО, того стоит, бо всякие reinterpret_cast видны, т.е. не представляют из себя тех самых "незаметных мин" в коде... а во всех остальных местах код будет несильно уступать Хаскелю по типобезопасности.
Здравствуйте, samius, Вы писали:
S>Я тут как-то налабал комбинаторный парсер CSS на шаблонах. Ну то есть совершенно не постеснялся их использовать по случаю и без, любая комбинация принимала выводила типы параметров-парсеров и выдавала в качестве результата новый тип. Получил 5Мб бинарников. В этом случае оптимизатор link-time ничего сделать не мог даже теоретически. S>Пришлось выделять абстракцию и учить комбинаторы работать с ней.
Комбинаторные парсеры — это антинаучная лажа. Сорри, но сие так.
Более менее попытались вывести мат-аппарат для популярного здесь PEG-семейств грамматик (тоже близко к комбинаторным), но почитай критику и тонкие моменты таких парсеров. Я так и не созрел их юзать. А использовать произвольные комбинаторные парсеры — ну это разве что для "по-быстрому на коленке". Твои 5МB говорят о том, что минипарсеров было оч. много, т.е. на примитивный случай там никак не тянет. Надо было делать как положено: брать семейства GLR/LALR или LL(K). Навскидку, в CSS грамматике оч мало неодногзначностей (или нет совсем, так?), поэтому GLR или LL(1) парсеры будут отрабатывать за время, близкое к O(n), что комбинаторным и не снилось никогда. Ну и размер бинарника собственно парсера максимум в десятки К.
Правда, продолжать тему не буду, уже когда-то ломали копья и по поводу PEG и по поводу комбинаторных парсеров, легче найти те обсуждения, чем повторяться.
V>>Признаюсь, я был сильно в 2002-м году удивлен, когда в релизном коде обнаружил, что getI и getF имеют один и тот же адрес, т.е. вместо двух ф-ий в бинарнике осталась только одна. S>
угу, размер-то типов одинаков, т.е. в терминах машинного кода всё одинаково.
S>Вот, общее тело ведь принимает длину параметром метода, а не template-параметром? Если да, то вопрос снят.
ммм... поясни мне, чем для снипета:
std::copy(src, src + size, dst);
разница, откуда был взят size, из параметра шаблона, или как константный параметр ф-ии? Для шаблонного, то бишь инлайного исполнения, эта разница стирается. Это код относительно безопасен в месте декларации (т.к. в одном экземпляре и скрее всего обложен юнит-тестом), но опасен во всевозможных местах вызова из всех сценариев и оперируемых типов данных, поэтому его неплохо иметь во внутреннем неймспейсе или в приватном методе, а в открытых иметь типобезопасные инлайные "точки входа".
S>Я использую точки входа, просто подумал на тот template что он есть общее тело.
Иногда он и есть единственное и неповторимое тело, если сами пишем, какие проблемы?
Все-равно внутри будет вызвана итерация по элементам через какой-нить STL/boost algorithm с каким-нить bind-замыканием, так что "точкой входа" было бы неплохо сделать код, выполняющий итерирование. И для контейнеров, совместимых с STL, тоже. Поэтому код точек входа мог быть другой, чем я приводил, если бы целевое тело писалось нами, а не было бы неким АПИ в стиле С, над которым мы делаем типобезопасные обертки.
Здравствуйте, gandjustas, Вы писали:
V>>Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код. G>Что значит "первичная бизнес логика", чем она от вторичной отличается?
Наверно тем, что клиент не располагает всеми данными, и может лишь верифицировать поля по статическим ограничениям, либо по ограничениям, зависящим только от данных в рамках одной записи (грубо).
G>Ты наверное не соображаешь что если дать возможность клиенту проводить вычисления, а потом посылать резльтаты на сервер, то это может быть не согласовано с логикой на сервере.
Тихий ужас просто... Сервер на ASP.Net выдает динамические HTML-страницы, которые не согласованы с собственной логикой... Дай пожму твою мужественную руку! Это просто титанический труд... это ж еще суметь такое надо!
G>Поэтому сейчас ни одно приложение не имеет логики на клиенте, на клиенте располагается код для обработки UI и не более того.
Прямо сейчас я не видел ни одного вменяемого, где бы поля не верифицировались первично еще на клиенте. Ну и подгрузка и аплоад AJAX-данных всегда управляется логикой на клиенте, то бишь просто огромный пласт логики целиком едет на клиента и там прекрасно живет.
V>>>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>>>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
V>>Какой именно сервер? G>Лобой. Это чтобы ты понял что объе данных не коррелирует с полезностью и заратами.
Да понял я понял. Не коррелирует. Бывает такой Transact SQL в природе. Очень опасная для тебя штука, похоже, ведь может случится несогласование с логикой. Поэтому надо пол-базы грузануть, на управляемом коде перелопатить, а потом нести самую отпетую пургу, какую я только слышал, насчет корреляций объемов данных, затрат и полезности. Правда, просмотрев весь контекст, я вижу, что речь здесь может идти только о полезности программиста? А оно, соглашусь, ни с чем тут не коррелирует.
V>>С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами. G>Эффективная отдача заключается в том чтобы не забирвать канал, о отдавать ровно столько сколько клиент сможет принять учитывая характеристики канала и возможности клиента.
Интересно. Не пояснишь на пальцах, а как возможно иначе для TCP? (в отличие от UDP, где это таки возможно)
G>И одна из самых эффективных реализаций такого сейчас сделана угадай где? Правильно в самом ненативном silvelight. От тупо считывает разные файлы с сервера в разным bitrate в зависимости от загруженности канала.
С какой версии сервелат перестал быть нейтивным? Из всех версий фреймворков, в нем закодировано в нейтиве больше всего, включая собственно сервелатное GUI и всё медиа. И уж управление QoS, если ты о нем, и диспетчеризация приоритетов в драйвере QoS, никогда не выполнялись в managed. Из managed можно разве что через pInvoke вызвать ф-ию открытия сокета с желаемыми предустановленными параметрами QoS, больше ничего. А уж как пойдут данные — от дотнета уже не зависит. Если же ты о проигрывателях медиа в сервелате, то при чем тут дотнет? Открой любой, даже самый старый проиграыватель, и в нем есть параметр — длина буфера (в ед. измерения времени). Проигрыватель медиа всегда подкачивает данные чуть вперед, но агрессивно не больше чем до заполнения буфера. Ну и надо понимать особенности TCP. Наиболее эффективно передавать данные с постоянной скоростью, т.е. с постоянным размером окна. Как только окно начинает дергаться, так кол-во служебной информации и общее кол-во пакетов возрастает.
V>>>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G>>> G>>>Посмотри сколько данный форум возвращает, и не говори бредятину.
V>>И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз. G>А какая разница? Из них же все равно надо склеить html, или ты думаешь что это бесплатно делается?
Именно. Приклеить сообщение в 50 байт стоит практически столько же, сколько приклеить сообщение в 1000 байт. Не веришь — измерь сам скорость вставки в StringBuilder. Тоже самое касается парсера потока MS SQL, — единичное текстовое поле парсится за фактически константное время независимо от размеров, т.к. затраты на копирование области памяти в сравнении с затратами на обыгрывание всего остального — ничтожны.
G>Ну замерь "реальное быстродействие" stackoverlow, посмотри какие там юзкейсы есть и статистика прям на главной.
Легко, кидаешь куда-нить на локальное ГУИ ActiveX IE-контрол, смотришь в какие ID элементов что внести, пишешь скрипт, например на VBA, и после отправки замеряешь время получения обновленной страницы с твоим сообщением. У меня для социалок выходили 1,5-3 сек, при пинге 80ms. Вот и прикинь быстродейтвие. При том что для такого сценария, коль скрипт отрабатывает практически сразу, скорее всего TCP-коннекшен еще жив после запроса самой страницы. В общем, это такой порядок цифр, где обсуждать сразу нечего. Для сравнения, обычная многозвенка, с десктопной мордой, при отключенном нагиле каждому клиенту способна выдавать десятки "страниц" (форм) в секунду. Т.е. это не общая пропускная способность, а именно оборот по одному независимому клиентскому коннекту, которых тоже десятки. Ну и реакция аппликухи при изменении данных молниеносная, разумеется. Вот почему я веб терпеть до сих пор не могу, бо там не ГУИ, а издевательство над психикой.
G> Ты смешон
Мне тоже нескучно.
V>>Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить? G>Я ссылку открыл, там на странице ни одного слова про C++ или native, веб-сервер Apache. Скорее всего там PHP. Для отображения используется flash.
Значит, не смотрел. Там используется shockwave player, это не flash, хоть одной и той же конторой писанное. А исходники библиотеки доступны для скачивания.
V>>Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал? G>Не понял о чем ты. Я спрашиваю почему на C++ мы не видим сотен сайтов если все так плохо у ASP.NET? Кстати большинство сайтов на ASP.NET прекрасно работают с достаточным быстродействием.
Наверно, потому что веб-технологии тормозные, сойдет и так. Но корпоративные приложения бывают далеко не только веб. Прямо на Оракле чудесно пишут приложухи, и прямо оттуда бинд на джаву. И клиенты — оч тонкие вебовские или десктопные морды. В одном из проектов сервер был хоть и дотнетный (сервер приложений, не веб), клиенты к нему были как дотнетные, так и нейтивные. А сам сервак вызывал основные достаточно тяжелые операции, писанные на плюсах. Целиком дотнетные были только задачи общения с базой (бо данных немного) и построения метаинформации для прикладных сущностей.
G>Да без разницы, возьми apache\php, с++ в вебе в микроскоп не видно. Хотя я уверен что у php парсер TDS работает не быстрее .NETного
Я тебе показал, что и ASP.Net не особо видно. Заметь, я не утверждал, что "все пишут сервера на плюсах", в отличие от тебя, так что не юли. Я говорил, что возможность такая есть и пишут. Даже взять начинку марштрутизаторов, например, с администрированием по HTTP, начинка обычно плюсовая, и ссылки на популярные HTTP-либы для этого тебе давались.
G>Круто.. Я три на asp.net сделал за первый год. Причем особо извращений не было, даже лечил некоторые извращения таких умельцев "раком ставить".
Супер! Хорошее приложение начинается от 3-5 человеколет, так что примерную "трудоемкость" своих проектов ты обрисовал. Если подобного уровня "проекты" в активы засчитывать, никакого резюме не хватит.
G>MS SQL рвет как тузик грелку на любых нетривиальных запросах, так что тут и соревноваться не зачем.
Кто кого рвет и на каких запросах? Соревновались тыщи раз до тебя — не рвет нифига на большом классе задач. Осообенно там, где для получения маленького объема данных надо перелопатить большой объем. Вы его просто готовить не умеете. А там, где действительно можно порвать MS SQL, там впору нейтивную числомолотилку вставлять, бо с числодроблением на дотнете из рук вон плохо.
G>Ты еще посмотри доля каких серверов растет. Ты удивишься, это nginx. Тупо потому что самый дешевый вариант для организации прокси. Для генерации контента он и не используется. Обычно им экранируют апач (который знатный трмоз если что).
Да плевать. Какое тебе дело, до сравнения долей всего остального вне ASP.Net? Ты что-то насчет "всех серверов на ASP.Net" утверждал? Утверждал. Глупость сморозил? Сморозил.
V>>но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность. G>Так у тебя вроде еще прототип или как понимать фразу выше?
Понимать так, что собеседник знает что говорит, бо экспериментировал именно со способами поднятия эффективности WPF-приложений. И вижу, что ты разводишь банальное ля-ля, делая далекоидущие выводы только лишь из того факта, что собеседник помимо всех прочих инструментов юзает С++. Если тебе удасться поднять быстродействие писанного мною для спора макета на оговоренные %, поверь, мне не жалко будет проиграть никаких денег. Бо оно того будет стоить.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Мощно и выразительно.
Угу, поэтому foreach по родному дотнетному массиву компилится в код, не использующий итераторы. Достаточно подать тот же массив туда, где ожидается IList<T>, и получаем полный приплызд. Мне удавалось поднять быстродействие более чем в 10 раз в дотнете просто заменяя везде АПИ на интерфейсах на АПИ на массивах. Причем, быстродействие требовалось именно для веб-аппликухи (поиск в семантическом облаке на основе AI).
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И на момент публикации (февраль 2010) обслуживали 90% трафика с помощью этого самого HipHop.
Реально HipHop — это на практике просто threaded interpreter. Среднее ускорение 2-3 раза всего по сравнению с чистой интерпретацией.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>А в чём? Интересно было бы узнать твоё мнение. AVK>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.
Дык, такие вещи ни от платформы, ни от языков не зависят.
ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования, где любые решения по-месту эффективности ради считаются чуть ли не хакерством. Как в том большом обсуждении задачки для собеседования про "бесконечную" очередь. В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже), но это порой требует лишнего ручного приседания в алгоритмах. И аргумент "надо, значит надо" для многих банально не подходит, т.к. большинство дотнет разработчиков не связаны с задачами, критичными к перформансу. Для них плохой перформанс — это, например, многократно открывать один и тот же файл, для последовательного чтения строк. Или организация доступа по порядковому номеру в связанных списках (встречал и такое).... Только дотнет тут не при чем, повторюсь. Это лень и безалаберность.
Здравствуйте, Геннадий Васильев, Вы писали:
V>>Т.е. сама необходимость обеспечивать рантайм рефлексию накладывает серьезные ограничения на трансформацию кода и данных в процессе компиляции. Не зря когда-то в рамках Singularity пришли к тому, что в их специализированном компиляторе поддерживается только compile-time рефлексия.
ГВ>Согласен. Хотя теоретически (в смысле — с непонятным практическим смыслом) можно держать две версии бинарников: оптимизированную для работы и неоптимизированную — специально для использования с рефлексией. Другое дело, что такой подход ещё больше нагрузит память. Да и время+ресурсы на JIT-компиляцию вырастут.
Если рефлексия нам нужна только для получения метаинформации, то без проблем, т.к. метаинформация после JIT никуда не денется, но если эта метаинформация используется для целей динамического доступа к полям, например, даже приватным, вот тут и наступает то ограничение, что конкретное поле оптимизатор не имеет права нивелировать/преобразовать/переместить. Причем, в поле может быть ссылка на другой объект, тоже видимый только локально, если брать классические public/private, и сценарии пользования которого или даже само наличие которого как отдельного объекта в куче могло быть оптимизатором пересмотрено... Но если через динамику/рефлексию "кто-то" может активно вмешиваться в процесс работы, то это вмешательство надо обеспечивать, согласно исходной метаинформации.
Здравствуйте, vdimas, Вы писали:
V>А в дотнете встанет проблема привязать имеющуюся метаинформацию к такой "другой" оптимизированной программе, что может создать сложности для доступа к объектам через рефлексию.
Такие проблемы уже есть и никого особо не пугают. К примеру, инлайнинг методов корежит стектрейс.
Кроме того, далеко не всегда оптимизации вообще должны портить рефлексию. Устранение виртуальных вызовов, использование общей реализации для шаблонов с разными аргументами, escape анализ в джаве.
А есть ведь еще вещи, с оптимизацией не связанные, но точно так же вносящие несоответствие кода рефлексии — лямбды, итераторы, анонимные типы, async и т.п. И это, вобщем то, тоже особо никого не пугает.
Так что значимость проблемы ты сильно преувеличиваешь.
V> Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.
Тем не менее современный CLR умеет и межсборочную оптимизацию делать. Например, инлайнинг методов из другой сборки. Слабо компилятору С++ заинлайнить метод из другой dll?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, kaa.python, Вы писали:
KP>А почему тогда приложения на плюсах работают быстрее?
Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, konsoletyper, Вы писали:
K>Вот уж не знаю, везде ли так, как у меня, или не везде. Но и скорость работы спеца нафиг никому не упёрлась. Я тут со своей эффективностью сижу и жду, когда же бизнес решит, чего он хочет.
Это всего лишь означает, что распределение задач ваш PM делает неэффективно. У меня, к примеру, почти всегда есть парочка параллельных задач разного приоритета (это специально так сделано). Если по одной пауза, занимаюсь второй. Кроме того, планов на будущее столько, что можно несколько лет что то писать. Так что если и бывают дни, когда получается относительная пауза, то это максимум 2-3 дня в год, и связано это, обычно, с выпуском очередного релиза.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, DarkGray, Вы писали:
DG>в managed есть лишь лишние проверки при доступе к массиву. DG>Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Да, это серьезная проблема. Сам МС с ней борется весьма просто — переходит на unsafe. Тем паче что в 4 версии шарпа добавили синтаксис взятия адреса n-ного элемента массива вместо явной адресной арифметики.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Легко! Наведенная ошибка — это практически любая неправильно обработанная ошибка или пропущенная где-то ранее ошибка. Самый очевидный пример — когда-то ранее null сохранили без проверки, а в момент использования получи ошибку. Вот тебе классическая наведенная ошибка, найти которую не поможет никакой стек-трейс, т.к. в момент возникновения ошибки ее предыстория неизвестна. Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. По-сути ты называешь главной причиной наведенных ошибок ту, которая составляет доли одного процента от всех причин для наведенных ошибок. Сие нелепо.
Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
V>Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
V>Откуда же такое внимание к ошибкам именно в нейтиве?
Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
2) Наличие коллстеков у всех исключений.
3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
Здравствуйте, mrTwister, Вы писали:
T>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
От найтив не найтив это мало зависит, например вполне аналог C++ — D от didgitalmars практически свободен от подобных ошибок.
Ну или другой пример OCaml или Хаскель тоже вполне найтивны, однако по ошибкоустойчивости дадут фору и шарпу и яве.
Здравствуйте, vdimas, Вы писали:
V>Ты сим постом сделал такое предположение о кач-ве дотнетных специалистов, что обсуждать сразу стало нечего.
А ты этим постом тоже кое что наглядно продемонстрировал.
Нет никакого такого качества дотнетных специалистов. Есть просто качество специалистов. И от того, что конкретного человека ты с шарпа на плюсы пересадишь, он умнее не станет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
S>>И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.
ГВ>Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++. А то, всё время получается:
ГВ>
- У дотнет есть некоторые недостатки...
ГВ>- А вы ошибки делаете, память теряете, ужас-ужас-ужас, уши отваливаются при стрельбе в ногу! Нет-нет-нет, мы обратно ни ногой!
А у тебя что, монопольное право тыкать в недостатки платформы ? Или дотнетчиками надо молча слушать твои плевки в сторону дотнета ?
ГВ>Ни ногой, так ни ногой, только зачем шуметь,
Так это С++ники бесятся, надавай им по шее, шоб не буянили.
Здравствуйте, DarkGray, Вы писали:
ГВ>>- В 1999-2009 акцент в индустрии смещался
DG>в моем понимании, как всё эти годы был акцент на том, что программист пишет на той фигне, на которой ему удобнее, а умный черный ящик обеспечит, чтобы это выполнялось быстро, так он и остался.
Об этом можно спорить, конечно, но демагогии вокруг того, насколько производительность программиста важнее производительности программы я тоже наслушался по самую макушку. Собственно, Саттер как раз это и отмечает.
DG>максимум, что поменялось за это время — это то, что из-за появления реальной многоплатформенности появилась тенденция генерить не сразу машкод, а сначала C++/C, java-у или .net, который уже потом транслируется в машкод.
Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов. Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ> Об этом можно спорить, конечно, но демагогии вокруг того, насколько производительность программиста важнее производительности программы я тоже наслушался по самую макушку.
на примере JavaScript-а и sql-я видно, что кроме вышеперечисленного, еще важна переносимость и дуракоустойчивость
ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов. Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
если уж из php умудряются генерить C++ код без gc (или все-таки у них там есть свой GC?), то уж из .net-а или java-ы тем более это можно сделать.
Здравствуйте, uncommon, Вы писали:
U>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии.
С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд.
U>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией.
И пофиг, зато быстро работает.
Здравствуйте, Klatu, Вы писали:
M>>>Про переполнение буфера забыли? C>>Это что, такое пугало для детей? K>Нет, для взрослых дядек, у которых внезапно оказывается что их сервер уже не совсем их.
Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью.
Хм. Написать что-ли статический проверяльщик, который ровно это делает?..
Здравствуйте, Mazay, Вы писали:
U>>>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии. C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд. M>Который надо было сделать 7 лет назад.
Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
K>>Да уж.. порой мне кажется, что для программиста это — насущная необходимость
V>Ну кому-то же надо и драйвера разрабатывать, и кодеки... Не всем же т.н. "программистам" сайты рисовать...
Больная тема?
А при чем тут драйверы с кодеками вообще?
Здравствуйте, vdimas, Вы писали:
V>Насчет всех этих упомянутых эксплоитов... Во первых, чтобы получить контроль над машиной, код должен выполняться с определенными правами, даже нативный.
Именно поэтому большинство современных експлойтов — про эскалацию привилегий. В основном — через те самые исключительно неуправляемые проблемы, типа переполнения буфера.
V>А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ?
Действительно. В таких задачах, как хорошо известно, рулит Эрланг — практически интерпретатор, полностью управляемый. Дотнет слишком низкоуровневый для таких задач.
V>Ну и справедливости ради, рядом положить PDB для нейтива, тоже всё увидеть можно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хм. А GC разве не занимается регулярными проверками состояния памяти?
Нет. То, чем занимается GC, трудно назвать "проверками состояния памяти". Если хочется покритиковать "затраты на GC", то давайте называть вещи своими именами, а не "постоянно сам себя проверяет".
Не буду вдаваться в детальный ликбез про поведение GC. Вкратце, поясню:
1. Затраты на GC зависят от количества живых объектов. Поэтому, если вы много работаете с короткоживущими объектами, то затраты на GC могут оказаться не выше, а то и ниже, чем альтернативные затраты на явное выделение/освобождение памяти в традиционных менеджерах памяти.
2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию
3. Для короткоживущих объектов с детерминированным lifetime, которые в неуправляемом мире принято размещать на стеке и экономить обращения к менеджеру памяти, в управляемых средах может применяться escape-анализ. В результате такие объекты не нагружают GC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
S>>2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию
ГВ>"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав?
Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.
1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает.
2) Чтобы не бегать по всей памяти существуют поколения, их 3. Размеры их растут экспоненциально, частота сборок уменьшается экспоненциально.
3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее.
4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.
Здравствуйте, gandjustas, Вы писали:
G>>>Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.
ГВ>>Я знаю, что полно, но ты сам что именно посоветуешь? G>http://www.rsdn.ru/article/dotnet/GC.xml
А... Ну это-то я как раз читал. Ну, всё равно спасибо.
G>>>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает. ГВ>>По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит. G>Ты еще не формализовал понятие "не хватает".
По умолчанию мы считаем, что рассматривается вся доступная процессу память.
G>>>3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее. ГВ>>OK. Про использование защищённых страниц я не знал (разве что краем уха слышал). G>Я читал о таком механизме как о возможной оптимизации поколений (ссылку к сожалению не найду), но подобный механизм точно существует иначе .NET был бы не быстрее ruby.
OK, поищу тогда сам. Правда, пока что ничего не нашёл.
G>Причем долгое время mono не имел generational GC и дико тормозил. Также generational gc отсутствует в xbox.
G>>>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#. ГВ>>И в чём выражаются такие нарушения? G>Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
А в чём тут отрицательное влияние выражается? В миграции ссылки на долгоживущий объект из памяти Gen2 в память Gen0?
Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>>А в чём тут отрицательное влияние выражается? В миграции ссылки на долгоживущий объект из памяти Gen2 в память Gen0? DG>основной ошибкой будет постоянное изменение ссылок из долгоживущих на короткоживущие. DG>это приведет к тому, что постоянно будет звенеть колокольчик, что произошло изменение страниц памяти с долгоживущими, и что их надо перепроверять при анализе для сборки мусора короткоживущих объектов. DG>соответственно, если объект просто используется из пула, то это даст ускорение, но если при этом в нем постоянно начинают меняться ссылки на другие объекты, хотя бы на строки, не говоря уже о других более сложные объектах, то может получится что такая оптимизация добавит больше работы gc, чем выиграет от повторного использования.
Выглядит хорошим аргументом в пользу функционального стиля с иммутабельными объектами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит. S>Это любые, где требуются явные операции освобождения памяти.
Продвинутые аллокаторы используют локальные для потоков арены, там блокировка не нужна.
Здравствуйте, Sinclair, Вы писали:
ГВ>>"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит. S>Это любые, где требуются явные операции освобождения памяти.
Операции освобождения памяти требуются не менеджерами памяти, а программой, которая эти менеджеры использует. Можно грохнуть весь менеджер, ни разу не выполняя промежуточный delete.
ГВ>>"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав? S>Да, неправ. Рекомендую углубленный RTFM на тему.
Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mazay, Вы писали:
M>Ага. Вот например std::copy на итераторах. Как там проверить, что в приёмнике места достаточно? Только если заменить итераторы на диапазоны и добавить рантаймовые проверки. То есть просадка производительности. Да и с диапазонами легко накосячить, поскольку они всё равно на итераторах, которые могут инвалидироваться.
Или сделать в диапазонах compile-time проверки, введя размер в аргумент шаблона.
Не уверен, что это прожуётся современными компиляторами С++.
И что есть достаточное количество таких задач, где размеры диапазонов заранее известны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Как тут поможет Timer? S>DateTime катастрофически неточен.
В данном случае это не имеет значения, т.к. длительность измеряемого интервала — 4.5-7.5 секунд.
ГВ>>Код под катом. S>Предлагаю следующее простое изменение:
C# for (int i = 0; i < ArrSize; ++i): 890,85096 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 1414,08088 ms
C# for (int i = 0; i < arr.Length; ++i): 1414,88092 ms
Press Enter to exit...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Пытливый ум при этом задаст ещё один вопрос: а что делать потом с фрагментированной свободной памятью? При этом граница эффективности как-то размывается... S>Совершенно верно. Фрагментация свободной памяти, которой подвержены классические менеджеры памяти — это ещё один аргумент в пользу GC.
Неправильно. Это аргумент в пользу отказа от классических менеджеров памяти. Ещё варианты есть?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Геннадий Васильев, Вы писали: ГВ>>Неправильно. Это аргумент в пользу отказа от классических менеджеров памяти. Ещё варианты есть? S>Хорошо, сформулируем по-другому: фрагментация свободной памяти возникает в ручном подходе к выделению памяти. И является, таким образом, аргументом для отказа от ручного распределения в пользу автоматического выделения памяти, т.е. GC.
Снова неправильно. Фрагментация возникает тогда, когда реализованная в программе политика управления жизненным циклом объектов подразумевает такую фрагментацию. Ещё варианты?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>Если объекты "тяжелые", то такой подход оправдан. Но сама операция выделения памяти в managed очень быстрая (по сути interlocked increment), затраты вносит сборка мусора которая зависит от количества живых объектов. Это значит что чем меньше остается живых перед сборкой мусора — тем лучше. S>>Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0: S>>
S>>Выделение памяти без синхронизации
S>>В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
G>Насколько я сылшал серверный GC позволяет параллелить в первую очередь сборку мусора, а не выделение памяти. interlocked increment и так довольно быстр чтобы еще и его пытаться оптимизировать.
Речь шла о выделении памяти. То что в многопроцессорном GC используется несколько арен поколения 0 — не я придумал. А раз используется несколько арен, то interlocked там и не нужен. Т.к. насколько бы он не был быстр, он значительно медленне простого инкремента.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> Первый раз я это услышал от спеца, принёсшего весть не то с конференции MS, не то с какой-то UG в 1997-м: что, мол, "сейчас главное — разрабатывать программы быстро, а то, что форма рисуется не за 200 микросекунд, а за 200 миллисекунд — так кому какая разница!" и тут же: "MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась).
Вот уж не знаю, везде ли так, как у меня, или не везде. Но и скорость работы спеца нафиг никому не упёрлась. Я тут со своей эффективностью сижу и жду, когда же бизнес решит, чего он хочет. От нечего делать попиваю чаёк и читаю RSDN. Так что мем зародился именно из-за безалаберности. При желании можно и эффективный код писать быстро. Я понимаю, были бы какие-то сложные алгоритмы, где надо полгода думать, как от вместо O(n*log(n)) перейти к полиномиальной сложности. А тут же формочки с БД! Написание эффективного кода в таких условиях превращается из сложной задачи в банальный навык, зашитый в спинном мозге.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет?
Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд. Сочетание параллельного GC и фонового немного смягчает этот эфект, растягивая сборку поэтапно по времени.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>... В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать.
Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
Здравствуйте, Sinclair, Вы писали:
S>Скажем, Outlook Web Access — одно из лучших веб-приложений, которые я когда-либо видел. Сделать такое на С++, имхо, просто нереально.
Нереально... Нереально прогнать бесконечный цикл за конечное время, остальное — вопрос технический.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
C>>Продвинутые аллокаторы используют локальные для потоков арены, там блокировка не нужна. S>Тем не менее, независимо от степени продвинутости аллокатора, при убийстве 100к объектов нужно 100к раз вызвать код возврата памяти в кучу.
Это считанные такты в нормальных реализациях. GC этого же колва объектов будет дороже.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции. G>Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
Нет, никаких метаданных не остается, у них обратная философия все что можно должно быть разрешено в момент
компиляции и оба выдают чистый машинный код, хотя OCaml может компилировать и в байт код своей виртуальной машины.
У OCaml'а код во многом даже более кошерный чем у C++, RTTI практически отсутствует.
G>При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
Здравствуйте, mrTwister, Вы писали:
ГВ>>ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. [...] T>К сожалению, в сложных проектах, которые делаются более чем одной командой, еще как начинает.
Сам начинает? А он как это делает, по вторникам, или по пятницам?
T>Тоже мне удивил. Именно про твою историю я писал следующее: T>
Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
Правильно. И я как раз не возражаю против этого.
ГВ>>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так. T>Каким образом он их замаскировал?
Да вот тем самым, когда вместо двух объектов оказывался один.
ГВ>>4) Ошибки в unmanaged-коде, действительно, неимоверно сложно искать... В особенности, когда их там нет и ты точно знаешь, что их там нет. T>То есть другими словами, работать с unmanaged кодом очень сложно, так как если ты при работе совершишь ошибку (начнешь использовать в несколько потоков, вместо одного), то вылавить эту ошибку будет очень трудно, так как получишь произвольную стрельбу по памяти. Причем в каком коде (managed или unmanaged) ты совершишь ошибку неправильного использования unmanaged кода, в любом случае тубу будет очень весело.
Нет, именно теми словами, которыми написано: трудно искать чёрную кошку в тёмной комнате, когда её нет.
ГВ>>В общем, факт остаётся фактом: если бы на хвосте managed не висел сквалыга-unmanaged, ошибку пришлось бы искать гораздо дольше, а то и вообще она проплыла бы мимо. T>С чего ты это взял? В твоем случае тебе повезло, что оно просто упало. А ведь могла вместо этого отвалиться совершенно левая функциональность, которая к данному коду вообще не имеет никакого отношения. А так радуйся, что пронесло в этот раз.
Некоторые детали мне пришлось опустить. А потом проезд по памяти с разносом всего, включая GC-хип бы бы благом, поскольку заставил бы обратить внимание на эту ошибку намного раньше. К слову сказать, AVE в какой-то момент был у меня единственным методом диагностики. AVE и непосредственно предшествующее ему состояние памяти.
ГВ>>Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг. T>Совершенно верно. При этом самые сложные для поиска баги — это баги, специфичные для С++, а именно проход по памяти, некорректная её интерпретация и пр.
Мантра. Даже обсуждать не хочу. Как раз из-за того, что не раз такие ошибки и делал, и лечил (не только у себя).
ГВ>>В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged. T>Легче из-а отсутствия наиболее противных багов и наличия нормальных исключений с callstack'ами и сообщениями.
Вот странное дело. Сколько пишу на этом кошмарном C++, а самые противные баги — из-за бестолковой спецификации. ЧЯДНТ?
ГВ>>У меня даже закралась крамольная мысль, [...] T>Контракты тебя спасут. В отличии от С++, в котором даже контракты не помогут, так как ничего не стоит эти контракты кому угодно разрушить без твоего ведома.
Ну, в упомянутом случае они спасти не могли, хотя бы в виду исторических причин. А то, знаешь, хорошо решать проблемы с помощью будущих инструментов.
T>>>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
ГВ>>Заблуждение. С неимоверной лёгкостью при concurrency-ошибках можно получить совместное владение одним объектом вместо двух, никто и слова худого не скажет. Один объект будет при этом ухлопан, а второй окажется в обоих потоках. И никакого шума, поскольку: а) для обновления ссылок синхронизация не требуется, б) клиент не управляет удалением объекта и там, где unmanaged непременно даст диагностику двойного удаления, managed — стоически промолчит.
T>Локализованы — это значит, что у тебя не сломается не связанная с этими объектами функциональность. [...] В частности, благодаря наличию метаданных твоя ошибка ищется очень просто: в windbg ты можешь сдампить все объекты интересующиего тебя типа, посмотреть их количество, и проверить все ссылки, кто на что ссылается. В частности, как только тестировщик видит, что приложение падает (из-за нарушения контракта), либо работает некорректно, то он делает дамп, отдает его тебе, ты видишь, что объектов два вместо одного, кричишь WTF, смотришь на код, который их создает и видишь, что этот код ломается в случае параллельного доступа. Все просто и скучно, никакого веселья и гадания на кофейной гуще, как в С++.
Хм. Я, вроде, понятно высказался: один объект вместо двух. Если они используются как read-only, ошибок попросту не будет. Вернее, они будут проявляться очень косвенно. Какая именно функциональность поломается — трудно предсказать в любом случае.
Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи.
ГВ>>Потом, например, параллельный доступ к тому же Dictionary может привести к весьма загадочным ситуациям (по этому поводу тут Klatu как-то возмущался). А поиски причин могут быть очень нетривиальными, в особенности, если этот Dictionary уедет ещё куда-то. T>Эти загадочные сидуации будут касаться только кода, связанного с этим Dictionary. Уши при этом у тебя не отвалятся. А в С++ возможно все.
В целом верно, но это, в сущности, не так уж плохо, поскольку заставляет внимательнее относиться к программированию.
T>>>2) Наличие коллстеков у всех исключений. ГВ>>Не надо преувеличивать: сам по себе коллстек показывает лишь на место возникновения сбоя, но ничего не говорит о той цепи причин, которые привели к его возникновению (кроме непосредственной). Об этом было говорено-переговорено лет семь-восемь назад. T>В 90% случаев этого достаточно. В С++ нет даже этого. Ты просто знаешь, что что-то где-то сломалось. Что и где — неизвестно. Если не удалось поймать дамп в момент падения, то начинается веселье.
Чушь. В C++, в случае выбрасывания исключения я знаю о происходящем ровно столько же, сколько и в C#: что в точке файл... строка... вылетело исключение. Информация о стеке... Ну как, может быть полезна с некоторой вероятностью, но не более того. А о действительных причинах в этот момент я всё равно могу только догадываться.
T>>>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы. ГВ>>Ещё раз повторяю для дотнетчиков: ошибки типобезопасности вычисляются и лечатся на раз. [...] T>Ситуация из недавней практики: поскольку проект очень большой, то его части собираются в разное время (чтобы оптимизировать время сборки). Однажды произошла такая ситуация, когда версия хедеров перестала соответствовать бинарям (забыли пересобрать). И продукт при этом работал практически всегда, но иногда в очень редких кейзах начинал течь. Сил угрохали на поиск в коде бага море. А в .NET такое невозможно в принципе.
И о чём это говорит? Да ни о чём. Собирать модули надо с соблюдением процедуры, больше ничего.
ГВ>>Так что, всё, что ты перечислил — оно, конечно, правильно, но практика — вещь такая... T>Все, что я перечислял касается именно практики по интеграции большого количества unmanaged кода, написанного разными командами с большим количеством managed кода.
Как видишь, у каждого свои выводы из практики.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Banned by IT, Вы писали:
G>>в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью. BBI>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
Средний C# не знает и не умеет указателей. Как то так выходит, что заказчики предлагают проектов примерно на порядок больше, чем могут реализовать умелые сиплюсники, так что unmanaged это вынужденая мера.
C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.
Здравствуйте, Klatu, Вы писали:
V>>>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. K>>>ну это просто вранье или полная некомпетентность ГВ>>Слушай, найди какой-нибудь другой аргумент, а? K>Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил [...]
На этом варианты закончились? Только глобальное/статическое?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Banned by IT, Вы писали: BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру? S>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои. Голые указатели, если верить форумам, вообще никто уже десять лет не применяет.
Пользовал и пользую; писал и пишу; применяю, где имеет смысл и не применяю, где не имеет смысла.
S>И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.
Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++. А то, всё время получается:
- У дотнет есть некоторые недостатки...
— А вы ошибки делаете, память теряете, ужас-ужас-ужас, уши отваливаются при стрельбе в ногу! Нет-нет-нет, мы обратно ни ногой!
Ни ногой, так ни ногой, только зачем шуметь, если кто-то констатирует объективные недостатки того же дотнета, не зависящие от программистов? А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. А если их нет, этих преимуществ по каким-то критериям?
S>Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.
Во-во, оно и есть.
S>Добро пожаловать в реальный мир, Нео.
Угу, загляни в топикстарт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Ikemefula, Вы писали:
I>>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
ГВ>А можно узнать возрастные характеристики этого среднего программиста?
Рекомендую сналчала поинтересоваться об источнике этой информации
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, mrTwister, Вы писали:
T>>Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ!
V>Ну ты не приводи слова без указания контекста, або даже я упомяну неприятное слово "демагогия".
T>>Куча тактов процессора и байтов памяти зазря тратятся.
V>-1 V>Достаточно самому написать програму из 3-х строк, с использованием std::auto_ptr, и убедиться на сгенеренном бинарном коде, что использование этого умного указателя ничего не стоит, в сравнении с ручным вариантом, безопасным к исключениям.
Тоже мне, умный указатель нашел std::auto_ptr
Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно! На каждую аллокацию для объекта получаем еще одну аллокацию для счетчика. В результате нагрузка на и так тормозной менеджер памяти увеличивается в два раза. А какой размер такого счетчика ссылок? 4 байта? Только для этих 4 байтов в стандартной виндосовой куче будет выделено 16. И спрашивается, на кой черт это надо, не проще ли сразу .NET использовать, а на С++ писать только куски, на которые и умного указателя жалко?
Здравствуйте, mrTwister, Вы писали:
T>Тоже мне, умный указатель нашел std::auto_ptr
Самый что ни на есть умный, автоматизирующий реализацию технологии RAII.
T>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно!
Есть так же intrusive хранение счетчика. Аналогично, как intrusive linked list всяко получше такого linked list, где целевые объекты дополнительно по ссылке из узлов хранятся, как в дотнете. В общем, поинт номер один в том, что оптимизировать всё подряд вовсе не надо, но если надо... то поинт номер два в том, что С++ дает всяко больше таких возможностей относительно дешево (из-за повторяемости решений через шаблоны и отсутствия ограничений value/ref типов), причем, абсолютно в типобезопасном виде, вовсе не надо жонглировать никакими битами и напрасной реинтепретацией памяти. Хотя, самые эффективные биржевые протоколы как раз описаны в терминах С (напр. NASDAQ OMX) и полностью сидят на реинтепретации памяти, экономя на десериализации байт, т.е. входящие пакеты можно просто приводить к некому типу данных, согласно фиксированного заголовка. Там, где время отклика должно составлять единицы микросекунд (десятки наносекунд на каждый элемент внутри сообщения, с учетом всей прикладной логики), это оправдано. Но ключевое опять же в том, что это С-АПИ, а не С++. Для С++ пишут типизированные и безопасные обертки над этим С-АПИ, которые, что характерно, ничего не стоят в рантайм.
Возвращаясь к бедному shred_ptr. Его можно использовать как первое приближение при реализации прототипа. Потом, когда собственная программа станет самому более понятна, и будут обкатаны все сценарии, будет хорошо видно в конечном наборе сущностей, кто кем и когда владеет, и в большей части кода shared_ptr может уйти совсем (как раз недавно занимался увеличением эффективности одного продукта, заменяя shared_ptr в т.ч.), или когда его можно переделать на intrusive, если уж критично в этом месте к быстродействию, но налицо именно совместное владение объектом из разных потоков с недетерминированным временем жизни самих этих потоков.
Если проводить аналогии с дотнетом, то shared_ptr хорош там, где объекты создаются относительно редко, и потом долго используются, т.е. те, которые в дотнете пойдут во 2-е поколение. А то, что в дотнете не переживает первой сборки, обычно в программе на С++ не требует памяти из кучи вообще, т.е. не требует никаких shared_ptr ввиду отсутствия ограничений на место расположения объектов. Т.е. можно на стеке создать временный объект, либо другой экземпляр того же типа на куче, если этот экземпляр будет долгоживущий. Есть выбор, вот что удобно.
Объекты С++ собираются на подобных шаблонных хелперах как из кубиков LEGO, оставляя пространство разработчику для выбора кучи стратегий, прописывая текущие зависимости через typedef, давая возможность кардинально все менять, не трогая зависимый код. В C# иногда просто ломка, когда приходится разрабатывать что-то за рамками использования стандартной библиотеки, бо ручного труда навскидку в 2-3 раза больше. Из-за ограничений технологии генериков в т.ч. Хорошо понимаю немерлистов, когда они описывают похожий эффект.
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, gandjustas, Вы писали:
G>>>>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1. BBI>>>Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный. G>>Микротесты на массивах чтоли? А толку от них? BBI>если jit профейлил на простых микротестах то думаешь в более сложной ситуации он поведёт себя лучше?
Микротесты ничего не доказывают так как по их результатам нельзя судить о более сложном коде.
Здравствуйте, vdimas, Вы писали:
T>>А кто тебя заставляет это делать? V>Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы.
Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.
V>Дык, это не тот класс ошибок, который действительно напрягает.
Ну это кого как. Меня уже достало искать подобные ошибки в С++ коде.
T>>Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие!
V>Если не пользовать механизмы исключений как способ организации логики программы, то до фени быстродействие абсолютно, если уж произошла исключительная ситуация.
Это отдельная флеймовая тема: и что такое исключительная ситуация, и как отличить исключительную ситуацию от неисключительной и про то, что исключительная ситуация с точки зрения одного кода может быть неисключительной с точки зрения другого, и, наконец, про то, что по мнению многих плюсовиков коды возврата — это прошлый век и тонны ифов.
Но в любом случае ваше решение очень ограниченно по следующим причинам:
1) Надо распространять pdb
2) Надо модифицировать код, бросающий исключения, а это не всегда возможно.
3) Можно получить очень сильную просадку производительности на ровном месте.
T>>А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?
V>На этапе беты — да, а что? V>В клинических случаях даже для релизных продуктов шлем клиентам PDB, просим положить рядом и воспроизвести.
А в чем смысл? Если уж клиент согласен и в состоянии воспроизвести (что далеко не всегда так), то почему бы тогда полный дамп не сгенерировать?
V>>>Помогает только для примитивных ошибок, и доступно для С++ тоже. T>>Примитивных ошибок большинство и суммарное время, потраченное на их исправление довольно большое.
V>Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки".
Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов. Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!
V>И я опять утверждаю, что дотнетные программы чаще плюют баги у клиентов, чем плюсовые, по итогам наблюдений за 8 лет.
Я этого почему-то не наблюдаю.
V>И как общую картину исправит тот факт, что на стороне разработчика этот баг потом проще найти?
Повлияет тем, что можно набрать больше тестировщиков благодаря тому, что программисты быстрее исправляют ошибки. В результате больше ошибок будет найдено и исправлено во время тестирования. У нас, например, тестировщиков больше, чем программистов. Если бы не С++ код, то пропорцию можно было бы еще увеличить.
V>Не принципиально абсолютно. Да и не помню я, чтобы сложные в поиске баги, т.е. занявшие хотя бы пол-дня на поиски, выскакивали чаще, чем раз в несколько лет.
Да, кстати. Мы тут недавно Critical Fix выпускали. Buffer overrun в одном из umanaged компонентов. Но, как мне тут объяснили, таких ошибок в реальной жизни не бывает. Значит мне это все приснилось
T>>Совсем необязательно что-то там хачить. Достаточно воспользоваться указателем на удаленный блок памяти. V>Тю, блин, а я то думал... Для этого надо следить за ресурсами в стиле голого С. Начинаем шарманку сначала, или остановимся?
Совсем не обязательно. Достаточно сделать грамотную и продуманную политику управления времени жизни объектов и в соответствии с этой политикой для обеспечения энергоэффективности передать куда-нибудь объект по константной ссылке (одетый С++, между прочим). Там эту константную ссылку бережно сохранят и нагадят в нее потом.
Или, например, удалить популярный в этом топике кастомный аллокатор (вместе с кучей) до того, как забыты все ссылки на объекты из этой кучи.
Здравствуйте, samius, Вы писали:
S>Отлично, но ведь такую точку входа не подружить с
Подружить запросто. Перегрузки ф-ий отличаются, будет выбрана более специализированная версия. Перегружается же как-то operator<< для всевозможных типов.
Например, у меня стоит такая ловушка для самого общего случая:
// A trap for unknown types to help in operator<< overriding diagnosticstemplate<typename UNKNOWN_TYPE>
TextBuilder& operator<<(const UNKNOWN_TYPE & value) {
struct can_not_format_unknown_type {};
//
// Note: you must define an external operator<< like:
// TextBuilder& operator<<(TextBuilder& f, const YourConcreteType& value)
// or TextBuilder& operator<<(TextBuilder& f, YourConcreteType value)
// defined in ****::**** namespace or in YourConcreteType declaration namespace
//
can_not_format_unknown_type error = value;
}
Которая генерит следующую ошибку при отсутствии специализации:
cannot convert from 'const SomeType' to '****::****::TextBuilder::<<::can_not_format_unknown_type'
Для аналогичного показанному в пред.посте случаю есть специализация:
S>Я прикопался не к типобезопасности, а именно к передаче размера массива темплейт параметром. Если такой метод используется часто с массивами различной длины, то будет взрыв размера бинариев, как я понимаю.
Да, в первых компиляторах С++ происходил именно взрыв размера бинарника. А потом оптимизатор link-time научился "склеивать" одинаковые куски кода. Что характерно, эта техника работает даже для нешаблонных и даже для виртуальных ф-ий, например:
class SomeIntBox
{
int i;
public:
virtual int getI() { return i; }
};
class SomeFloatBox : public ISomeContract<float>
{
float f;
public:
virtual float getF() { return f; }
};
Признаюсь, я был сильно в 2002-м году удивлен, когда в релизном коде обнаружил, что getI и getF имеют один и тот же адрес, т.е. вместо двух ф-ий в бинарнике осталась только одна.
Для случая doSomething наиболее вероятным будет несколько сгенеренных точек входа (настоящих точек входа, без call и дополнительного фрейма стека, а просто jump потом на общее тело) с инициализацией какого-нить регистра или push в стек разных значений. Достоверно обещать не могу, это уж как оптимизатор выкрутится для конкретного кода, но использование нескольких легковесных точек входа, без создания лишних фреймов, наблюдаю постоянно. Особенно это неплохо смотрится если помнить, что в современных процах (со времен 2-го пня) безусловный jump занимает ровно 0 тактов.
Здравствуйте, gandjustas, Вы писали:
ГВ>>Ясное дело, в managed с этим намного лучше: ссылку на объект, к которому моя функция будет обращаться, уже давно обнулили, но специально ради моей функции держат в памяти уже забытую всеми остальными копию. Благодарствую за любезность! G>Именно. Это позволяет делать unmanaged. G>Есть еще более коварный вид ошибок. Когда ты сам держишь ссылку, а кто-то другой объект удаляет, считая его ненужным.
Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
ГВ>>>>1) Нельзя вестись на поводу у дурацких стереотипов, что в AVE всегда виноват unmanaged. G>>>Ок, докажи обратное. Когда чисто managed код вызывает AVE. ГВ>>Что — обратное? G>Дальше написано. Пример когда чисто managed код вызывает ave.
Речь идёт о связке unmanaged + managed. И у меня там всё расписано: я не отрицаю того, что исключение бросит именно unmanaged. Важно, почему он это сделает.
ГВ>>>>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так. G>>>То есть managed код работал, а unmanaged таки падал? Ведь именно unmanaged не был спроектирован под cuncurrency. ГВ>>Умничка. Именно дотнетный код — работал. Ну, по вашему же, если эксцепшенов нет, значит код — работает! Возьми с полки пирожок. Ты, кстати, не у конкурентов, часом работаешь? Надо посоветовать, чтобы тебе зарплату подняли. Скажи, эдипов папа посоветовал. G>Не уходит от вопроса. Ты не написал что были какие проблемы непосредственно в managed, ты сказал что он не так вызывал unmanaged, но сам unmanaged этому никак не противился.
Да банальные проблемы — несколько потоков лезли одновременно к одному и тому же объекту без синхронизации.
G>То есть переписал unmanaged так чтобы не было этих проблема можно было вообще исключить эту проблему.
Там было написано: соответствующая проверка была убрана ради оптимизации.
ГВ>>>>3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше; G>>>Без unmanaged скорее всего косяк был бы найден раньше ибо в managed из unmanaged не попадет сведений о threading model вызываемого кода. ГВ>>Без unmanaged ошибка не была бы найдена вообще. Но она от этого никуда бы не делась G>А в чем тогда ошибка? И почему она не была бы найдена? Или ты что-то не договариваешь ил просто пытаешься свалить вину.
Скажем так: unmanaged создавал некий объект, который передавался в managed, читал он его из некоей большой-пребольшой базы данных (действительно большой, но это к делу не относится). Один вызов unmanaged — один новый объект. В дальнейшем эти объекты с данными поочерёдно помещались в поле объекта-получателя и юзались как read-only (до следующей транзакции). Грубо где-то так:
public class SomeDataProcessing {
// Текущая порция данных
SomeData portion;
// Чтение данных обращением к unmanagedpublic void readDataPortion() {
portion = callUnmanagedCode();
}
// Цикл обработки. Работает в отдельном потоке.public void processData() {
while(...) {
readDataPortion();
// Обработка того, что положили в portion:int a = portion.prop1;
int b = portion.prop2;
// ...
}
}
}
То есть вызывающему коду было без разницы, в скольки потоках работать — данные он не модифицирует, только читает. И если чтение вдруг происходит в два потока, то один из полученных объектов пропадает (portion-то у нас одно, правильно?), и оба обратившихся потока будут пользоваться ссылкой на один объект данных. Но никаких конфликтов в managed-коде эта ситуация не вызовет. Разве что когда-то потом могло быть отслежено нарушение целостности данных... Но это же ещё надо сначала это нарушение обнаружить, а для этого нужно создать специфичные условия, чтобы два потока создались вместо одного, а в тестовых условиях всё тихо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом. S>А можно поподробнее мне объяснить, за счёт чего произойдёт этот "ой"?
При порче заголовков блоков памяти, выделяемых хипом, выбрасывается исключение. Не в момент порчи, а в момент нормального освобождения этой памяти.
Хотя да, в случае всего одной маленькой переменной не факт, что ты попортишь именно заколовок хипа, а не тело другого объекта. Я тут уже высказывался, что всякого рода шумовые эфекты — это гут, потому что ошибка себя проявляет.
Здравствуйте, gandjustas, Вы писали:
ГВ>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
G>Да, и managed программа будет работать и работать корректно.
Разницу между "корректно" и "без выбрасывания исключений" надо объяснять?
G>В unmanaged в лучшем случае упадет. Разницу понимаешь?
Естественно, понимаю.
[...]
G>Тут получается что просто не договорились между managed и unmanaged о tread safety.
Вот, живой пример вреда code samples: собеседник начинает делать далеко идущие выводы из ничего. Код сугубо иллюстративный и показывает только то место, где возникала потеря объекта данных. В реальности и сам код был сложней, и ещё довольно сложная логика перезапуска потоков, из-за которой, в общем, всё и случилось. Но к тому, на что я хотел обратить внимание, это не относится. А про однопоточность unmanaged всем и так было известно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.
Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно". Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь". В случае managed-кода всё это было аккуратно и тихо проглочено либо "гарантирующей" средой, либо GC.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
ГВ>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности. G>Ну ты же начал про managed-unmanaged, а привел говнокод, который на любом языке мог бы так работать.
Не на любом. Только на языке, который гарантирует контроль памяти и атомарность обновления ссылок. Собственно, такого же эффекта можно добиться на обычных смарт-пойнтерах.
ГВ>>"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило. G>А это еще один интересный вопрос. Видимо помимо проблем в managed были еще и в unmanaged проблемы, которые приводили к ave. Тоже что-то вроде разделяемых данных без синхронизации.
Кхм. По-моему, я несколько раз говорил, что код принципиально строился, как однопоточный. То есть я понимаю, что для тебя выражение "соглашение об использовании" — пустой звук в сравнении с гайдлайнами от MS, но не надо всех по себе равнять, это контрпродуктивно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?
При оперировании состояниями в небезопасном к исключению коде это еще оптимистично, бо негативных сценариев всегда больше позитивных. Я бы сформулировал так: на каждый позитивный сценарий есть целая куча негативных.
G>Ты уже перешел в демагогию. Вместо описания каких-то проблем ты пишешь общие слова, которые все по разному понимают. G>Давай пиши конкретнее что ты имеешь ввиду.
Это общеупотребительные термины и мемы.
G>ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.
Ну, ок, по серверам я говорил, что это ниша дотнета, по многим пунктам. И даже особенности работы GC как раз хорошо ложатся на массовое обслуживание. Касательно подробностей модели, в 99% случаев веба там stateless, т.е. состояние просто умирает в этом сценарии, а не переходит в невалидное. К тому же сценарий обработки ошибки ровно один — передать текст ошибки клиенту. Ну и транзакционность и независимость подключений/запросов обеспечивается протоколом и низлежащей инфраструкторой, к которой к тебе торчит "конец", дергаемый в нужное время, не тобой определыемое. И вот во всей этой массе серьезных технологий вы делаете прикладную верхушку айсберга.
Здравствуйте, gandjustas, Вы писали:
G>Как обычно за "общеупотребительными терминами" у каждого свое понимание. Дай ссылку на какие-нить источники, хоть википедию чтоли.
Еще посмотри популярный "read copy update". Дополнительно к блокировке писателей в этой модели удобно применить lock-free парадигму для любых многопоточных обновлений любых объектов, представляющих из себя состояние (не везде сказан про этот неплохой сценарий, приведу почти рабочий псевдокод):
Resource target; // целевой ресурс для обновления, лежит где-то мембером или статиком.
...
Resource resCurrent = target; // запоминаем локально ссылку на текущий экземплярdo {
Resource res = resCurrent; // промежуточная переменная для оптимизации сценария CompareExchange
Resource resNew = MakeCopyOfSomeDeep(res); // здесь будет 1% всех исключений
Update(resNew, data); // обновляем локальную копию, здесь будет 99% всех исключений
// атомарно обновляем ссылку на данные, если до этого все прошло успешно
} while((currentTarget = Interlocked.CompareExchange(ref target, resNew, res)) != res);
G>Не спорю. Но ты на вопрос ответь. Ты предлагаешь тестировать негативные сценарии, которые по сути не нужны пользователю. Зачем это делать? G>Ага, но если в десктопе писать большую часть приложения в таком же stateless стиле, то получается не хуже чем в вебе.
Не выйдет, ты же не только с данными работаешь, а со всем окружением вокруг программы, от которого изолирован в вебе. Если в вебе в случае ошибки ты отправил ее текс клиенту и "вышел", то в десктопе некуда выходить. Практически в КАЖДОМ сценарии тебе надо максимально адекватно обыграть любую ошибку. Без состояний на клиенте не обойтись. Напр, для твоего веба состоянием клиентской программы распоряжается браузер, + частично куки (хотя и тут гонки), и если для веба "нормально" показать ошибку и потерять нафик все результаты, например сообщение, которое тщательно 15 мин писал в этот форум прямо в браузере, то в обычной десктопной программе такое не прощается.
А что я вижу порой и что имею ввиду? Такие лихие зацикливания в попытках "правильно" обработать ошибки в клиентских программах... В половине случаев в цикле начинают мне показывать сообщения об ошибке, избавиться от этого никак, только снять процесс. Помнится, первые версии решарпера это нам тоже демонстрировали во всей красе. Непервые ночные билды тоже. Это тебе дотнетная прога из первых рук. Или, например, программа работала нормально, но после первой же странной ошибки, стала показывать сообщения об ошибке на каждое действие. Я такого в нейтивных программах не помню оч. давно.
G>Стейт как всегда присутствует в двух местах: интерфейс и хранилище данных. Первый нормально изолируется с помощью паттернов mv*, второй с помощью грамотно проработанных интерфейсов.
Ес-но, только у тебя "хранилище данных" — это и есть состояние твоей десктопной программы. С миллионном флагов и просто значений. И если ты сумеешь организовать транзакционность, т.е. чтобы обновление, скажем сотни полей, прошли либо все успешно, либо никто не прошел, то всё будет ок. Прямо как буд-то работаешь с транзакционной БД. О чем и речь. Просто в С++, ввиду того, что иногда приходится вручную следить, кто кем владеет и когда, безопасная схема слежения за ресурсами может быть только транзакционной или никакой. Устойчивость прикладной логики в этом случае — приятный бонус.
G>Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее. А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.
Ну, если ты только клиента для БД пишешь, то у тебя тоже, большая часть сценариев сводится к staless, а транзакционность за тебя БД умеет.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Геннадий Васильев, Вы писали:
G>>>Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?
ГВ>>По-видимому, я всё-таки невнятно это как-то обозначил: приведённый код принципиально однопоточный. Многопоточным он "становился" только из-за ошибки в управлении потоками.
V>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.
довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные
Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
V>>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения. G>>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные
ГВ>И ты, естественно, предположил, что обозначенный код выполнен однопоточным только из-за такого "неумения"? Силён, бродяга, ничего не скажешь.
Да, я уверен в этом. Ты же сам говорил что код "читает из большой базы данных", но все известные мне движки СУБД отлично работают с несколькими соединениями из разных потоков. Потом привел код, который использует состояние объекта для передачи данных внтури метода, что тоже является признаком неумения.
ГВ>Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации.
Ага, то есть саначла написали локи, потом оно начала дико тормозить, потом локи убрали возложив отвественность за синхронизацию на вызывающий код. А вызывающий код был написан вообще без мыслей о многопоточности, а потом она внезапно появилась. Причем как ты сам пишешь что race появился по ошибке.
В итоге одна ошибка на другой.
G>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики. ГВ>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.
Здравствуйте, c-smile, Вы писали:
G>>Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.
CS>Тут одно утверждение и одно предположение. Оба неверные. Толпы в EverNote никогда не было это точно.
CS>По поводу WPF и .NET UI вообще.
CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
что это за десяток things?
CS>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл. CS>Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.
CS>Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.
я не знаю что такое абстрактный HTML DOM, он везде свой, конкретный. как можно сравнивать WPF OO и абстрактную OO HTML DOM мне не ясно.
Здравствуйте, gandjustas, Вы писали:
V>>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.
G>Еще как в состоянии. Достаточно сделать данные immutable.
Не достаточно, коль нам от кода нужно именно поведение, зависящее от состояния. Обеспечение такой семантики через выделение памяти под каждое новое immutable состояние уж тем более не приемлимо, раз неприемлимы были такие мелочи, как примитивы синхронизации.
V>>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь? G>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.
А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей?
Какие ты еще знаешь способы реализации архитектур СМО, интересно?
V>>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового. G>Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.
Описание факта не может являться демагогией, в отличие от навешивания ярлыков, которое ты демонстрируешь. Сухое такое описание банальной ситуации. Подставить туда managed-реализацию вместо unmanaged — ошибка себя в этом месте не проявляет, но она есть, и периодически неуловимо портит важные бизнес-данные. Вот и все, что было сказано.
G>По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан.
Т.е. баги бывают исключительно в плохом коде, что ле?.. договорились... И у тебя за всю жизнь не бывает багов в процессе разработки? А тестеров ваших вы зачем кормите? А юнит тесты (я уверен) нафига исопльзуете? Ведь достаточно же писать "хороший код", это сам по гарант надежности программ...
В общем ладно, через бездну подобных заблуждений я всё-равно никогда не продерусь. Очевидные ответы можно лепить бесконечно, жаль что бестолку. Тут или предвзятось или что похуже даже, чем отсутствие воображения.
V>>Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение. G>Это отличный сценарий, особенно если учесть еще два фактора: распределенность и client state. Такая архитектура на десктопе в принципе не встречается.
G>С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает
у тех ли? Вот прога обрабатывает десятки тыщ сообщений в сек, должна принимать бизнес-решения за единицы микросекунд, ты предлагаешь такую задачу делать распределенно? А люди, ставящие хосты с многими десятками ядер наверно дураки поголовно? Ведь можно же "распределенно"?
Здравствуйте, hattab, Вы писали:
H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
показываем HTML + js — опа, и у нас уже Apache ненативный
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.
G>>Еще как в состоянии. Достаточно сделать данные immutable.
V>Не достаточно, коль нам от кода нужно именно поведение, зависящее от состояния.
Тогда надо изолировать. Исключать подобные ошибки. В более менее сложном объем кода UI сильно меньше остальной логики, а state нужен только ему, для stateless-логики передаются параметры и никто снаружи их не поменяет просто так.
V>Обеспечение такой семантики через выделение памяти под каждое новое immutable состояние уж тем более не приемлимо, раз неприемлимы были такие мелочи, как примитивы синхронизации.
Ну это в unmanaged так, а в .NET как раз правильное использование immutable позволяет увеличить быстродействие слегка увеличив расход памяти, а также сделать код многопоточным.
V>>>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь? G>>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.
V>А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей?
Может и там был, ведь пример не я придумал, а ГВ, а он как раз рассказал и показал все, кроме того места где собственно была ошибка.
V>Какие ты еще знаешь способы реализации архитектур СМО, интересно?
Что такое СМО?
V>>>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового. G>>Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.
V>Описание факта не может являться демагогией, в отличие от навешивания ярлыков, которое ты демонстрируешь. Сухое такое описание банальной ситуации. Подставить туда managed-реализацию вместо unmanaged — ошибка себя в этом месте не проявляет, но она есть, и периодически неуловимо портит важные бизнес-данные. Вот и все, что было сказано.
См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.
G>>По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан. V>Т.е. баги бывают исключительно в плохом коде, что ле?.. договорились... И у тебя за всю жизнь не бывает багов в процессе разработки? А тестеров ваших вы зачем кормите? А юнит тесты (я уверен) нафига исопльзуете? Ведь достаточно же писать "хороший код", это сам по гарант надежности программ...
Нет, баги еще бывают когда неправильно поняли что нужно сделать на каком либо этапе передачи данных от заказчика программисту. Но их тут мы не рассматриваем.
G>>С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает V>у тех ли? Вот прога обрабатывает десятки тыщ сообщений в сек, должна принимать бизнес-решения за единицы микросекунд, ты предлагаешь такую задачу делать распределенно? А люди, ставящие хосты с многими десятками ядер наверно дураки поголовно? Ведь можно же "распределенно"?
Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.
Здравствуйте, Banned by IT, Вы писали:
ГВ>>Вон, как здесь уже договорились до того, что аллокатор=гуру, скоро до указателей дойдёте. BBI>Этот момент нереально повеселил. Шарпист добровольно по сути признал меня гуру, цирк на конной тяге!!!
Гуру это не тот кто знает всё, это тот кто знат намного больше средней массы и встречается в силу этого сильно редко. Ты просто не понял иронии. Бывает.
Здравствуйте, hattab, Вы писали:
H>Доки никто нативными не называет. Но доки могу содержать скрипты на Тьюринг-полном языке, а Ворд умеет их выполнять. Так Ворд нативный или нет?
Я уже дал ответ — зависит от реализации самого ворда, а не того, что ворд умеет или не умеет выполнять.
I>> Я определяею нативность в зависимости от реализации непосредственной функциональности софта. Если это нативный с++ , то прилага нативная. Если это нативный с++ вперемешку с js, vb или lua — это смешаное. Если же только js, то очевидно это вообще не нативное приложение.
H>Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется.
Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).
Если сервер БД свой непосредтсвенный функционал реализует в т.ч. на скриптах, то это смешаное приложение. Например если в консольном олдскульном WINAPI приложении на языке с напишу примерно следуеющее
ТО очевидно приложение сразу становится смешаным, т.к. использует джаваскрипт для реализации своего функционала.
И так же очевидно, что интерпретатор джаваскрипта писаный на чистом нативном С является нативным приложение хотя и умеет выполнять джаваскрипт. Зато если написать на этом скрипте приложение да пускать его через этот интерпретатор, приложение будет управляемым.
Так понятно ?
I>> Реализации непосредственной функциональности ворда никак не зависит от документов, которые ты открываешь в ворде. Вот если движок для скриптов, работы с доками и тд полностью нативный, значит ворд нативная софтина. Если там есть скрипты — значит смешаная.
H>Непосредственная функциональность Ворда заключается в том числе и в корректной интерпретации документов имеющих скрипты.
Интерпретатор может быть и нативным, представь себе весь ужас.
>С игрушками точно также. Что такое игрушка? Грубо говоря, это движок способный корректно интерпретировать данные уровня и его скрипты.
Вот раз "и его скрипты", то следовательно приложение смешаное.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, c-smile, Вы писали:
CS>>Каждый DOM элемент в WPF это Common Language Runtime object instance. CS>>Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д. CS>>Десятки GCable things и набегают. MM>Дык, не получается. Я приводил тест. Создано было более 5000 контролов, в каждом из которых визуальное дерево образуют еще 5-10 вложенных. GC потратил на себя ничтожное время. Да, загрузка медленная, но не из-за GC.
Проблема не в самом GC как процессе сборки мусора. А скорее в самой архитекуре managed объектов обусловленных нуждами этого GC. Там где в native code я могу например выделить память под контейнер одним куском
struct items {
...
int _n_items;
T _items[0];
}
и получу оптимальную структуру с точки зрения data caching в процессоре и пр.
В managed средах ты просто вынужден писать нечто типа
class items {
...
int _n_items;
T[] _items;
}
увеличивая (в два раза) indirection levels.
Короче — за все приходится платить — manageabilty не дешевое удовольствие.
CS>>Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser. CS>>Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий. CS>>Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале. MM>Пример с Evernote скоро станет, как Fire And Motion. Конечно, WPF сольет native. Тут без вариантов. Отсутствие интеропа, наличие огромного числа наработок для native кода. Evernote делали для .Net 3.5. Сейчас в WPF шрифты не плывут, известны разные ходы для увеличения пефоманса. И я бы хотел поглядеть на код, тогда смогу сказать, что Evernote-вцы выжали из WPF всё, что смогли. Недавно я установил их клиент: не сказать, что там мега-богатый UI. Не вижу причин, почему на нем WPF должно быть медленнее (исключая запуск .Net).
На самом деле UI сам по себе это вершина айсберга. Вот скажем представление предметной области — доступ к базе данных.
В native code я например могу спроецировать DB на память — т.е. получение access к данным это тривиальный pointer на память. Быстро и дешево (по памяти).
В случае с managed — пляски с бубном и GC cycles как результат. В native code свободы для оптимальных решений на порядки больше. Вот и результат.
именно эти частности — и дают отличие native от managed.
если в скрипте есть проверка на выход за границы — это уже managed, если есть gc — то тем более.
дальше этот managed быть тотальным (все операции проверяются), или не тотальным (проверяется только часть операций, и есть операции которые позволяют выйти за пределы массива и выделить память в обход gc)
Здравствуйте, gandjustas, Вы писали:
G>В вебе время отклика важно всегда, далеко не всегда это микросекунды, но объем обрабатываемых данных огромный и одна машина не всегда справляется с нагрузкой.
Микросекунды и "далеко не всегда это микросекунды" — это уже качественное различие между ПО. Я серьёзно: то, что вполне укладывается в "не микросекунды" абсолютно не допустимо там, где речь заходит о микросекундах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
FR>Кстати и питон нативный язык:
Мне лень развивать эту ветку в такой форме, потому я готов согласиться на что угодно, наприме что все языки — нативные, все языки — менеджед, все языки — интерпретируемые и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
I>>>Хорошо, все программы — нативные, все программы — менеджед, все программы — интерпретируемые ГВ>>Ну, поскольку процессор умеет исполнять только нативный код, то, думаю, можно ограничиться первым.
I>Отлично. Все программы — нативные. А следовательно быть никакого ренесанса и конца нересурсов быть не может.
Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Отлично. Все программы — нативные. А следовательно быть никакого ренесанса и конца нересурсов быть не может.
ГВ>Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк.
Да не вопрос. Но других то определений нет и не предвидится
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Есть тестирование чтобы предотвратить случайные ошибки, есть управляемые среды, которые просто не допускают некоторые классы ошибок.
V>Эээ... Ты сейчас понял хоть, что сказал? Управляемая среда не может "не допустить ошибку" выхода за пределы, например, она честно выплюнет баг... И если повезет — во время тестирования. Но в плане "недопущения" — это фантазии.
Не говори глупости. Я использую foreach у меня вообще нет ошибок выхода за пределы массива, их в принципе не может появится.
V>К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет.
Дык есть codecontracts, кроме того есть unit-тесты, которые проверяют утверждения, которые в свою очередь невозможно вычислить статически.
G>>Процент багов, связанных с неправильным кодированием, попадающими в production очень низок. V>Процент от объема логики или от чего?
Процент от всех потенциально возможных.
V>>>И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию. G>>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна). V>Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования.
Ну давай вернемся. Ты серьезно предлагаешь затратить 70% времени тестирования на тестирование результатов не нужных пользователю?
G>>А разницы между потоком и запросом почти нету на самом деле. Можно одно свести к другому и наоборот. V>Нельзя. Каждый запрос — локален, независим от остальных.
Это зависит от того как напишешь.
V>Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние.
Скажу по секрету что запросы тоже могут влиять на состояние. Например форум подсчитывает количество просмотров, на каждый запрос изменяется соcтоние.
Более того "поток данных" состоит из отдельных кадров, так что вопрос в том как работать с состоянием.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк. AVK>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет.
Я бы сказал не так. ИМХО, одни товарищи пытаются не слишком умело жонглировать словами, а другие развлекаются за их счёт. Добро бы те, первые, исправляли свои ошибки — ну ляпнул и ляпнул, с кем не бывает, так нет же, пытаются ещё и доказать что-то. С другой стороны — обе стороны упражняются в риторических умениях, так что, сплошное добро™ и благолепие, если разобраться.
А с третьей стороны — ну да, вот она, война информационного века — война смыслов (строгий онтопик для ФП, кстати). По сути, "первые" пытаются донести до окружающих простую до примитивного мысль: "C++ — в ж...", оформляя её в квазилогичное рассуждение, ну а "вторые" — раскатывают эту квазилогичность и таким образом, нейтрализуют неявную исходную посылку.
Ergo, не такие они и бессмысленные — эти самые споры о терминах. Ну и лулзы опять таки, куда ж без них?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Ты покажи сайт написаный на native, который работает соизмеримо с сайтом на ASP.NET?
Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта.
CS>>Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично. G>Это не значит что они умеют и знают WPF
А что там уметь и знать для EverNote? Ты его интерфейс видел? Это можно брать любой официальный пример и в 2 шага получить требуемое.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Эээ... Ты сейчас понял хоть, что сказал? Управляемая среда не может "не допустить ошибку" выхода за пределы, например, она честно выплюнет баг... И если повезет — во время тестирования. Но в плане "недопущения" — это фантазии. G>>Не говори глупости. Я использую foreach у меня вообще нет ошибок выхода за пределы массива, их в принципе не может появится.
V>"Не говори глупостей", "это хрень" и т.д. Думаешь, эти "заклинания" работают? V>ИМХО, прошли те времена, когда на RSDN оппоненты понимали что пишут не поставлялись в каждом втором абзаце строчке...
Это правда жизни. Ты пытаешься говорить то что противоречит практике. Мне даже лениво тебе объяснять все детали.
V>Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит.
Агащаз.
V>Например, попарный перебор элементов коллекции.
.Zip
V>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам.
Снова бред. Ты просто не в теме.
V>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.
Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
V>Пишу эти банальности не для тебя, разумеется, бо с тобой уже по 3-му кругу пошли на одно и то же... как том анекдоте, про очень пылкого в постели дедушку со склерозом. Это я для "независимых" читателей пишу, которые добрались до сюда и надеются вынести толику информации.
Ты бы лучше выглянул из своей норы, увидел бы что в .NET есть много способов априори избежать тех ошибок, которые постоянно случаются в unmanaged. Но если для тебя stl является пределом, то вряд ли стоит тебе что-то тут писать.
V>>>К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет. G>>Дык есть codecontracts, кроме того есть unit-тесты, которые проверяют утверждения, которые в свою очередь невозможно вычислить статически.
V>Мы уже не раз тут соглашались в разных спорах, что объем юнит-тестирования не может превышеть объем целевого кода на порядки. Ну кроме пресловутых программ для атомных электростанций и прочих сферических вещей. Если ты обложишь юнит-тестыми абсолютно все места, где идет динамическое приведение типов, используются банальные if, идет оперирование массивами и т.д. до бесконечности, то получить превышение объема тестового кода над целевым на пару порядков- как два пальца об асфальт. И я бы не видел регулярные падения дотнетных более-менее крупных программ. К джаве это так же относится.
Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются.
V>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом.
Не, в C# такой код просто не будет написан. Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.
V>Опять ошибаешься, и уже делился информацией не раз. Например, открыть нашу JIRA, и там багов, связанных с порчей памяти, будет всяко меньше одного процента. Далеко не у каждого проекта хотя бы раз, при общем кол-ве фиксов на каждый проект за несколько лет жизни в сотни. Т.е. ошибки в логике происходят примерно в тысячу раз чаще, чем ошибки собственно кодирования. Да, разумеется, юнит тестирование используется. Как раз чаще всего для проверки граничных условий и соблюдения инвариантов. Надо просто понимать, что стоит проверять в первую очередь. Все подряд, естественно, мы не проверяем.
Именно, вот managed позволяет сконцентрироваться на логике, а в unmanaged ты вынужден и за памятью следить. При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
G>>>>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна). V>>>Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования. G>>Ну давай вернемся. Ты серьезно предлагаешь затратить 70% времени тестирования на тестирование результатов не нужных пользователю?
V>Именно.
Это тоже бред. Ни один толковый менеджер не позволить такое сделать.
V> Даже озитивные юнит-тесты, проверяющие граничные случаи, фактически проверяют те сценарии, которые никогда не происходят (или крайне редко).
Нет, то что не происходт — не проверяется. Нет смысла писать тесты для наборов входных данных, которые не появляются в работе. Лучше такие места заткнуть ассертами (или code contracts), любое срабатывание которых очевидно говорит о баге, который надо править.
V>Почему именно так? Помнишь, про относительную надежность? У вас в продукте тысячи таких примитивных мест, и если надежность каждого из них жалкие ~99.9%, достигнутые через код ревью и проверку только позитивных моментов, то программа ваша в большинстве случаев будет падать. Всё просто. Поэтому тут и пишут некоторые, что у них огромный отдел "ручных" тестировщиков. Их задача как раз "тупо" запускать программу в различных условиях, что бы вылазили боком те самые непокрытые негативные сценарии в различных комбинациях. А что еще можно проверять в ручном режиме? Помедитируй на эту тему... И как приговор: ручное тестирование — это аналог тыканья пальцем в небо. Можно попасть, а можно нет — как повезет.
Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит.
Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе.
V>>>Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние. G>>Скажу по секрету что запросы тоже могут влиять на состояние. Например форум подсчитывает количество просмотров, на каждый запрос изменяется соcтоние. V>Но требования к оперативности получения этой изменяемой величины стремятся с 0-лю. Каждый запрос вполне может слать выделенному сервису тикет, который будет вставлен в неспешную очередь, которая будет разгребаться в отсутствии пиков загрузки с подходящим приоритетом и т.д. Что я тебе тут рассказываю, в общем, базовые вещи уровня 3-го курса профильной специальности...
Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Ты покажи сайт написаный на native, который работает соизмеримо с сайтом на ASP.NET?
V>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта.
Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.
CS>>>Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично. G>>Это не значит что они умеют и знают WPF V>А что там уметь и знать для EverNote? Ты его интерфейс видел? Это можно брать любой официальный пример и в 2 шага получить требуемое.
Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп.
WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.
Здравствуйте, gandjustas, Вы писали:
V>>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта. G>Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.
Ты случайно не клиентскую DHTML-фичу имеешь ввиду?
Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере.
Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился.
Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.
И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++)
Ну и даже брать задачи работы с БД, где ASP.Net якобы является "удачной прослойкой"... Дотнетный парсер потока MS SQL сливает нейтивному в 4-5 раз (а то и более, если идет много числовых полей и мало строковых). Т.е. на сегодня ситуация такова, что нейтивный MS SQL способен выдавать данные быстрее, чем дотнетные приложения способны парсить его ответ... Хохма натуральная. Уже на гигабитных картейках в локалке это видно во всей красе.
Поэтому действительно "быстрые" веб-сервера пишутся как нейтивная часть некоторого сервера, например модули Apache или нейтивные модули IIS. Так же полно популярных нейтивных либ, вроде этой, обыгрывающих серверную часть HTTP-протокола. Ты просто очень далек от современной ситуации в web, судя по твоим постам...
G>Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп. G>WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.
Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать...
Здравствуйте, AndrewVK, Вы писали:
MS>>Да элемеентарно. Когда у тебя зоопарк из 15 платформ, C++ это единственно возможный вариант.
AVK>Когда у тебя зоопарк из 15 платформ, скорее подойдет Java.
До 2005-го так и было. Но потом компиляторы С++ как-то стали получше соответствовать стандарту. Прямо на сегодня разработка в исходниках под зоопарк платформ уже не является таким кошмаром, как, скажем, в 99-м году.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Ты их по скорости сравнивал? G>>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.
V>Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?
В смысле? 10000 раз в секунду пересчитать сумму массива? Данивопрос, посчитаю один раз и верну ответ.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
AVK>Тебе? Не буду. Упражнения в демагогии, уж извини, в мои ближайшие планы не входит. А интереса к реальному положению дел, судя по этому топику, у тебя нет.
Но тем не менее ты ей занимаешься. Например, сознательно смешивая ответ лично мне и комментарий на публичном форуме.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>А интереса к реальному положению дел, судя по этому топику, у тебя нет.
А что такое реальное положение дел? Я беру последний выпущенный фреймворк (4-й) и пытаюсь выяснить: сработает ли прославленная JIT-оптимизация на простейшем, казалось бы, случае:
v.Aggregate(c, (acc, k) => acc += k, acc => acc);
Не срабатывает. Окей, я понимаю, что здесь массивная конструкция итераторов и ещё байт знает, что, с чем и плюсовый компилятор вряд ли управится. Ну хорошо, это перебор. Сделаем проще:
static T accumulate<T>(T init, T[] array, Func<T, T, T> func)
{
T result = init;
foreach (var x in array)
result = func(result, x);
return result;
}
c = accumulate(c, v, (acc, k) => acc + k);
Однако, этот вариант тоже беспощадно тормозит, правда, "всего лишь" вшестеро по сравнению с C++-ными лямбдами. Хотя, казалось бы, тут есть все условия для полного инлайнирования. Где оно? В смысле — может быть, инлайнинг и есть, но я не вижу вменяемого результата этого инлайнинга. Код полностью замкнут, это не библиотека с открытым API, размер массива — константа и т.п. Оптимизируй — не хочу.
Вот такое реальное положение дел. ЧЯДНТ?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
V>>Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach. G>Зачем? Это ведь написаный, протестированный и отлаженный не мной код. Там OutOfRangeException не возникает. Я его использую и у меня не возникает. G>Мы ведь говорим за код приложений.
И что? Твои задачи всегда проще, чем код библиотек фреймворка? Если да, то... то тем более не стоит свою рубаху на всех натягивать.
V>>Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой? G>Ты удивишься но написание почти всего кроме быстрой сортировки на месте и умножения матриц не требует цикла for.
Мде... Любая обработка сигналов и просто информации практически всегда требует цикла for. Даже такая тупая вещь как AI.
Кстати да, я действительно удивился.
G>>>Для моих задач быстродействия linq более чем хватает V>>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться? G>Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
Если в личке спросишь, ссылок отсыплю. Но это не принципиально, ведь даже на этом сайте полно форумов, где ни слова о дотнете и много чего обсуждают.
G>Не, в managed просто нет таких ошибок или сразу exception.
Детсад.
V>>Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз. G>Меня не интересуют низкоуровневые детали, пусть хоть полностью в unmanaged перепишут. Меня как раз интересует прикладной код и библиотеки прикладного кода. Linq например импользуется чаще, чем StringBuilder и внутри первого нету for и массивов, а внутри второго есть.
Да я понял, что работа у тебя очень узкая: прочесть поле из базы, записать поле в базу. Не понял только, с какой стати столь далекоидущие выводы? Уж чего-чего, а этого твои оппоненты тоже наелись по самое нихочу. Просто стараются избегать подобной рутины. Не всегда получается, правда.
V>>Это ты только что сам придумал? G>Нет, это правда жизни. Не бывает медленных программ, бывают недостаточно быстрые.
Это верно, если программа одна такая на всю нишу. Гораздо чаще бывает такая банальность: лидер в какой-то нише и остальной невостребованный мусор.
G>Не-а, когда обе программы "достаточно быстрые", то уже не быстродействие является главным козырем.
Хе, обе. Твоя-то не будет.
V>>И даже в заказном ПО при условии честных тендеров, как ни странно, тоже. G>В заказном ПО как раз заранее характеристики обговариваются и никто не парится сделать максимально быстрым.
О максимальности речи и не идет. Но если приложение с неплохими характеристиками, надежное при этом, всяко больше шансов получить хороший следующий заказ.
G>Хотя как раз в обоих случаях сроки разработки важнее скорости работы программы, особенно для первых версий, потому что начав продавать можно уже работать за деньги клиентов, а не их своего кармана.
Ну так про макетирование и прочие вещи и на плюсах речь шла. Это универсальные подходы. Любая вменяемая разработки итеративна, иначе она не увидит свет.
G>>>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности. V>>Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего. G>Действительно? Только я за это время успел из рядового программиста стать преподавателем, MVP, очень востребованным специалистом и руководителем небольшой фирмы, по пути поработав и тилидом и немного ПМ.
В 3 года можно уложиться. Все равно ведь не поверю, что в 2003-м, например, не сталкивался с задачами, где дотнета не хватало. Это значит, в эти года ты вообще всерьез ни с чем не сталкивался, бо ровно наоборот — под дотнет подходили только некоторые ниши.
G>Как раз да. Приведи ссылку где набирают C++ про новый проект, только не новую версию старого.
V>>>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>>>Не пишется, а саппортится, пишется на порядки меньше. V>>Опять мимо. G>Ну конечно, у тебя просто прямое подключение к богу статистики и ты все лучше знаешь.
Тебе там на семинарах просто мозги промыли. У самой MS мильон относительно новых нейтивных разработок, например, сервера конференций. Любое медиа сейчас идет в нейтиве, VoIP тоже, вся связь, любая обработка сигналов, изображений, и просто информации. Огромный финансовый рынок, из которого даже если и торчат концы в дотнет и джаву, то это именно что лишь самые "наконечники". Есть EDI/HIPPA и прочее, перемалывающее многомегабайтные (!!!) электронные документы. Вот как-то вокруг всех этих направлений дейтельность и складывается. И разве я говорил, что не юзаю дотнет? Еще как юзаю, бо столько функционала нахаляву, и когда его характеристики позволяют, то почему бы и нет? Это же нормально. Но в половине случаев управляемые среды не катят. Я тут всего лишь делюсь опытом, а ты утверждаешь, что нам вообще не стоит этим заниматься, коль задача нерешаема на дотнете, а на С++ обязательно будут баги. А кто тогда будет их решать? Кто напишет тебе управляемую среду? Драйвер GPU? Фильтр под QoS? Шуструю игруху или отзывчивое офисное приложение? Пушкин? Почему участники этого форума не могут-то? Или это настолько в твоем представлении из "далекой галактики", что факт живого общения с людьми из "того" мира тебе кажется нереальностью или как?
И вообще, где ты видел указанные ЗП для спецов верхнего эшелона? Много ты видел афишируемых ЗП для руководителей проектов?
Хотя иногда и проскакивают цифры в 160к для специалиста. Это совсем плохая ЗП для Москвы или как, проясни?
Или вот это что:
Разработка серверной части высокопроизводительного приложения;
Участие в проектировании архитектуры одного из крупных проектов компании.
Это разве не серверная часть? И разве архитектуру разрабатывают не у новых проектов?
Короче, пора было тупо свернуться. У тебя кругозор ровно одной платформы. По остальному ты слышал звон, но не знаешь где он. Требуешь данных и ссылок, а в упор их не видишь. Эту избирательную "слепоту" посторонний человек тебе всё равно никогда не вылечит, только ты сам, если будет желание.
V>>Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана. G>И то и другие — инструменты.
Принципиально разные. Независимо от языка. Срабатывание ассерта в real-time требует принципиально другого сценария, чем срабатывание проверки контрактов. Во втором случае это могут быть просто неверно введенные пользователем данные, а в первом — это ошибка в самой программе. Необходимо как можно скорее выйти и не дать навредить. Однако, сам сценарий выхода должен зависеть от того, где мы находимся и что делает клиент. В общем, их ну никак нельзя сваливать в одну кучу. Конкретно в текущей области моей работы, самым лучшим сценарием на срабатывание run-time assert будет запись в лог координат ошибки и стека, выдача как можно более вежливого сообщения об ошибке в программе в какой-нить callback клиентскому коду, и немедленный выход.
V>>Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок. G>В CodeContracts тоже есть ассерты если что
Серьезно? И то и другое что-то проверяет и может выплюнуть эксепшен. Да они же одинаковые? Не?
V>>Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента. G>А если напишешь проверку то что? Кинуть exception? Ассерты говорят что какое-то условие должно выполнятся всегда, то есть вообще всегда — не выполняется, надо править программу, зачем еще что-то писать для того же резльтата? Если в процессе тестирования ассерт не выпадал, а выпал у клиента при нормальной работе, значит и процесс тестирования надо улучшать.
Чем дальше в лес, тем толще партизаны. Т.е. вы таки постоянно привлекаете клиентов к тестированию? Везет, что еще могу сказать.
G>Смешной ты, много ты процесс тестирования организовывал? Я то как раз прекрасно знаю про качество знаю и знаю где находится граница good enough.
Спецов нанимал, они организовывали и тестеров учили. Как раз, чтобы отсебятину не пороть. Все твои "я то как раз прекрасно знаю" — сугубо субъективны. Если вы на клиенте отлаживаетесь, давай ты мне про кач-во ничего больше говорить не будешь?
G>О, да. Тут послушать так все минимум софтом для космических кораблей занимаются. А я занимаюсь софтом, который бабло приносит.
А остальные за голый интерес что ле работают? Чем ты занимаешься, уже поняли. Это проходили почти все в разное время. У тебя такой сейчас период, ну что ж... Дерзай.
Здравствуйте, AndrewVK, Вы писали:
V>>Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc
AVK>Вот когда бекенд стандартизуют на 100% у всех компиляторов, а потом большую часть API всех часто используемых ОС тоже, тогда и можно будет сравнивать кроссплатформенность С++ и джавы.
В реальной жизни переносимость на уровне исходников достаточна. кошмар был когда уже на этом уровне приходилось изворачиваться.
У джавы когда-то наблюдал под разные платформы шли разные инсталляхи аппликух. Да еще каждая с собой тащит свою версию фреймворка. Не знаю как последние годы, не слежу.
G>>>Для моих задач быстродействия linq более чем хватает V>>Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться? G>Я зенимаюсь тем же, чем и тысячи других программситов, значит им тоже. А ты наверное один такой уникальный, или на пару с ГВ, кому быстродейтсвия не хватает категорически, хотя что за задачи — хз. Ни ты ни он не колетесь.
Обычные задачи с приличным объемом данных и никакой магии. Если есть млрд айтемов, то лишние 100тиков на обработку ~30сек задержка, лишний байт — расход 1ГБ оперативки. Добавь сюда немножко активных клиентов, жесткие ограничения на время отклика системы и коктейль готов —
в дотнете перестает устраивать абсолютно все.
ГВ>- В 1999-2009 акцент в индустрии смещался с энергопотребления и энергоэффективности [...]
...смещался с производительности [...]
Энергоэффективность там упоминается в другом контексте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>- Начиная с 2010 всё возращается на круги своя — начинают считать циклы/ватт потребляемой мощности (Саттер называет это Return of The King);
Остается ключевой вопрос:
в каком именно году весь код facebook-а и все приложения android-а перепишут на C++? а также все тонкие приложения (например, gmail)?
Здравствуйте, DarkGray, Вы писали:
ГВ>>- Начиная с 2010 всё возращается на круги своя — начинают считать циклы/ватт потребляемой мощности (Саттер называет это Return of The King);
DG>Остается ключевой вопрос: DG>в каком именно году весь код facebook-а и все приложения android-а перепишут на C++? а также все тонкие приложения (например, gmail)?
The main challenge of the project was bridging the gap between PHP and C++. PHP is a scripting language with dynamic, weak typing. C++ is a compiled language with static typing. While PHP allows you to write magical dynamic features, most PHP is relatively straightforward. It's more likely that you see if (...) {...} else {..} than it is to see function foo($x) { include $x; }. This is where we gain in performance. Whenever possible our generated code uses static binding for functions and variables. We also use type inference to pick the most specific type possible for our variables and thus save memory.
The transformation process includes three main steps:
1. Static analysis where we collect information on who declares what and dependencies,
2. Type inference where we choose the most specific type between C++ scalars, String, Array, classes, Object, and Variant, and
3. Code generation which for the most part is a direct correspondence from PHP statements and expressions to C++ statements and expressions.
И на момент публикации (февраль 2010) обслуживали 90% трафика с помощью этого самого HipHop.
Так что...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
в моем понимании, как всё эти годы был акцент на том, что программист пишет на той фигне, на которой ему удобнее, а умный черный ящик обеспечит, чтобы это выполнялось быстро, так он и остался.
максимум, что поменялось за это время — это то, что из-за появления реальной многоплатформенности появилась тенденция генерить не сразу машкод, а сначала C++/C, java-у или .net, который уже потом транслируется в машкод.
Здравствуйте, DarkGray, Вы писали:
ГВ>>Они там, похоже, трансформируют PHP в C++:
DG>тогда тем более можно считать, что .net и java тоже трансформируются в C++ (вернее, сразу в машкод).
Считай, кто тебе запрещает?
DG>в чем тогда point статьи?
Пойнт в том, что по причинам низкой производительности кода, получаемого из PHP Facebook-у пришлось воспользоваться вот такой хитрой технологией.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>>Пойнт в том, что по причинам низкой производительности кода, получаемого из PHP Facebook-у пришлось воспользоваться вот такой хитрой технологией.
DG>так для Facebook новый код-то пишется на php? или сразу на C++?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>> Об этом можно спорить, конечно, но демагогии вокруг того, насколько производительность программиста важнее производительности программы я тоже наслушался по самую макушку.
DG>на примере JavaScript-а и sql-я видно, что кроме вышеперечисленного, еще важна переносимость и дуракоустойчивость
Правда, что-то мне подсказывает, что в случае Facebook решающим аргументом был накопленный объём исходников на PHP.
ГВ>>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов. Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
DG>если уж из php умудряются генерить C++ код без gc (или все-таки у них там есть свой GC?), то уж из .net-а или java-ы тем более это можно сделать.
А кто-то с этим спорил? Осталось только додаться появления компиляторов Java->C++ и C#->C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>если уж из php умудряются генерить C++ код без gc (или все-таки у них там есть свой GC?) [...]
Слушай, скачай, да посмотри, что и как они там генерят. Вот ссылка на википедию, дальше по ссылкам. Проект с открытыми исходниками.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
ГВ>>И на момент публикации (февраль 2010) обслуживали 90% трафика с помощью этого самого HipHop. C>Реально HipHop — это на практике просто threaded interpreter. Среднее ускорение 2-3 раза всего по сравнению с чистой интерпретацией.
В принципе — неплохой результат, если учесть, что иначе им пришлось бы тонны кода переписывать. С другой стороны — наверняка, можно было бы добиться большего, если бы, как я понимаю, не необходимость тащить саму модель PHP.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В принципе — неплохой результат, если учесть, что иначе им пришлось бы тонны кода переписывать. С другой стороны — наверняка, можно было бы добиться большего, если бы, как я понимаю, не необходимость тащить саму модель PHP.
Хех. У меня тут знакомый переписал код с php на Node.js — тупо простым переносом кода с php на JavaScript. Так оно стало работать в 5 раз (!!!) быстрее из-за того, что для JS виртуальная машин делает нормальную компиляцию.
Здравствуйте, dimgel, Вы писали:
C>>Хех. У меня тут знакомый переписал код с php на Node.js — тупо простым переносом кода с php на JavaScript. D>Там модели наследования слишком сильно отличаются, тупо не перенесёшь, разве что код совсем простой. (К теме jit это отношения не имеет.)
Насколько я понял, там у него дубовый код на PHP без всяких классов и прочего.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>> Осталось только додаться появления компиляторов Java->C++ и C#->C++.
DG>второе уже, как минимум, два года есть в виде того же MonoTouch http://en.wikipedia.org/wiki/Mono_(software)#MonoTouch , который переводит C# в objective-c
Куда, куда, извините?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
ГВ>>В принципе — неплохой результат, если учесть, что иначе им пришлось бы тонны кода переписывать. С другой стороны — наверняка, можно было бы добиться большего, если бы, как я понимаю, не необходимость тащить саму модель PHP. C>Хех. У меня тут знакомый переписал код с php на Node.js — тупо простым переносом кода с php на JavaScript. Так оно стало работать в 5 раз (!!!) быстрее из-за того, что для JS виртуальная машин делает нормальную компиляцию.
Так у Facebook в том и прикол, что они не могли отказаться от использования PHP при всём желании.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
U>>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии. C>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд.
Который надо было сделать 7 лет назад.
U>>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией. C>И пофиг, зато быстро работает.
Про переполнение буфера забыли?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>К разговорам о ренессансе C++.
Нет никакого ренессанса.
ГВ>Чертовски любопытное выступление Герба Саттера "Why C++".
Мне хочется Саттера спросить, за что они C++ так изуродовали. Тот что в WinRT это не C++, это мутант. Ты сам-то смотрел на это чудо?
ГВ>В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать.
Нет, просто нынче модными стали планшеты, а их производительность относительно не очень высока. МС, чтобы не упустить этот кусок рынка пришлось допиливать Винду, чтобы она более менее нормально шла под маломощные планшеты. А тут альтернатив кроме C++ особо и нет.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Klatu, Вы писали:
M>>>>Про переполнение буфера забыли? C>>>Это что, такое пугало для детей? K>>Нет, для взрослых дядек, у которых внезапно оказывается что их сервер уже не совсем их. C>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью.
Все бы не отказались. Кажется в Google Go для этого сделали слайсы.
C>Хм. Написать что-ли статический проверяльщик, который ровно это делает?..
Напиши Но ИМХО это пока из области научной фантастики.
Здравствуйте, __lambda__, Вы писали:
ГВ>>К разговорам о ренессансе C++. ___>Нет никакого ренессанса.
ИМХО, это из разряда "память больше не ресурс" и прочей "халвы".
ГВ>>Чертовски любопытное выступление Герба Саттера "Why C++". ___>Мне хочется Саттера спросить, за что они C++ так изуродовали. Тот что в WinRT это не C++, это мутант. Ты сам-то смотрел на это чудо?
C++ как C++, слегка подрихтованный под COM. Темплейты, указатели, генерация бинарников на месте, а остальное — да хай себе развлекаются.
ГВ>>В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать. ___>Нет, просто нынче модными стали планшеты, а их производительность относительно не очень высока. МС, чтобы не упустить этот кусок рынка пришлось допиливать Винду, чтобы она более менее нормально шла под маломощные планшеты. А тут альтернатив кроме C++ особо и нет.
Ты почитай бумажку про Dark Silicon. Не одними планшетами....
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, uncommon, Вы писали:
U>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии.
А что, если сказали: "C++ renaissance", то это непременно должно означать, что — раз, и все проснулись в мире, где пропали managed-языки?
U>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией.
Ну и что? C++ остался тем же самым, а синтаксические примочки никого не пугают.
U>MS рванул из огня да в полымя. XAML и Silverlight не смогли дотянуть, давайте все на свете перепишем на С++ и HTML5. Ну и понятно, чем это закончится. Очередным рывком обратно в огонь, как показывает уже 20-летняя история развития MS технологий.
XAML как раз остаётся на своём месте. Silverlight — ИМХО, туда ему и дорога. А 20-летняя история показывает, что C++ и COM вполне устояли на своём месте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Не смешно.
U>>>>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией. C>>>И пофиг, зато быстро работает. M>>Про переполнение буфера забыли?
ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
Одного тестирования мало. Надо использовать современные языковые средства, а не "unsafe буферами и голыми указателями".
Честно говоря, я не очень понимаю, к чему ругать действия Комитета, если по ходу дела ругают сам C++. Это, что ли, лишь бы ругаться хоть на что-нибудь, относящееся к C++? Мне за C++ не обидно, не подумай, просто забавно всё это выглядит: не то C++ — плохой, не то Комитет.
C>>>>И пофиг, зато быстро работает. M>>>Про переполнение буфера забыли? ГВ>>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
M>Одного тестирования мало. Надо использовать современные языковые средства, а не "unsafe буферами и голыми указателями".
Я не спорю, языковые средства контроля выхода за границу буфера — вещь полезная. Только не надо преувеличивать её значение. Runtime-исключение, вылетающее в самый неподходящий момент ничуть не приятнее AV или эксплоитной дырки. Метод борьбы одинаков во всех случаях — исправление программы и приведение в порядок работы с индексами. Только в случае unmanaged-языков исправленная программа больше не потребляет ресурсов на ненужный самоконтроль, а в случае managed — продолжает заниматься самопроверками.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
ГВ>>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
K>Ткнешь в любой массовой продукт — везде дырки. Один только Геннадий Васильев красавчик и непризнанный лидер программизма, у которого все проблемы решаются на раз
Это ты, типа, на личности пытаешься перейти? Толсто, дружище, толсто!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
ГВ>>Я не спорю, языковые средства контроля выхода за границу буфера — вещь полезная. Только не надо преувеличивать её значение. Runtime-исключение, вылетающее в самый неподходящий момент ничуть не приятнее AV или эксплоитной дырки.
K>Действительно, какая разница. Просто выдали ошибку, в худшем случае аккуратно закрыли процесс. Или дали возможность злодею анально поиметь хозяина компа. Вообще никакой разницы
Уел, уел. Про "эксплоитную дырку" разрешаю вычеркнуть. Правда, они тоже обнаруживаются при тестировании — обычно каналов получения внешних данных у программы немного и их можно проверить. Но это ж тестировать надо!
И кроме того, это ещё очень большой вопрос, где этих самых дырок для эксплоитов допускается больше — в коде на C или в насквозь защищённых языках с их навороченными объектными конструкциями.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
ГВ>>Это ты, типа, на личности пытаешься перейти? Толсто, дружище, толсто! K>Неинтересна мне твоя личность. Просто очень сильно сомневаюсь в твоем профессионализме.
Поскольку я не знаю, что означает термин "профессионализм", то я ни подтвердить, ни опровергнуть твои сомнения не в силах. Что такое "профессионал" — знаю, это тот, кто зарабатывает на хлеб насущный некоторой профессией. А что такое "профессионализм" — тайна сия... Во всяком случае, википедия несёт сущий бред по этому поводу:
Профессионализм — особое свойство людей системно, эффективно и надёжно выполнять сложную деятельность в самых разнообразных условиях.
Хотя, конечно, если ты более адекватно раскроешь значение этого термина, можно попытаться выяснить что-нибудь относительно моего профессионализма. Люблю разные психологические тесты.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Здравствуйте, Cyberax, Вы писали: ГВ>>>В принципе — неплохой результат, если учесть, что иначе им пришлось бы тонны кода переписывать. С другой стороны — наверняка, можно было бы добиться большего, если бы, как я понимаю, не необходимость тащить саму модель PHP. C>>Хех. У меня тут знакомый переписал код с php на Node.js — тупо простым переносом кода с php на JavaScript. Так оно стало работать в 5 раз (!!!) быстрее из-за того, что для JS виртуальная машин делает нормальную компиляцию. ГВ>Так у Facebook в том и прикол, что они не могли отказаться от использования PHP при всём желании.
Ну так пусть заплатят Гуглу, чтобы им сделали нормальную виртуальную машину для PHP. Или транслятор из PHP в V8. Специалисты в Гугле есть.
Здравствуйте, gegMOPO4, Вы писали:
C>>>Хех. У меня тут знакомый переписал код с php на Node.js — тупо простым переносом кода с php на JavaScript. Так оно стало работать в 5 раз (!!!) быстрее из-за того, что для JS виртуальная машин делает нормальную компиляцию. ГВ>>Так у Facebook в том и прикол, что они не могли отказаться от использования PHP при всём желании. MOP>Ну так пусть заплатят Гуглу, чтобы им сделали нормальную виртуальную машину для PHP. Или транслятор из PHP в V8. Специалисты в Гугле есть.
Скажи это сотрудникам Facebook.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали: DG>если уж из php умудряются генерить C++ код без gc (или все-таки у них там есть свой GC?), то уж из .net-а или java-ы тем более это можно сделать.
Срок жизни php-программы невелик, сборкой мусора можно не заморачиваться. Пришёл запрос — инициализировали область памяти, всё выделение только из неё, по окончании обработки всю область грохнули. Ни деструкторов, ни циклических ссылок.
MOP>Срок жизни php-программы невелик, сборкой мусора можно не заморачиваться. Пришёл запрос — инициализировали область памяти, всё выделение только из неё, по окончании обработки всю область грохнули. Ни деструкторов, ни циклических ссылок.
согласен. добавлю лишь, что это возможно в любой stateless-программе на любом языке, а не только php.
Здравствуйте, Mazay, Вы писали:
C>>Хм. Написать что-ли статический проверяльщик, который ровно это делает?.. M>Напиши Но ИМХО это пока из области научной фантастики.
Почему? Просто достаточно запретить все небезопасные обращения. Т.е. доступ к вектору/строчке — только по at() и т.п.
С арифметикой указателей только аккуратно надо будет, особенно с итераторами.
Здравствуйте, monax, Вы писали:
C>>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью. M>pascal?
Просьба пройти в биореактор и не выходить оттуда.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, monax, Вы писали:
C>>>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью. M>>pascal? C>Просьба пройти в биореактор и не выходить оттуда.
компилируемый? — да. проверка границ есть? — да. запросы соблюдены? — да. так что биореактор ждёт тебя
Здравствуйте, monax, Вы писали:
C>>>>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью. M>>>pascal? C>>Просьба пройти в биореактор и не выходить оттуда. M>компилируемый? — да. проверка границ есть? — да. запросы соблюдены? — да. так что биореактор ждёт тебя
Тут один минус — язык Паскаль.
Здравствуйте, Pzz, Вы писали:
ГВ>>К разговорам о ренессансе C++. Pzz>Глядишь, они на этом не остановятся, и пойдут дальше, к Си без плюсов или даже к ассемблеру
Ну что, запасаемся попкорном?
Вообще, глядя на реакцию публики я бы запасался кофе, а то уснуть можно. Тут, понимаешь, бравые техасские парни сногсшибательные вещи пишут, а народу — хоть бы хны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
ГВ>>Тут, понимаешь, бравые техасские парни сногсшибательные вещи пишут, а народу — хоть бы хны. IT>Дык в Техасе хорошие пастухи, а не программисты. Вот если бы они написали как настоящий стейк готовить, тогда да.
С другой стороны, уж кто-кто, а пастухи-то понимают в ресурсах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Дык в Техасе хорошие пастухи, а не программисты. Вот если бы они написали как настоящий стейк готовить, тогда да. ГВ>С другой стороны, уж кто-кто, а пастухи-то понимают в ресурсах.
И ещё в навозе.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Дык в Техасе хорошие пастухи, а не программисты. Вот если бы они написали как настоящий стейк готовить, тогда да. ГВ>>С другой стороны, уж кто-кто, а пастухи-то понимают в ресурсах. IT>И ещё в навозе.
Это не порок.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>>>Дык в Техасе хорошие пастухи, а не программисты. Вот если бы они написали как настоящий стейк готовить, тогда да. ГВ>>>С другой стороны, уж кто-кто, а пастухи-то понимают в ресурсах. IT>>И ещё в навозе.
ГВ>Это не порок.
Да уж.. порой мне кажется, что для программиста это — насущная необходимость
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.
Когда то я это уже слышал. Лет 8 назад. Сюрприз — из IL кода с почти 100% точностью можно восстановить исходник.
ГВ> Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
Как человек, который перформансом дотнет приложений регулярно занимается, смею тебя заверить — на практике проблемы далеко не в оптимизациях компайлера или GC.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.
AVK>Когда то я это уже слышал. Лет 8 назад.
Я думаю, где-то уж лет 10 должен слышать.
AVK>Сюрприз — из IL кода с почти 100% точностью можно восстановить исходник.
Ах, ну да. Рефлектор же... Ай-яй-яй мне.
ГВ>> Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).
AVK>Как человек, который перформансом дотнет приложений регулярно занимается, смею тебя заверить — на практике проблемы далеко не в оптимизациях компайлера или GC.
А в чём? Интересно было бы узнать твоё мнение.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы). S>Осталось понять, что ж ни Adobe, ни MS, ни Apple не выловили и не вылечили это всё на раз. А продолжают мне дважды в месяц присылать очередные апдейты, где "fixed the vulnerability allowing a remote attacker to gain a control over compromised system".
Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто. ИМХО, разумеется. И трудно предположить, что эти считанные дыры могут заставить переписать всё на новом языке.
S>Наверное, менеджмент во всех трёх сговорился и систематически дурит с тестированием.
Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится.
Влияющих факторов может быть очень много: использование стороннего кода, какие-нибудь флуктуации в "давлении сроков" или, скажем, "внезапное" изменение таймингов аппаратуры. Да до хрена всего.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто.
Я здесь подменил количество ошибок количеством бюллетеней — это неправильно. Но тем не менее, у той же MS, к примеру, дырок не много (в штуках не скажу).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
ГВ>>>А в чём? Интересно было бы узнать твоё мнение. AVK>>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках. V>Дык, такие вещи ни от платформы, ни от языков не зависят.
V>ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования, где любые решения по-месту эффективности ради считаются чуть ли не хакерством. Как в том большом обсуждении задачки для собеседования про "бесконечную" очередь. В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже), но это порой требует лишнего ручного приседания в алгоритмах. И аргумент "надо, значит надо" для многих банально не подходит, т.к. большинство дотнет разработчиков не связаны с задачами, критичными к перформансу. Для них плохой перформанс — это, например, многократно открывать один и тот же файл, для последовательного чтения строк. Или организация доступа по порядковому номеру в связанных списках (встречал и такое).... Только дотнет тут не при чем, повторюсь. Это лень и безалаберность.
Я бы не стал, наверное, связывать такую культуру именно с дотнетом, поскольку вокруг "формочек к СУБД" наблюдал такие рассуждения довольно давно. Да, точно. Первый раз я это услышал от спеца, принёсшего весть не то с конференции MS, не то с какой-то UG в 1997-м: что, мол, "сейчас главное — разрабатывать программы быстро, а то, что форма рисуется не за 200 микросекунд, а за 200 миллисекунд — так кому какая разница!" и тут же: "MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась). Вот где-то тогда, видимо, этот "нересурсный" мем и зарождался.
То есть "культурные" корни тут длинные. Ещё и Java подсуетилась.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
ГВ>>Поскольку я не знаю, что означает термин "профессионализм" K>Почему-то я даже не удивлен
Ну что поделать. Могу только посоветовать ещё несколько способов перестать удивляться и начать удивлять самому:
— Выдернуть отдельные слова из реплики;
— Переставить их местами;
— Можно ещё и буквы перемешать.
Как видишь, перед тобой просто бескрайние горизонты!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Klatu, Вы писали:
ГВ>>>Поскольку я не знаю, что означает термин "профессионализм" K>>Почему-то я даже не удивлен
ГВ>Ну что поделать. Могу только посоветовать ещё несколько способов перестать удивляться и начать удивлять самому:
ГВ>- Выдернуть отдельные слова из реплики; ГВ>- Переставить их местами; ГВ>- Можно ещё и буквы перемешать.
ГВ>Как видишь, перед тобой просто бескрайние горизонты!
Спасибо за мастер-класс, но эти методы не для меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Klatu, Вы писали:
K>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
V>Это от технологии не зависит.
Здравствуйте, Klatu, Вы писали:
ГВ>>Уел, уел. Про "эксплоитную дырку" разрешаю вычеркнуть. K>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
О, чувствуется мастерство: два предположения, и оба — с явным переходом на личности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
K>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое? V>>Это от технологии не зависит. K>Чего-чего?
Садись, два.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Т.е. сама необходимость обеспечивать рантайм рефлексию накладывает серьезные ограничения на трансформацию кода и данных в процессе компиляции. Не зря когда-то в рамках Singularity пришли к тому, что в их специализированном компиляторе поддерживается только compile-time рефлексия.
Согласен. Хотя теоретически (в смысле — с непонятным практическим смыслом) можно держать две версии бинарников: оптимизированную для работы и неоптимизированную — специально для использования с рефлексией. Другое дело, что такой подход ещё больше нагрузит память. Да и время+ресурсы на JIT-компиляцию вырастут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто. ИМХО, разумеется. И трудно предположить, что эти считанные дыры могут заставить переписать всё на новом языке.
Ну вот видите, из "лечится на раз" мы перешли "присутствует в любой достаточно большой базе исходников".
ГВ>Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится.
ГВ>Влияющих факторов может быть очень много: использование стороннего кода, какие-нибудь флуктуации в "давлении сроков" или, скажем, "внезапное" изменение таймингов аппаратуры. Да до хрена всего.
Ну вот видите, из "только если не дурить с тестированием", мы получили "очень много влияющих факторов".
Отличный прогресс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто. ИМХО, разумеется. И трудно предположить, что эти считанные дыры могут заставить переписать всё на новом языке. S>Ну вот видите, из "лечится на раз" мы перешли "присутствует в любой достаточно большой базе исходников".
Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал.
ГВ>>Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится. ГВ>>Влияющих факторов может быть очень много: использование стороннего кода, какие-нибудь флуктуации в "давлении сроков" или, скажем, "внезапное" изменение таймингов аппаратуры. Да до хрена всего. S>Ну вот видите, из "только если не дурить с тестированием", мы получили "очень много влияющих факторов".
Эти факторы как раз и влияют на "дурь" с тестированием.
S>Отличный прогресс.
Скорее — изменение предмета обсуждения.
Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
K>>>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое? V>>>>Это от технологии не зависит. K>>>Чего-чего?
ГВ>>Садись, два. K>Ну только не тебе это решать K>Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?
А ты не хами попусту и выражайся яснее, тогда и переспрашивать не придётся. Я-то подумал вообще про все такие ошибки (и vdimas, как я понимаю — тоже), а не только про те, которые наведены ошибками работы с памятью.
Кому может понадобиться такой или подобный код за пределами задач интеропа — могу только догадываться, но тем не менее, это "чистый" managed-код, который создаёт условия для той самой загадочной ошибки (чаще всего — AVE). Чистый в том смысле, что он не содержит прямых обращений к исполняемому unmanaged и скомпилирован с запретом unsafe.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Klatu, Вы писали:
ГВ>>О, чувствуется мастерство: два предположения, и оба — с явным переходом на личности. K>Отстань от меня со своей личностью, она меня совершенно не интересует. Утомил уже
А ты прекрати апеллировать к личности и уставать не придётся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А ты не хами попусту
Немедленно прекрати переходить на личности
ГВ>Кому может понадобиться такой или подобный код за пределами задач интеропа — могу только догадываться, но тем не менее, это "чистый" managed-код, который создаёт условия для той самой загадочной ошибки (чаще всего — AVE).
То есть, если захотеть и очень постараться, то такую ошибку можно получить и в менеджед коде. Действительно, практически никакой разницы
Здравствуйте, Klatu, Вы писали:
K>Ну только не тебе это решать
Дык, ты сам нарисовался в публичном форуме, так что уж терпи.
K>Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?
Твой новоязный термин "косвенность ошибки" я хоть понимаю интуитивно, но ты все равно ошибаешься. Наверно ты имел ввиду "наведенную ошибку", дык проход по памяти — это только один всех возможных способов ее получить. А плавающие — тем более! Плавающие в большей степени зависят от данных, вернее от соблюдения их инвариантов, чем от технологии программирования.
Насчет всех этих упомянутых эксплоитов... Во первых, чтобы получить контроль над машиной, код должен выполняться с определенными правами, даже нативный. А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ? Дотнет — это параллельная такая вселенная, далекая от всех этих страшных цифр и прочей головной боли реального мира... Во вторых, доля использование legacy-кода слишком большая, т.е. это еще код не то что до-дотнетных времен, это еще С++ нормального не было и многое писалось на С, в котором обеспечить типобезопасность, достижимую современным С++ невозможно. Например, чего стоило тут обсуждение относительно исправления семантики memcpy для линухов и того, что отвалился флеш-плеер... Это ж с каких годов бага там жила? Наверно, с самых первых вариантов 93-го года. Уже лет 10 никто непосредственно memcpy в логике не юзает. И тем более не создает массивы памяти вручную. Такие вещи если делают, то сугубо в системном коде, где С++ используется как замена С и ассемблеру. В общем, это не характеристика конкретно языка, а точно такая аналогичная "возможность" как в дотнете попортить память через unsafe, либо без вcякого unsafe банально через некорректные параметры при вызове методов классов Marshal, Buffer и т.д. В общем, возможность писать безопасно есть, так же как возможность писать небезопасно, полностью аналогично дотнету, так что от разработчиков всё еще больше зависит, чем от технологий.
Ну и популярные толкаемые вещи, что вот в дотнетной программе если ошибка, то можно пользователя попросить сохранить данные всвязи с ошибкой и аккуратно закрыться... Покажи мне хоть одну такую гламурную программу! Болтовня, короче. Всё что я видел, работает точно так же как нативные приложения, разница только в диалогах сообщения об ошибке, ибо null reference он и в Африке null reference. Отличие лишь в том, что стек трейс виден детальный, т.е. быстрее можно найти ошибку (если она не та самая наведенная )
Ну и справедливости ради, рядом положить PDB для нейтива, тоже всё увидеть можно.
Здравствуйте, Klatu, Вы писали:
C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд.
K>Но далеко не факт, что в правильном направлении
А в каком направлении должен развиваться язык, предназначенный для нейтива? Твои соображения?
Здравствуйте, AndrewVK, Вы писали:
AVK>Такие проблемы уже есть и никого особо не пугают. К примеру, инлайнинг методов корежит стектрейс.
Ну это, как раз, не страшно. В С++ это от рождения и не мешает. Тебе же не надо обеспечивать доступ к произвольной ячейке стека через рефлексию, поэтому противоречия нет.
AVK>Кроме того, далеко не всегда оптимизации вообще должны портить рефлексию. Устранение виртуальных вызовов, использование общей реализации для шаблонов с разными аргументами, escape анализ в джаве.
Ты еще забыл однократное извлечение адреса виртуальной ф-ии для многократного вызова в цикле. Конечно, это все оптимизации, как раз как я говорил — уровня 5-6-й версии С++. С которых пор он нехило продвинулся вперед, в отличие от, застрявшего в плане оптимизации на временах 2-го дотнета.
AVK>А есть ведь еще вещи, с оптимизацией не связанные, но точно так же вносящие несоответствие кода рефлексии — лямбды, итераторы, анонимные типы, async и т.п. И это, вобщем то, тоже особо никого не пугает.
Ниже по ветке я интересуемый сценарий насчет рефлексии уже уточнил:
Если рефлексия нам нужна только для получения метаинформации, то без проблем, т.к. метаинформация после JIT никуда не денется, но если эта метаинформация используется для целей динамического доступа к полям, например, даже приватным, ... надо обеспечивать, согласно исходной метаинформации.
Например, у нас нет возможности получить метаданные текущего итератора в цикле foreach, поэтому и обеспечивать доступ не к чему.
AVK>Так что значимость проблемы ты сильно преувеличиваешь.
В С++ аналогично, один и тот же метод, который виден как экспортируемый из DLL, во внутренних вызовах инлайнится на раз. Поэтому проблема организовать точку входа для вызова ф-ии не стоит вообще. Другое дело, и во всех мануалах по работе оптимизаторов MSVC и gcc говорится, что любой экспортируемый из библиотеки символ сразу ограничивает кол-во приемов оптимизации вокруг этого символа. И далее по зависимостями оптимизация обрубается тоже, например, ф-ия должна возвращать какие-то данные, и вот эти уже данные должны быть в том виде, в котором они размечены в исходном коде. Так в дотнете, вообще все ф-ии экспортируемые с этой т.з. зрения, т.е. согласно тех же гайдов по оптимизации программ, заведомо делают невозможными подавляющую часть приемов оптимизатора.
Могу еще привести пример: есть такой популярный прием в С++, исходящий из того, что все объекты C++ с т.з. дотнета могут быть как value-type, так и ref-type. Есть некий объект, хранящий некое свое состояние в куче, например, рекурсивный фильтр, и в нем 4-8 вещественных полей. Данные ВСЕГДА подаются пачками, хоть интерфейс фильтра может, например, принимать по 1-му отсчету, не суть. Так вот, имея такой объект на куче, можно непосредственно подать ему пачку данных для обработки, просто вызывая методы объекта, а можно скопировать объект на стек, подать пачку данных и потом скопировать обратно. Разница в быстродействии, в зависимости от числа отсчетов в пачке 3-12 раз в пользу второго варианта, а это уже ого! Там просто разный код, даже если на 100% заинлайненый, он все-равно разный для обоих случаев. Первый работает с памятью через this, во втором участвуют только SSE регистры процесора, и нет никакого объекта на стеке. Так вот, для дотнета этот фокус не работает. И это я привел вырожденный случай, когда даже для дотнета не надо обеспечивать доступ через рефлексию.
V>> Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.
AVK>Тем не менее современный CLR умеет и межсборочную оптимизацию делать. Например, инлайнинг методов из другой сборки. Слабо компилятору С++ заинлайнить метод из другой dll?
Не люблю я слово "демагогия", но тут натуральное передергивание. Из статической библиотеки без проблем, и ты это знаешь. Так же как знаешь, что дотнетные динамические библиотеки не обладают св-вами нейтивных dll (только если не в GAC-е предкомпиленные и тоже уже нативные), ибо сколько процессов эту дотнетную dll загрузит, столько копий прошедших JIT ф-ий/методов будет, в то время как в нейтиве сообща используется уже готовый для исполнения нейтивный код, без перекомпиляции. Наверно поэтому в DLL обычно кладут такую ф-сть, которая дороже затрат на вызов, правда? А обертки и прочие кандидаты на инлайн поставляют в статических либах. Ну и еще полно либ, которые даже не статические, а идут исключительно как h-файлы. Например, объектная обертка над GDI+. Вообще прелесть, не надо загромождать клиентский комп лишними dll, из которых потом надо еще что-то инлайнить при запуске.
Здравствуйте, vdimas, Вы писали:
V>Ну это, как раз, не страшно. В С++ это от рождения и не мешает.
В C++ вообще нет стандартного анализируемого стектрейса, потому и не мешает.
V> Тебе же не надо обеспечивать доступ к произвольной ячейке стека через рефлексию
Что ты понимаешь под "доступ к произвольной ячейке стека"? Возможность анализа стектрейса в дотнете встроена.
V>Могу еще привести пример: есть такой популярный прием в С++, исходящий из того, что все объекты C++ с т.з. дотнета могут быть как value-type, так и ref-type. Есть некий объект, хранящий некое свое состояние в куче, например, рекурсивный фильтр, и в нем 4-8 вещественных полей. Данные ВСЕГДА подаются пачками, хоть интерфейс фильтра может, например, принимать по 1-му отсчету, не суть. Так вот, имея такой объект на куче, можно непосредственно подать ему пачку данных для обработки, просто вызывая методы объекта, а можно скопировать объект на стек, подать пачку данных и потом скопировать обратно.
Это одна из разновидностей escape-анализа и она вполне доступна для JIT. В дотнете с этим пока никто не ковырялся, а вот в джаве, где вообще нет value-типов, это одно из основных направлений развития оптимизатора.
V>Так вот, для дотнета этот фокус не работает.
Вполне работает.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
V>>Так вот, для дотнета этот фокус не работает.
AVK>Вполне работает.
Теоретически работает? Дык и я на конкретно этом сценарии настаиваю, что при условии локальности зависимостей должно работать... но времени со 2-го дотнета прошло слишком много, а телодвижений не вижу... этих вещей я давно жду (последние годы со скептисом), у меня и на нейтиве почти половина загрузки проца, а на дотнете аналогичное даже не взлетает.
Здравствуйте, Cyberax, Вы писали:
P>>Тогда MODULA-2. C>В чём отличие конского навоза от свиного?
С вопросами о навозе, скорее к зоотехнику или ветеринару.
Ты просил язык с определенными условиями. Тебе предложили вариант. Ты по ходу дела условия уточнил. Тебе предложили еще вариант. Мы же не обсуждаем языки. То чого ж ти репетуєш? (c) Кстати, мою точку зрения по этому вопросу можно найти в теме про синтаксический оверхед и некоторых других.
А еще навскидку только Ада всплывает с обозначенными тобой свойствами.
Здравствуйте, vdimas, Вы писали:
AVK>>Вполне работает.
V>Теоретически работает?
Теоретически. Но ты ж за фундаментальное ограничение это выдавал.
V> Дык и я на конкретно этом сценарии настаиваю, что при условии локальности зависимостей должно работать... но времени со 2-го дотнета прошло слишком много, а телодвижений не вижу...
А ты смотрел? Навскидку — основные изменения в 4 рантайме?
V> этих вещей я давно жду (последние годы со скептисом), у меня и на нейтиве почти половина загрузки проца, а на дотнете аналогичное даже не взлетает.
Многие оптимизации можно сделать руками. В т.ч. с передвиганием в стек и обратно. Их отсутствие — никак не show stopper.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
ГВ>>Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал. S>Но при этом почему-то считаешь их "мифическими". S>Занятная мифическость получается: в компаниях с высокой культурой разработки и значительными инвестициями в отлов и починку этих мифических зверей их извести никак не могут. Наверное, зато, в наколенных поделках самоучек эти зверьки совсем-совсем не встречаются.
Хорошо, хорошо, признаю, что сравнение выбрано неудачно и аллегория применена не вовремя. Не стоило сравнивать с "мифическими зверьками". Это на самом деле была аллюзия на одну очень давнюю дискуссию, ещё с участием eao197, если не ошибаюсь.
ГВ>>Эти факторы как раз и влияют на "дурь" с тестированием. S>А-а. Ну то есть несмотря на то, что МС уже лет пять как делает "quality-based releases" и отказывается называть заранее даты выхода продуктов, чтобы избежать проблем типа "не успеваем к релизу — давайте скипнем тестирование", и вкладывает чудовищные деньги в тестирование и верификацию своих неуправляемых программ, систематически получает проблемы. S>Если у них дурь с тестированием, то остальные, скажем так, вообще никаким QA не занимаются.
Я не знаю, как у них там всё на самом деле обстоит. Ну и потом, тестирование — это только часть QA.
S>Каким же тогда образом мы можем полагаться на надёжность программ на C++?
Что значит "полагаться"? Отказать может любое ПО, тем более — плохо проверенное перед выпуском, в т.ч. и на managed-языках. Фактически же, можно полагаться на ПО или нет показывает только продолжительная реальная эксплуатация, а не технология реализации. Не будет ошибок "прохода по памяти", так будут дыры в спецификациях более высокого уровня и будет выпускаться полностью верифицированное дырявое ПО (hole guaranteed!). Короче говоря, не надо ставить лошадь позади телеги.
ГВ>>Скорее — изменение предмета обсуждения. ГВ>>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. S>С чего бы это вдруг? Нет, я буду агитировать за взвешенный подход. S>Менеджед вовсе не означает гарантированного увеличения ресурсопотребления. Да, сборка мусора требовательнее к памяти, чем обычное выделение. Это не означает, что нельзя сочетать оба подхода. Более того, в высокопроизводительных серверных приложениях так и делают — выделяют часть памяти "статически". И таки память сейчас значительно менее ресурс, чем даже во времена начала дотнета. S>Для роста затрат остальных ресурсов объективных причин нет.
Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия?
Что-то мне всё это напоминает того же "мифического зверька", только другой породы. Только один лагерь объявляет мифами утечки памяти, а другой — перерасход ресурсов.
ГВ>>Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку. S>Угу. Вот только пока что основные результаты в компайл-тайм верификации достигнуты как раз для управляемого мира. А так как я целиком за статическую верификацию, то, естественно, моё мнение склоняется в управляемую сторону.
Ясно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
V>>А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ? S>Действительно. В таких задачах, как хорошо известно, рулит Эрланг — практически интерпретатор, полностью управляемый. Дотнет слишком низкоуровневый для таких задач.
Ну вопрос в том, что подразумевать под "рулит", вон довольно известный эрлангер Валкин в где-то похожей задаче заменяет эрланг на СИ. Всё относительно, как обычно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, хорошо, признаю, что сравнение выбрано неудачно и аллегория применена не вовремя. Не стоило сравнивать с "мифическими зверьками". Это на самом деле была аллюзия на одну очень давнюю дискуссию, ещё с участием eao197, если не ошибаюсь.
Ок. S>>Для роста затрат остальных ресурсов объективных причин нет.
ГВ>Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия?
Это откуда такие дровишки? Можно поподробнее рассказать об этих "постоянных проверках"?
Менеджед — это тот, кто предоставляет о себе достаточно информации. Например, в MSIL у нас есть полная информация о типах и их совместимости. Некоторые ограничения дают нам гарантии сбалансированности managed-стека, и того, что для каждой операции с этим стеком мы заранее точно знаем типы аргументов. Это позволяет верификатору гарантировать типобезопасность. При этом никаких "постоянных проверок" в результирующем коде нет. Потому что эти гарантии верифицируются статически.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия? S>Это откуда такие дровишки? Можно поподробнее рассказать об этих "постоянных проверках"?
Хм. А GC разве не занимается регулярными проверками состояния памяти?
S>Менеджед — это тот, кто предоставляет о себе достаточно информации. Например, в MSIL у нас есть полная информация о типах и их совместимости. Некоторые ограничения дают нам гарантии сбалансированности managed-стека, и того, что для каждой операции с этим стеком мы заранее точно знаем типы аргументов. Это позволяет верификатору гарантировать типобезопасность. При этом никаких "постоянных проверок" в результирующем коде нет. Потому что эти гарантии верифицируются статически.
Это немного другое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
V>>Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная. S>OMG. OMG!
Хех. Закинуть, что ли, эту подборку в официальную рассылку?
ГВ>Хм. А GC разве не занимается регулярными проверками состояния памяти?
в managed есть лишь лишние проверки при доступе к массиву.
Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Здравствуйте, Sinclair, Вы писали:
S>1. Затраты на GC зависят от количества живых объектов. Поэтому, если вы много работаете с короткоживущими объектами, то затраты на GC могут оказаться не выше, а то и ниже, чем альтернативные затраты на явное выделение/освобождение памяти в традиционных менеджерах памяти.
"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит.
S>2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию
"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>>Хм. А GC разве не занимается регулярными проверками состояния памяти?
DG>в managed есть лишь лишние проверки при доступе к массиву. DG>Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Ну, доли или не доли, трудно сказать. Вот такой вот простой код:
static void assign(long[] arr, int index, int val)
{
arr[index] = val;
}
/////const int ArrSize = 50000;
long[] arr = new long[ArrSize];
var dt = DateTime.Now; // Засечка 1for (int j = 0; j < ArrSize; ++j)
for (int i = 0; i < ArrSize; ++i)
{
assign(arr, i, i*j);
}
var dte = DateTime.Now; // Засечка 2
Всё равно умудряется работать где-то на 5-7% медленнее C++-ного аналога (если хочешь, скину полные примеры). Хотя там JIT и инлайн делает, и лишние проверки выкидывает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.
Я знаю, что полно, но ты сам что именно посоветуешь?
G>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает.
По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит.
G>3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее.
OK. Про использование защищённых страниц я не знал (разве что краем уха слышал).
G>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.
И в чём выражаются такие нарушения?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, DarkGray, Вы писали:
ГВ>Ну, доли или не доли, трудно сказать. Вот такой вот простой код:
ГВ>
ГВ>const int ArrSize = 50000;
ГВ>long[] arr = new long[ArrSize];
ГВ>var dt = DateTime.Now; // Засечка 1
ГВ>for (int j = 0; j < ArrSize; ++j)
ГВ> for (int i = 0; i < ArrSize; ++i)
ГВ>
ГВ>Всё равно умудряется работать где-то на 5-7% медленнее C++-ного аналога (если хочешь, скину полные примеры). Хотя там JIT и инлайн делает, и лишние проверки выкидывает.
а если
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает.
ГВ>По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит.
Когда кончается не вся доступная память, а память в специальной арене для выделения (256Kb afair). Когда кончается эта арена — все на что есть ссылки выносится в первое поколение, указатель свободного места переносится на начало арены.
G>>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.
ГВ>И в чём выражаются такие нарушения?
фиксят указатели в unsafe. Наверное об этом...
Здравствуйте, samius, Вы писали:
ГВ>>Всё равно умудряется работать где-то на 5-7% медленнее C++-ного аналога (если хочешь, скину полные примеры). Хотя там JIT и инлайн делает, и лишние проверки выкидывает. S>а если S>
S>i < arr.Length
S>
S>?
Тогда скорость C# падает примерно в полтора раза.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
G>>>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает. ГВ>>По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит. S>Когда кончается не вся доступная память, а память в специальной арене для выделения (256Kb afair). Когда кончается эта арена — все на что есть ссылки выносится в первое поколение, указатель свободного места переносится на начало арены.
Вот мне и интересно как раз, каков будет консенсус вокруг "нехватки памяти".
G>>>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.
ГВ>>И в чём выражаются такие нарушения? S>фиксят указатели в unsafe. Наверное об этом...
Да нет, это слишком мрачно. Скорее всего, речь идёт о том, что долгоживущие объекты создают короткоживущие и размещают у себя ссылки на них, и поэтому приходится часто анализировать память, отнесённую к старшим поколениям. Длина анализируемого графаф увеличивается и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, samius, Вы писали:
ГВ>>>Всё равно умудряется работать где-то на 5-7% медленнее C++-ного аналога (если хочешь, скину полные примеры). Хотя там JIT и инлайн делает, и лишние проверки выкидывает. S>>а если S>>
S>>i < arr.Length
S>>
S>>?
ГВ>Тогда скорость C# падает примерно в полтора раза.
Где-то читал что оптимизируется именно вариант с проверкой array.Length, и что не нужно создавать переменную под это...
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, samius, Вы писали:
G>>>>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает. ГВ>>>По такой логике, любая программа на .Net должна для начала выедать всю доступную память, чего на практике обычно не происходит. S>>Когда кончается не вся доступная память, а память в специальной арене для выделения (256Kb afair). Когда кончается эта арена — все на что есть ссылки выносится в первое поколение, указатель свободного места переносится на начало арены.
ГВ>Вот мне и интересно как раз, каков будет консенсус вокруг "нехватки памяти".
Консенсус у кого c кем? Уверен, что gandjustas просто не уточнил, где именно не хватит памяти и какой именно памяти и спорить мы с ним по этому поводу не будем. Да и такой спор легко разрешился бы, делов-то дойти до шкафа с Рихтером и стряхнуть пыль с него.
ГВ>>>И в чём выражаются такие нарушения? S>>фиксят указатели в unsafe. Наверное об этом...
ГВ>Да нет, это слишком мрачно. Скорее всего, речь идёт о том, что долгоживущие объекты создают короткоживущие и размещают у себя ссылки на них, и поэтому приходится часто анализировать память, отнесённую к старшим поколениям. Длина анализируемого графаф увеличивается и т.п.
Вот этот сценарий — слишком мрачный. Думаю, что даже старички дотнетчики не заботятся о таких вещах.
Здравствуйте, samius, Вы писали:
ГВ>>>>Всё равно умудряется работать где-то на 5-7% медленнее C++-ного аналога (если хочешь, скину полные примеры). Хотя там JIT и инлайн делает, и лишние проверки выкидывает. S>>>а если S>>>
S>>>i < arr.Length
S>>>
S>>>?
ГВ>>Тогда скорость C# падает примерно в полтора раза. S>Где-то читал что оптимизируется именно вариант с проверкой array.Length, и что не нужно создавать переменную под это...
Да, так и есть. Вот такие варианты работают одинаково:
for (int j = 0, je = arr.Length; j < je; ++j)
for (int i = 0, ie = arr.Length; i < ie; ++i)
и
for (int j = 0; j < arr.Length; ++j)
for (int i = 0; i < arr.Length; ++i)
И они оба сильно отстают от:
for (int j = 0; j < ArrSize; ++j)
for (int i = 0; i < ArrSize; ++i)
Хотя массив создаётся в той же функции и казалось бы, можно определить константную длину.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
ГВ>>Вот мне и интересно как раз, каков будет консенсус вокруг "нехватки памяти". S>Консенсус у кого c кем? Уверен, что gandjustas просто не уточнил, где именно не хватит памяти и какой именно памяти и спорить мы с ним по этому поводу не будем. Да и такой спор легко разрешился бы, делов-то дойти до шкафа с Рихтером и стряхнуть пыль с него.
Я думаю, что оптимальный вариант — чтобы автор сам поправил ошибочные высказывания. Во избежание разночтений.
ГВ>>>>И в чём выражаются такие нарушения? S>>>фиксят указатели в unsafe. Наверное об этом... ГВ>>Да нет, это слишком мрачно. Скорее всего, речь идёт о том, что долгоживущие объекты создают короткоживущие и размещают у себя ссылки на них, и поэтому приходится часто анализировать память, отнесённую к старшим поколениям. Длина анализируемого графаф увеличивается и т.п. S>Вот этот сценарий — слишком мрачный. Думаю, что даже старички дотнетчики не заботятся о таких вещах.
Так именно такой сценарий и следует из слов gandjustas. И в принципе, он имеет право на существование.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, samius, Вы писали:
S>>>>фиксят указатели в unsafe. Наверное об этом... ГВ>>>Да нет, это слишком мрачно. Скорее всего, речь идёт о том, что долгоживущие объекты создают короткоживущие и размещают у себя ссылки на них, и поэтому приходится часто анализировать память, отнесённую к старшим поколениям. Длина анализируемого графаф увеличивается и т.п. S>>Вот этот сценарий — слишком мрачный. Думаю, что даже старички дотнетчики не заботятся о таких вещах.
ГВ>Так именно такой сценарий и следует из слов gandjustas. И в принципе, он имеет право на существование.
Право имеет, но вряд ли такой сценарий в большей мере относится именно к программистам C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи.
В Java пулы используются для работы с объектами, создание которых действительно дорого. К примеру, потоками или соединениями с БД.
Основная проблема в пуловых объектах в том, что их мутация заметно дороже мутации объектов из нового поколения.
Здравствуйте, Cyberax, Вы писали:
ГВ>>Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи. C>В Java пулы используются для работы с объектами, создание которых действительно дорого. К примеру, потоками или соединениями с БД.
C>Основная проблема в пуловых объектах в том, что их мутация заметно дороже мутации объектов из нового поколения.
В смысле?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>>А в чём тут отрицательное влияние выражается? В миграции ссылки на долгоживущий объект из памяти Gen2 в память Gen0? DG>основной ошибкой будет постоянное изменение ссылок из долгоживущих на короткоживущие. DG>это приведет к тому, что постоянно будет звенеть колокольчик, что произошло изменение страниц памяти с долгоживущими, и что их надо перепроверять при анализе для сборки мусора короткоживущих объектов.
DG>соответственно, если объект просто используется из пула, то это даст ускорение, но если при этом в нем постоянно начинают меняться ссылки на другие объекты, хотя бы на строки, не говоря уже о других более сложные объектах, то может получится что такая оптимизация добавит больше работы gc, чем выиграет от повторного использования.
Ясно. Я как раз примерно об этом сценарии и подумал
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит.
Это любые, где требуются явные операции освобождения памяти.
ГВ>"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав?
Да, неправ. Рекомендую углубленный RTFM на тему.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Продвинутые аллокаторы используют локальные для потоков арены, там блокировка не нужна. S>Тем не менее, независимо от степени продвинутости аллокатора, при убийстве 100к объектов нужно 100к раз вызвать код возврата памяти в кучу.
Совершенно не обязательно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И они оба сильно отстают от:
ГВ>
ГВ>for (int j = 0; j < ArrSize; ++j)
ГВ> for (int i = 0; i < ArrSize; ++i)
ГВ>
В релизе? Не из-под студии?
Очень, очень странно. Опубликуй, пожалуйста, программу — студии под рукой нет.
И, да, выкинь нахрен DateTime. Пользуйся System.Threading.Timer. ГВ>Хотя массив создаётся в той же функции и казалось бы, можно определить константную длину.
К месту создания массива это отношения не имеет. Ресайза массивов в дотнете нет, поэтому можно закладываться на постоянство arr.Length в любом случае.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ГВ>Операции освобождения памяти требуются не менеджерами памяти, а программой, которая эти менеджеры использует. Можно грохнуть весь менеджер, ни разу не выполняя промежуточный delete.
Скажем более общо: вызов операций удаления объектов определяется политикой управления памятью, которая, в свою очередь зависит от выбранной архитектуры, от задач приложения и кучи других соображений. Часть приложения может работать под одной политикой, часть под другой, часть — под третьей...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет?
Я не согласен называть построение графа живых объектов "проверкой состояния памяти". На состояние памяти GC совершенно наплевать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>>>Хм. Написать что-ли статический проверяльщик, который ровно это делает?.. M>>Напиши Но ИМХО это пока из области научной фантастики. C>Почему? Просто достаточно запретить все небезопасные обращения. Т.е. доступ к вектору/строчке — только по at() и т.п.
Это рантаймовые проверки. То есть просадка производительности.
C>С арифметикой указателей только аккуратно надо будет, особенно с итераторами.
Ага. Вот например std::copy на итераторах. Как там проверить, что в приёмнике места достаточно? Только если заменить итераторы на диапазоны и добавить рантаймовые проверки. То есть просадка производительности. Да и с диапазонами легко накосячить, поскольку они всё равно на итераторах, которые могут инвалидироваться.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет? S>Я не согласен называть построение графа живых объектов "проверкой состояния памяти". На состояние памяти GC совершенно наплевать.
Хорошо, пусть это будет "анализ состояния памяти". Хотя большой разницы нет: проанализировать и принять решение на основании анализа, считай, то же самое, что и: "проверить и принять решение на основании результата проверки". Разница в оттенках.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Совершенно не обязательно. S>В тех случаях, когда это необязательно, и GC вызывать тоже необязательно.
Я бы не стал обобщать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Как тут поможет Timer?
DateTime катастрофически неточен.
ГВ>Код под катом.
Предлагаю следующее простое изменение:
using System;
namespace ArrayOnly
{
class Program
{
const int ArrSize = 50000;
const int IterCount = 5;
static void testFunc2()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0; j < ArrSize; ++j)
for (int i = 0; i < arr.Length; ++i)
{
arr[i]= i * j * c;
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0; i < arr.Length; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void testFunc1()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0, j < ArrSize; ++j)
for (int i = 0, ie = arr.Length; i < ie; ++i)
{
arr[i]= i * j * c;
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0, ie = arr.Length; i < ie; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void testFunc()
{
var arr = new long[ArrSize];
var dt = DateTime.Now;
for (int c = 0; c < IterCount; ++c)
for (int j = 0; j < ArrSize; ++j)
for (int i = 0; i < ArrSize; ++i)
{
arr[i]= i * j * c;
}
var dte = DateTime.Now;
Console.WriteLine("C# for (int i = 0; i < ArrSize; ++i): {0} ms", (dte - dt).TotalMilliseconds / IterCount);
}
static void Main(string[] args)
{
testFunc();
testFunc1();
testFunc2();
System.Console.WriteLine("Press Enter to exit...");
System.Console.ReadLine();
}
}
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Скажем более общо: вызов операций удаления объектов определяется политикой управления памятью, которая, в свою очередь зависит от выбранной архитектуры, от задач приложения и кучи других соображений. Часть приложения может работать под одной политикой, часть под другой, часть — под третьей... S>Все эти песни мы уже слышали в 1996 году, при появлении Java. S>На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++. S>Не говоря уже о том, чтобы заниматься поддержкой множества политик управления памятью в пределах одного приложения.
Ну что ж, спасибо за комплимент. Надо сказать, весьма неожиданно для этого форума.
S>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
Не сомневаюсь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Я бы не стал обобщать. S>Однако уже обобщаешь.
Возможно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А... Ну это-то я как раз читал. Ну, всё равно спасибо.
Пишешь так как-будто не читал.
ГВ>По умолчанию мы считаем, что рассматривается вся доступная процессу память.
Нет, так не считаем. Если заканчивается вся доступная память то уже поздно что-то делать.
G>>>>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#. ГВ>>>И в чём выражаются такие нарушения? G>>Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
ГВ>А в чём тут отрицательное влияние выражается? В миграции ссылки на долгоживущий объект из памяти Gen2 в память Gen0?
1)Перемещение объектов в Gen2 — дополнительные затраты
2) долгоживущие объекты вызывают более частую и затратную сбоку мусора.
ГВ>Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи.
Если объекты "тяжелые", то такой подход оправдан. Но сама операция выделения памяти в managed очень быстрая (по сути interlocked increment), затраты вносит сборка мусора которая зависит от количества живых объектов. Это значит что чем меньше остается живых перед сборкой мусора — тем лучше.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Код под катом. S>Предлагаю следующее простое изменение:
Если все циклы по i заменить на:
for (int i = 0; i < ArrSize; ++i)
А циклы по j привести к первоначальному виду, то время для всех трёх вариантов станет одинаковым: ~885 мс.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
ГВ>>А... Ну это-то я как раз читал. Ну, всё равно спасибо. G>Пишешь так как-будто не читал.
Я не так много работаю с .Net, чтобы нужно помнить детали работы GC. А уж в эффектах — так и вообще путаюсь, вычисляю их сугубо логически по ходу дискуссии.
ГВ>>По умолчанию мы считаем, что рассматривается вся доступная процессу память. G>Нет, так не считаем. Если заканчивается вся доступная память то уже поздно что-то делать.
O'K
Про остальное — я понял твою точку зрения. Пока что мне тут добавить нечего.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>А циклы по j привести к первоначальному виду, то время для всех трёх вариантов станет одинаковым: ~885 мс.
Здесь самое любопытное явление — снижение производительности варианта, использующего только сравнение с константами (885 vs. 1065, т.е. ~17%). Либо JIT делает какие-то слишком далеко идущие предположения, либо... Дальше мысль останавливается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи.
G>Если объекты "тяжелые", то такой подход оправдан. Но сама операция выделения памяти в managed очень быстрая (по сути interlocked increment), затраты вносит сборка мусора которая зависит от количества живых объектов. Это значит что чем меньше остается живых перед сборкой мусора — тем лучше.
Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0:
Выделение памяти без синхронизации
В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
Здравствуйте, gandjustas, Вы писали:
G>для начала long в C++ и long в C# — не одно и то же.
Я это знаю, поэтому в C++-варианте используется long long. Выбрано ради 8-байтовой длины, чтобы на x64 поменьше неожиданностей было.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
ГВ>>Хорошо, пусть это будет "анализ состояния памяти". Хотя большой разницы нет: проанализировать и принять решение на основании анализа, считай, то же самое, что и: "проверить и принять решение на основании результата проверки". Разница в оттенках. S>Нет никакого "решения", нет никакого "анализа". S>Есть процедура "спасение живых объектов". Нет процедуры "удаление мёртвых объектов". S>В классическом менеджере памяти нет процедуры "спасение живых объектов", зато есть процедура "удаление мёртвых объектов". S>Этих несложных соображений пытливому уму должно быть достаточно для того, чтобы прикинуть, где должна пролегать граница между "GC эффективнее" и "классика эффективнее".
Пытливый ум при этом задаст ещё один вопрос: а что делать потом с фрагментированной свободной памятью? При этом граница эффективности как-то размывается...
S>И уж тем более достаточно для того, чтобы навсегда отказаться от заблуждений вроде "классика всегда эффективнее".
Хр-р-р пс-пс-пс... Хр-р-р пс-пс-пс...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Пытливый ум при этом задаст ещё один вопрос: а что делать потом с фрагментированной свободной памятью? При этом граница эффективности как-то размывается...
Совершенно верно. Фрагментация свободной памяти, которой подвержены классические менеджеры памяти — это ещё один аргумент в пользу GC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Отличие лишь в том, что стек трейс виден детальный, т.е. быстрее можно найти ошибку (если она не та самая наведенная )
Это точно, еще как быстрее.
И ты за всем пустословием упустил самое главное. В управляемом коде надо еще постараться, чтобы получить наведенную ошибку. А в С++ надо очень постараться, чтобы их не получить.
Здравствуйте, Klatu, Вы писали:
V>>Отличие лишь в том, что стек трейс виден детальный, т.е. быстрее можно найти ошибку (если она не та самая наведенная ) K>Это точно, еще как быстрее. K>И ты за всем пустословием упустил самое главное. В управляемом коде надо еще постараться, чтобы получить наведенную ошибку. А в С++ надо очень постараться, чтобы их не получить.
Ты снова говоришь только об ошибках, наведённых неправильной работой с памятью, или на этот раз имеешь в виду все наведённые ошибки?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Ну и потом, это не только из unmanaged, такой же подход используется в Java. Собственно, пулы хорошо решают задачу снижения издержек конструирования объектов, распределение памяти — только часть этой задачи.
G>>Если объекты "тяжелые", то такой подход оправдан. Но сама операция выделения памяти в managed очень быстрая (по сути interlocked increment), затраты вносит сборка мусора которая зависит от количества живых объектов. Это значит что чем меньше остается живых перед сборкой мусора — тем лучше. S>Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0: S>
S>Выделение памяти без синхронизации
S>В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
Насколько я сылшал серверный GC позволяет параллелить в первую очередь сборку мусора, а не выделение памяти. interlocked increment и так довольно быстр чтобы еще и его пытаться оптимизировать.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Klatu, Вы писали:
K>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
V>Это от технологии не зависит.
Вот тут не уверен. Когда разрабатываешь один продукт, состоящий из разных компонент и когда разные компоненты делают разные отделы, и при этом один компонент портит память другому, то непонятно даже на какой компонент баг вешать. Вот и приходится мне, как продуктовому разработчику, сидеть в windbg и ковыряться в компонентах, к которым я вообще отношения не имею, кто кому портит память, просто чтобы понять, кому вешать баг. Мне что, больше заняться нечем? Вот и думаешь в такие моменты: писали бы все на .NET'e или яве, как бы проще жить было!
Здравствуйте, samius, Вы писали:
ГВ>>Так именно такой сценарий и следует из слов gandjustas. И в принципе, он имеет право на существование. S>Право имеет, но вряд ли такой сценарий в большей мере относится именно к программистам C++.
ХЗ... В С++ короткоживующие объекты, являющиеся полями других объектов, обычно хранятся как value-type (т.е. имеют семантику значений). Перетягивая эту привычку на дотнет я зачастую делаю так же, а не то, что изобретает себе gandjustas.
Здравствуйте, gandjustas, Вы писали:
G>Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
Может, не может... что за гадания на кофейной гуще?
Когда вводят пул объектов, то делают это под постоянным присмотром через результаты тестирования производительности. Я даже боюсь себе представить твою ситуацию "умозрительного" применения пула объекта, т.е. вне процедур по увеличению эффективности кода, со всем тем, что эти процедуры сопровождает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>А в чём? Интересно было бы узнать твоё мнение.
AVK>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.
А почему тогда приложения на плюсах работают быстрее? Там алгоритмы лучше или с дизайном дела как-то иначе обстоят?
Здравствуйте, samius, Вы писали:
S>Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0: S>
S>Выделение памяти без синхронизации
S>В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
Это касается только маленьких объектов. Для больших, по-прежнему пулы показывают оч. высокую эффективность, в сравнении с GC. Например пуллы массивов байт/символов.
Здравствуйте, Cyberax, Вы писали:
C>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью.
D?
Хотя для этого не обязательно новый язык, достаточно рантайма и чуть измененного кодогенератора в компиляторе как
например у гуглевского Native Client.
C>Хм. Написать что-ли статический проверяльщик, который ровно это делает?..
Сомнительно что для С++ получится, разве для ограниченного подмножества.
Здравствуйте, vdimas, Вы писали:
S>>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
V>Нет подобных возможностей.
Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Здравствуйте, konsoletyper, Вы писали:
ГВ>> Первый раз я это услышал от спеца, принёсшего весть не то с конференции MS, не то с какой-то UG в 1997-м: что, мол, "сейчас главное — разрабатывать программы быстро, а то, что форма рисуется не за 200 микросекунд, а за 200 миллисекунд — так кому какая разница!" и тут же: "MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась).
K>Вот уж не знаю, везде ли так, как у меня, или не везде. Но и скорость работы спеца нафиг никому не упёрлась. Я тут со своей эффективностью сижу и жду, когда же бизнес решит, чего он хочет. От нечего делать попиваю чаёк и читаю RSDN. Так что мем зародился именно из-за безалаберности. При желании можно и эффективный код писать быстро. Я понимаю, были бы какие-то сложные алгоритмы, где надо полгода думать, как от вместо O(n*log(n)) перейти к полиномиальной сложности. А тут же формочки с БД! Написание эффективного кода в таких условиях превращается из сложной задачи в банальный навык, зашитый в спинном мозге.
В абсолютном большинстве тех мест, где мне довелось побывать, картина похожая: самые большие тормоза — выделение и формализация задачи, а это скоростью работы программистов никак не лечится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
ГВ>>Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет? V>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд. Сочетание параллельного GC и фонового немного смягчает этот эфект, растягивая сборку поэтапно по времени.
Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно.
Вернее — как. В теории-то оно понятно: если вся работа системы сводится, грубо говоря, к функциональной модели — когда возврат управления из функции означает вычисление value-типа и выбрасывание всех промежуточных результатов, то GC может дать очень приличную скорость. По сути тут GC будет работать не как GC (со всеми его графами, периметрами, маркировками-перемаркировками), а скажем так, по-минимуму: пометил освободившуюся память — и всё. Только на практике функциональный стиль сам по себе не всегда даёт большую скорость, и из-за этого благие представления разбиваются о суровою реальность. Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр.
Собственно, понятно, откуда растут ноги у апологии stateless (были когда-то горячие споры в АПО). Это здесь самая адекватная модель: быстро выполнили запрос, сгенерировали ответ, промежуточные результаты выкинули или повесили в долгоживущий кэш. Ответ ушёл по сети, и значит, промежуточный объект, содержавший результат — тоже выкинули. Чисто, аккуратно, только априори медленно, поскольку вся работа с состоянием вытесняется куда-нибудь аж на сервер БД. Зато .Net стоит весь "в белом": всегда можно сказать, что это SQL-сервер не справляется.
Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Снова неправильно. Фрагментация возникает тогда, когда реализованная в программе политика управления жизненным циклом объектов подразумевает такую фрагментацию. Ещё варианты? I>И много ты знаешь людей, которые способны реализоваь качественную политику управления жизненным циклом объектов ? Из Сиплюсников таких единицы
Ну как тебе сказать. Я знаю довольно много плюсовиков (во всяком случае, совсем не единицы), которые просто не станут реализовывать свои механизмы управления памятью, поскольку имеющихся общедоступных средств вполне достаточно. Хотя это вполне в их силах. Кстати, никаких "качественных" или "некачественных" политик управления памятью не бывает. Они соответствуют либо одним требованиям, либо другим. И собственно говоря, управление памятью почти всегда согласуется с архитектурой приложения, впрочем, это отдельный разговор.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
ГВ>>>Так именно такой сценарий и следует из слов gandjustas. И в принципе, он имеет право на существование. S>>Право имеет, но вряд ли такой сценарий в большей мере относится именно к программистам C++. V>ХЗ... В С++ короткоживующие объекты, являющиеся полями других объектов, обычно хранятся как value-type (т.е. имеют семантику значений). Перетягивая эту привычку на дотнет я зачастую делаю так же, а не то, что изобретает себе gandjustas.
gandjustas, как выяснилось, имел в виду несколько иной сценарий, но тот, о котором говорил я, ИМХО, вполне может проявляться. Знаешь же эти размашистые ёлки Больших Объектов™, которые хранят состояния, промежуточыне результаты...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Marty, Вы писали:
M>Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++.
Нет, не нужно. Нужно иметь немного другую квалификацию, и сравнить это не так просто.
M>По крайней мере, .NET уже сколько существует, а приложений все нет и нет.
Каких таких приложений нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, A13x, Вы писали:
ГВ>>... В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать. A>Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
Понятно, что в некоторых случаях Java может работать лучше C, только все-то программы к этим отдельным случаям не сведёшь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Marty, Вы писали:
M>Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++. M>По крайней мере, .NET уже сколько существует, а приложений все нет и нет. Единственное приличное, что могу вспомнить, это Paint.NET, все остальное встреченное было, как правило, УГ
Всё сильно зависит от того, какого типа приложения вас интересуют. Скажем, Outlook Web Access — одно из лучших веб-приложений, которые я когда-либо видел. Сделать такое на С++, имхо, просто нереально.
Сделать аналог шарепоинта (который хоть и глючный, но всё же) — тоже.
А на десктопе — да, тут всё как-то неинтересно до сих пор. Не вполне понимаю, почему.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А на десктопе — да, тут всё как-то неинтересно до сих пор. Не вполне понимаю, почему.
Потребляемые ресурсы, необходимость тащить FW, невнятная политика MS в отношении GUI. На сервере эти проблемы не так актуальны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд.
Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно.
Ес-но не бесплатно, но оказалось в тему для неравномерных нагрузок. Тут говорили, что GC запускается только тогда, когда памяти не хватает — это малость не так (вернее, не только так), по крайней мере с тех пор, как в ход пошел фоновый GC, потому как шедуллер GC ориентируется еще на счетчики производительности. В этом случае GC поможет выровнять, например, нагрузку на сервер.
ГВ>Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр.
Да, но тоже неплохо работает в фоне.
ГВ>Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
Ну... для таких задач в дотнете полно еще помех, помимо GC. Например, в C++ мы куски памяти непосредственно можем интерпретировать, в дотнете в safe-режиме это невозможно, а зачитка нативной памяти (десериализация) как показывают замеры — вещь очень и очень постепенная.
По большому счету меня сам байт-код не смущает. Его можно рассматривать как YA формат объектного файла и способ распространения программ. На CLR/C++ уже сейчас вполне можно генерить переносимые программы полностью в терминах байткода, используя как unsafe и ручное управление памятью где надо и safe где и так сойдет. Библиотек полно под любой чих, опять же. В моих экспериментах по однопоточному локальному эмулированию GC handle у меня в 3-4 раза выходило быстрее получать соответствие объектов unsafe->safe, чем через стандартные ср-ва, т.е. бороться с острыми моментами можно. Загвоздка, как постоянно говорю, лишь в большой разнице кач-ва генерируемого кода компилятором C++ перед JIT или ngen, а с этим бороться никак.
Здравствуйте, Ikemefula, Вы писали:
I>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Не преувеличивай, есть всего 2 основных способа, относящихся конкретно к дотнету:
— это создание относительно "больших" value-type, специально быть приватными полями других объектов.
— хранение таких же value-type в массивах.
Оба способа требуют пересмотра внутреннего интерфейса, понятное дело. Твой ref нужен вовсе не всегда, это зависит от того, где ты разместишь функциональность, и какую зависимость ей назначишь — от всего объемлющего value-type, или от его маленькой запчасти, которой по значению будет эффективней оперировать. Далее, константные объекты (иммутабельные), или еще забытое тобой, но не менее важное уменьшение уровня косвенности данных — это не специфично для дотнета, а общая практика. Разумеется, использование в дотнете повсюду value-type тоже снижает уровень косвенности, но этого недостаточно, если уж вылизывать. Сами принципы отношения объектов м/у собой, объектов и данных, и т.д. приходится пересматривать.
Имеющийся неприятный момент еще в том, что в официальных гайдлайнах, если не изменяет склероз, рекомендуют исполнять типы как value-type, если их размер не превышает 16 байт... Несусветнейшая чушь, ИМХО, которую оппоннеты часто используют как возражение (ведь оно идет аж от самого MS). На самом деле, можно подобрать сценарий, где и 16-байтовый тип лучше сделать ref, или наоборот, подобрать такой, где 256-байтовый объект будет в виде value-type самым эффективным решением.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
V>Может, не может... что за гадания на кофейной гуще?
V>Когда вводят пул объектов, то делают это под постоянным присмотром через результаты тестирования производительности. Я даже боюсь себе представить твою ситуацию "умозрительного" применения пула объекта, т.е. вне процедур по увеличению эффективности кода, со всем тем, что эти процедуры сопровождает.
Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
V>>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд.
AVK>Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть.
Плодить домены, разве что... Похоже, это единственный способ масштабировать дотнетные приложения на сейчас.
Здравствуйте, A13x, Вы писали:
A>Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
А можно ссылку на посмотреть? А то первый раз вижу упоминание, что Java делает C не на задачах, требующих активного выделения памяти.
Здравствуйте, Ikemefula, Вы писали:
S>>>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью. V>>Нет подобных возможностей.
I>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно.
Вот любишь же ты этим своим "качественно" цокать по поводу и без. Неужели GC способен что-нибудь потерять?
I>Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Сочувствую, без шуток. Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
V>Если ты это на своей работе видел, то у вас бардак, поздравляю.
Да именно бардак и был. Набирали программиостов на .NET проект, когда .NET программистов в нашем городе еще не было. Тупо брали тех кто на плюсах пишет и переучивали под .NET. Много чего насмотрелся тогда.
V>Похоже, работа над эффективностью смешивается с разработкой функционала. ИМХО, конкретно технология пулов — это настолько изолированная штука... которую можно прикручивать и откручивать, не трогая ничего вокруг, что я плохо себе представляю работать над полезным функционалом одновременно прикручивая/отлаживая пул объектов... Если они и на плюсах так писали, то конкретно плюсы тут уж точно не при чем. Это классичесский бардак и хаос в махровой стадии, который всегда бывает в отсутствии регулярного взаимного ревью кода. (даже у опытных разработчиков, угу)
Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
Здравствуйте, vdimas, Вы писали:
AVK>>Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть. V>Плодить домены, разве что...
Нет, не использовать развесистые графы, активнее использовать immutable объекты и т.п.
V> Похоже, это единственный способ масштабировать дотнетные приложения на сейчас.
Ну, у кого то может и так.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
G>Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
Угу, вот так взять свалить в одну кучу приемы, которые ничего не стоят, и которые просто правила хорошего тона и способы улучшения типобезопасности времени компиляции, с теми, которые требуют анализа, заметных трудозатрат и даже отладки. Круто.
Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
Был Evernote 3.5 написанный на WPF и заметно более тормозной чем нативные 3.1 и 4.0.
ГВ>"MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась).
для ПО, которое поддерживается напрямую разработчиками, я наблюдаю — что цикл 1-2 месяца — это нормально.
и это позволяет такому ПО быстро взлетать и занимать свою нишу.
сейчас только у коробок большой цикл — год-два, но там это больше связано с особенностями психологии покупателей.
ГВ>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
Смещать лучше туда, где риски меньше (добиваться в первую очередь необходимо оптимальности по тому параметру, за который больше карают при отличии от идеала).
От того что, например, программа в среднем на 5-10% тормознее и пусть даже в отдельные моменты тормозит в 10 раз больше — это для использования некритично.
но если программа в среднем имеет на 5-10% больше ошибок и в отдельные моменты в 10 раз больше — это уже пользователю критично.
соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Здравствуйте, DarkGray, Вы писали:
ГВ>>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
DG>Смещать лучше туда, где риски меньше (добиваться в первую очередь необходимо оптимальности по тому параметру, за который больше карают при отличии от идеала).
Батарейка. Perf/Watt.
DG>От того что, например, программа в среднем на 5-10% тормознее и пусть даже в отдельные моменты тормозит в 10 раз больше — это для использования некритично.
В контексте топика именно это и критично. Твои минус 5-10% скорости, это плюс 5-10% батарейки, вытряхнутые на те же задачи.
DG>но если программа в среднем имеет на 5-10% больше ошибок и в отдельные моменты в 10 раз больше — это уже пользователю критично.
А вот это в данном случае менее важно. Надёжность можно обеспечить и для managed, и для unmanaged. Вполне допускаю, что для unmanaged затраты на этапе разработки будут несколько больше (хотя это далеко не факт), но потом программа будет работать так же надёжно, как и managed, но уже с меньшими затратами ресурсов. Именно на этот момент сейчас и обратили внимание: потребление ресурсов в процессе эксплуатации, а не разработки.
DG>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Что и требовалось доказать. Фактически, ты сейчас согласился с тезисами выступления Саттера, которые я вынес в топикстарт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, kaa.python, Вы писали:
KP>А как кто-то приводит конкретный пример, дотнетовцы сразу говорят что вот уж в данном случае разговор отдельный. Тут должно тормозить, а вот в целом все очень быстро. Очень знакомо
Тебе повоевать захотелось?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
T>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
Еще две очень распространенные в С++ причины стрельбы по памяти — это использование ссылки\указателя на удаленный объект и неинициализированные данные.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mrTwister, Вы писали:
T>>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
FR>От найтив не найтив это мало зависит, например вполне аналог C++ — D от didgitalmars практически свободен от подобных ошибок. FR>Ну или другой пример OCaml или Хаскель тоже вполне найтивны, однако по ошибкоустойчивости дадут фору и шарпу и яве.
Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции.
Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
V>Угу, вот так взять свалить в одну кучу приемы, которые ничего не стоят, и которые просто правила хорошего тона и способы улучшения типобезопасности времени компиляции, с теми, которые требуют анализа, заметных трудозатрат и даже отладки. Круто.
Я же говорю что вживую наблюдал такое, причем не единожды.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, DarkGray, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте.
Если взять программистов той же квалификации и они напишут на C++ такую же программу, то в 99% случаев она будет падать сразу при старте, а в оставшихся 1% иметь учетки памяти и необяснимые ошибки.
V>Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти).
А также утечки памяти. В managed можно вернуть из метода объект и не париться по поводу его времени жизни, в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью.
V>Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти.
Спросил, мне ответили что около пары недель назад.
Проблема почти классическая. Указатель на освобожденный объект, память оказалась затерта другим значением, в цикле это использовалось в качестве границы. Причем сам код цикла не менялся, просто во внешнем коде переставил вызовы функций. Но там древний проект, большая часть код которого была написана практически на С.
Здравствуйте, gandjustas, Вы писали:
G>Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции. G>Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
G>При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
Ну а как на счёт D? ) Кстати, с ocaml всё не совсем так. На счёт хаскеля не знаю — не имел с ним дел. )
Здравствуйте, gandjustas, Вы писали:
G>Если взять программистов той же квалификации и они напишут на C++ такую же программу, то в 99% случаев она будет падать сразу при старте, а в оставшихся 1% иметь учетки памяти и необяснимые ошибки.
А вот здесь вы абсолютно правы. И это и есть основное преимущество явы и C# — возможность достаточно эффективно использовать труд малоквалифицированных программистов и легко заменять их в случае надобности. Это особенно актуально в корпоративном "не компьютерном" секторе. А вот для компаний специализирующихся на разработке софта картина немного другая... Тут уже бывает полезнее держать только высококлассных спецов и благодаря этому делать высококонкурентные продукты. Оба подхода востребованы на рынке — каждому своё...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции. G>>Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
G>>При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
_>Ну а как на счёт D? )
Надо учитывать что native-managed не строгая дихотомия, не который континуум. Есть тн typesafe языки, в которых в принципе нет возможности получить ссылку другого типа на тот же блок памяти, занятый другим объектом, это одна сторона континуума, другая сторона — ассемблер, где управлешь памятью как хочешь. Между ними находится много разных вариантов, причем варианты могут сочетаться даже в одном языке. Вот D один из таких языков, как и C++, только в последнем возможностей меньше.
Но тут есть особенность: для typesafe языков часть проверок можно провести статически, а в рантайме их выкинуть. Для языков где возможны разные варианты safety такой возможности нет надо постоянно выполнять проверки или просто получать проблемы.
_>Кстати, с ocaml всё не совсем так.
Что ты имеешь ввиду? Что он не использует данные о типах? Тогда как он мусор собирает?
Здравствуйте, vdimas, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Я знаю, что сейчас скажут про то, что "многие и не видели никогда": что вот потому и не видели, что эти ошибки невидимы!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mazay, Вы писали:
U>>>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии. C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд. M>Который надо было сделать 7 лет назад.
А C# давно уже надо было сделать телепатически понимающим мысли заказчика.
U>>>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией. C>>И пофиг, зато быстро работает. M>Про переполнение буфера забыли?
А что это?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Klatu, Вы писали:
K>И ты за всем пустословием упустил самое главное. В управляемом коде надо еще постараться, чтобы получить наведенную ошибку. А в С++ надо очень постараться, чтобы их не получить.
Теоретик?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Геннадий Васильев, Вы писали:
S>>На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++. ГВ>Ну что ж, спасибо за комплимент. Надо сказать, весьма неожиданно для этого форума.
Обычно применяемый ими термин скорее оскорбителен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
C>>В чём отличие конского навоза от свиного? BBI>А ты гурман!
Ну в целом, обоих навозов я перекидал тонны. Это гораздо более предпочтительное занятие, чем писать на Модула-2.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хотя, справедливости ради, время от времени чувствую себя, как в башне из слоновой кости: у них там какие-то хождения по памяти при Луне, мегагуры с продвинутыми техниками, которые я считаю тривиальными. Чистая фэнтезятина, ни дать, ни взять.
Аналогичен до безобразия.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
BBI>Это считанные такты в нормальных реализациях.
умножить на 100000. BBI>GC этого же колва объектов будет дороже.
Совершенно верно. Именно поэтому GC неэффективен там, где много объектов выживают.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
_>>Кстати, с ocaml всё не совсем так. G>Что ты имеешь ввиду? Что он не использует данные о типах? Тогда как он мусор собирает?
Использует битовый тег и унифицированные блоки памяти, для того чтобы отличать то что нужно собирать.
Здравствуйте, Sinclair, Вы писали:
S>Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.
S>Добро пожаловать в реальный мир, Нео.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. А ошибки, связанные с нарушениями инвариантов могут быть абсолютно в любом коде — managed, unmanaged, свой, чужой — без разницы.
К сожалению, в сложных проектах, которые делаются более чем одной командой, еще как начинает.
T>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
ГВ>Мои сугубо практические наблюдения говорят о том, что managed в состоянии подкинуть сюрпризы покруче. Чуть пониже расскажу одну историю.
Тоже мне удивил. Именно про твою историю я писал следующее:
Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
ГВ>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так.
Каким образом он их замаскировал?
ГВ>4) Ошибки в unmanaged-коде, действительно, неимоверно сложно искать... В особенности, когда их там нет и ты точно знаешь, что их там нет.
То есть другими словами, работать с unmanaged кодом очень сложно, так как если ты при работе совершишь ошибку (начнешь использовать в несколько потоков, вместо одного), то вылавить эту ошибку будет очень трудно, так как получишь произвольную стрельбу по памяти. Причем в каком коде (managed или unmanaged) ты совершишь ошибку неправильного использования unmanaged кода, в любом случае тубу будет очень весело.
ГВ>Спешу упредить возможные спекуляции: я далёк от рассуждений о чьей-то "низкой квалификации". Автор того managed-кода на самом деле весьма квалифицированный специалист и когда увидел всё это, схватился за голову, но... Не буду вдаваться в подробности, но были вполне объективные исторические причины, чтобы сложилась такая ситуация, да и вообще, настоящий профи должен лично составить полную карту граблей.
Да, это обычная ситуация.
ГВ>В общем, факт остаётся фактом: если бы на хвосте managed не висел сквалыга-unmanaged, ошибку пришлось бы искать гораздо дольше, а то и вообще она проплыла бы мимо.
С чего ты это взял? В твоем случае тебе повезло, что оно просто упало. А ведь могла вместо этого отвалиться совершенно левая функциональность, которая к данному коду вообще не имеет никакого отношения. А так радуйся, что пронесло в этот раз.
ГВ>Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг.
Совершенно верно. При этом самые сложные для поиска баги — это баги, специфичные для С++, а именно проход по памяти, некорректная её интерпретация и пр.
ГВ>В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged.
Легче из-а отсутствия наиболее противных багов и наличия нормальных исключений с callstack'ами и сообщениями.
ГВ>У меня даже закралась крамольная мысль, что атомарность обновления ссылок в управляемом коде — не столь уж однозначно хорошая вещь. С одной стороны — дело благое: ссылка ведь не может указывать в неизвестность, правильно? Она всегда содержит либо null, либо ссылку на корректный объект. Но с другой стороны, если бы ссылки в самом деле "рушились" при несинхронизированном параллельном доступе (или ещё как-то могли быть испорчены, по крайней мере, в каком-нибудь отладочном режиме), искать ошибки было бы легче. Забавный размышлизм, верно? Гарантия корректности ссылок приводит к тому, что в некоторых ситуациях концы в буквальном смысле прячутся в воду — и хорошо, если в этой воде будет сидеть unmanaged, который добавит драйва к этому сонному царству... А иначе программа запросто может пойти в эксплуатацию с очень трудновоспроизводимой плавающей ошибкой. Managed-программа, заметь, будет управляемо и очень честно гнать пургу время от времени. И никаких тебе AVE или подозрительных падений — тишь, гладь, управляемость.
Контракты тебя спасут. В отличии от С++, в котором даже контракты не помогут, так как ничего не стоит эти контракты кому угодно разрушить без твоего ведома.
T>>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
ГВ>Заблуждение. С неимоверной лёгкостью при concurrency-ошибках можно получить совместное владение одним объектом вместо двух, никто и слова худого не скажет. Один объект будет при этом ухлопан, а второй окажется в обоих потоках. И никакого шума, поскольку: а) для обновления ссылок синхронизация не требуется, б) клиент не управляет удалением объекта и там, где unmanaged непременно даст диагностику двойного удаления, managed — стоически промолчит.
Локализованы — это значит, что у тебя не сломается не связанная с этими объектами функциональность. В С++ коде бывает так, что виноват один компонент, а глючит совершенно другой, причем эти два компонента друг с другом вообще никак не связаны кроме того, что находятся в одном процессе. В .NET подобное придумать теоретически тоже можно, но это очень редко. На моей памяти такое было только раз, когда в пул потоков отдавался поток с незакрытым TransactionScope. Но опять таки подобные ошибки ищутся гораздо проще благодаря доступности всех метаданных во время отладки. В частности, благодаря наличию метаданных твоя ошибка ищется очень просто: в windbg ты можешь сдампить все объекты интересующиего тебя типа, посмотреть их количество, и проверить все ссылки, кто на что ссылается. В частности, как только тестировщик видит, что приложение падает (из-за нарушения контракта), либо работает некорректно, то он делает дамп, отдает его тебе, ты видишь, что объектов два вместо одного, кричишь WTF, смотришь на код, который их создает и видишь, что этот код ломается в случае параллельного доступа. Все просто и скучно, никакого веселья и гадания на кофейной гуще, как в С++.
ГВ>Потом, например, параллельный доступ к тому же Dictionary может привести к весьма загадочным ситуациям (по этому поводу тут Klatu как-то возмущался). А поиски причин могут быть очень нетривиальными, в особенности, если этот Dictionary уедет ещё куда-то.
Эти загадочные сидуации будут касаться только кода, связанного с этим Dictionary. Уши при этом у тебя не отвалятся. А в С++ возможно все.
T>>2) Наличие коллстеков у всех исключений.
ГВ>Не надо преувеличивать: сам по себе коллстек показывает лишь на место возникновения сбоя, но ничего не говорит о той цепи причин, которые привели к его возникновению (кроме непосредственной). Об этом было говорено-переговорено лет семь-восемь назад.
В 90% случаев этого достаточно. В С++ нет даже этого. Ты просто знаешь, что что-то где-то сломалось. Что и где — неизвестно. Если не удалось поймать дамп в момент падения, то начинается веселье.
T>>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
ГВ>Ещё раз повторяю для дотнетчиков: ошибки типобезопасности вычисляются и лечатся на раз. Во-первых, потому что они на самом деле встречаются нечасто; во-вторых, потому что быстро себя проявляют; а в третьих — места, где играются с приведением типов, как правило, хорошо известны и на них в случае чего напрыгивают с проверками в первую очередь (вычурные конструкции вроде reinterpret_cast придуманы не с бухты-барахты).
Ситуация из недавней практики: поскольку проект очень большой, то его части собираются в разное время (чтобы оптимизировать время сборки). Однажды произошла такая ситуация, когда версия хедеров перестала соответствовать бинарям (забыли пересобрать). И продукт при этом работал практически всегда, но иногда в очень редких кейзах начинал течь. Сил угрохали на поиск в коде бага море. А в .NET такое невозможно в принципе.
ГВ>Так что, всё, что ты перечислил — оно, конечно, правильно, но практика — вещь такая...
Все, что я перечислял касается именно практики по интеграции большого количества unmanaged кода, написанного разными командами с большим количеством managed кода.
Ну ты привел проекты очень давние, во-первых, во-вторых, опен-сорс по большей части студенты (или вчерашние студенты) пишут. Опен-сорс, это такая площадка для набития руки.
Я тебе целиком в личку свежие коммерческие проекты на С++ могу закинуть, на предмет поиска голых указателей вне private кода.
И да, многое поменялось. Например, boost уже не тот, чтоб был в 2002-м (накануне принятия стандарта C++03), можно смело пользоваться.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
_>>>Кстати, с ocaml всё не совсем так. G>>Что ты имеешь ввиду? Что он не использует данные о типах? Тогда как он мусор собирает?
FR>Использует битовый тег и унифицированные блоки памяти, для того чтобы отличать то что нужно собирать.
То есть метаинфорамция таки есть. Но за счет большей строгости языка её нужно меньше.
Здравствуйте, gandjustas, Вы писали:
G>То есть метаинфорамция таки есть. Но за счет большей строгости языка её нужно меньше.
Ну в таких и даже больших количествах метаинформация и в С++ есть, а в D или скажем дельфийском
Object Pascal ее на порядок больше, что не делает их управляемыми.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. А ошибки, связанные с нарушениями инвариантов могут быть абсолютно в любом коде — managed, unmanaged, свой, чужой — без разницы.
Неверно. Ты напишешь функцию, которая к полю объекта обращается. А кто-то до вызова твоей функции выполнит delete объекта, а потом на его месте новый создаст. Причина ошибки в таких случаях может находиться очень далеко от места возникновения, в отличии от managed, который еще и staktrace покажет и можно будет спокойно по дереву вызовов пройтись и узнать кто неверные данные передал.
V>>>Откуда же такое внимание к ошибкам именно в нейтиве? T>>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
ГВ>Некоторое время назад (не прошло и эм-м-м... примерно тридцати месяцев с тех пор) мне довелось лечить одну ошибку в комплексе managed+unmanaged. Классика жанра: AVE, чёрт-те что на выходе из unmanaged и далее по списку. Я когда увидел — ну всё, думаю, вот оно, тайное колдунство unmanaged. Добегался по форумам за "дотнетчиками", задавака хренов — вот сам теперь по носу своему задранному и получил. А ведь говорили, предупреждали хором: тайные ошибки — это вотчина unmanaged, и делают их не только вчерашние студенты. Короче, сел на измену, долго и тщательно копал — ничего. Ну, думаю, страус твои перья — и правда, пора C++ выкидывать, раз даже я в нём разобраться не могу. Короче, дня два или три я просидел на этой, довольно крутой измене, но как я ни искал ошибку в unmanaged — ни-фи-га. Поскольку код был мой, осознание этого факта добавляло мне острых ощущений.
ГВ>Потом думаю: не, что-то тут не то. Сильно не то. А, там ещё был нюанс: unmanaged-код был спроектирован исключительно под single-thread, а защиты от параллельного доступа предусмотрено не было (ради оптимизации, конечно). Естественно, были подозрения, что дело в параллельном доступе, но как-то... В общем, просматривали мы тот managed-код, но ничего подозрительного не обнаружили. Да и в остальном он работал без особых нареканий, так что, подозрения казались безосновательными.
ГВ>Короче, в качестве последней надежды я поставил блокировку параллельного обращения на входе в unmanaged. Так, на всякий случай, чем чёрт не шутит?
ГВ>Продолжать рассказывать или уже ясно? Да, через пару минут я получил диагностику параллельного обращения. В общем, в этом корректно работающем managed-коде была классическая concurrency-ошибка параллельного вызова того, что так вызывать в принципе нельзя, да никогда и не планировалось. Особую пикантность всей ситуации придавало то, что в остальном код работал, скажем так, вполне нормально — ну, может быть, кое-какие странности были, но мы их списывали на трудности "реальных условий". Короче: тишь, гладь, AVE, злобный C++, ухмылка Страуструпа на фоне клубов серного дыма.
Аааааа, я валаюсь. То есть код на C++ не был спроектировам под concurrency при этом сам проверок никаких не делал и ты говорищь что это ошибка managed кода?
Ну тогда любая ошибка — ошибка managed ибо не те параметры в unmanaged передаются. ГВ>Дальше всё пошло своим чередом: разобрались, поправили, вытерли пот со лба, облегчённо вздохнули. Однако я вынес из этого несколько очень полезных для себя уроков.
ГВ>1) Нельзя вестись на поводу у дурацких стереотипов, что в AVE всегда виноват unmanaged.
Ок, докажи обратное. Когда чисто managed код вызывает AVE.
ГВ>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так.
То есть managed код работал, а unmanaged таки падал? Ведь именно unmanaged не был спроектирован под cuncurrency.
ГВ>3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше;
Без unmanaged скорее всего косяк был бы найден раньше ибо в managed из unmanaged не попадет сведений о threading model вызываемого кода.
ГВ>В общем, факт остаётся фактом: если бы на хвосте managed не висел сквалыга-unmanaged, ошибку пришлось бы искать гораздо дольше, а то и вообще она проплыла бы мимо. Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг. В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged.
Я так понимаю что ошибки бы и не было если бы не unmanaged.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>То есть метаинфорамция таки есть. Но за счет большей строгости языка её нужно меньше.
FR>Ну в таких и даже больших количествах метаинформация и в С++ есть, а в D или скажем дельфийском FR>Object Pascal ее на порядок больше, что не делает их управляемыми.
В pascal или delphi она никак не используется средой выполнения, поэтому managed они не становятся.
Здравствуйте, c-smile, Вы писали:
G>>Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.
CS>Тут одно утверждение и одно предположение. Оба неверные. Толпы в EverNote никогда не было это точно.
"Двое — уже толпа". Слово "толпа" сильно образное. Причем если программистов было мало, то переписывание с C++ на .NET с большей вероятностью приведет к неудовлетворительноу результату.
CS>По поводу WPF и .NET UI вообще.
CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC. CS>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл. CS>Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.
Для быстрого старта надо не выгружать приложение из памяти после первого запуска. Так например metro работает в windows 8.
Долгий запуск — действительно проблема для WPF, но её можно скрыть как минимум.
Кстати в винде даже нативные notes первый раз стартуют заметное время. Но после добавления закладок они стартуют с виндой и не выгружаются.
Аналогичный инструмент MS Office OneNote тоже небысстро стартует, но у него в трее висит иконка (а соотвественно работает процесс), который позволяет быстро создать заметку.
При этом будучи запущенным постоянно тоже неплохо работает.
CS>Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.
Да, wpf сложен, особенно для нетривиальных интерфейсов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. А ошибки, связанные с нарушениями инвариантов могут быть абсолютно в любом коде — managed, unmanaged, свой, чужой — без разницы.
G>Неверно. Ты напишешь функцию, которая к полю объекта обращается. А кто-то до вызова твоей функции выполнит delete объекта, а потом на его месте новый создаст. Причина ошибки в таких случаях может находиться очень далеко от места возникновения, в отличии от managed, который еще и staktrace покажет и можно будет спокойно по дереву вызовов пройтись и узнать кто неверные данные передал.
Ясное дело, в managed с этим намного лучше: ссылку на объект, к которому моя функция будет обращаться, уже давно обнулили, но специально ради моей функции держат в памяти уже забытую всеми остальными копию. Благодарствую за любезность!
G>Аааааа, я валаюсь. То есть код на C++ не был спроектировам под concurrency при этом сам проверок никаких не делал и ты говорищь что это ошибка managed кода?
Именно.
G>Ну тогда любая ошибка — ошибка managed ибо не те параметры в unmanaged передаются.
Нет, не любая.
ГВ>>Дальше всё пошло своим чередом: разобрались, поправили, вытерли пот со лба, облегчённо вздохнули. Однако я вынес из этого несколько очень полезных для себя уроков.
ГВ>>1) Нельзя вестись на поводу у дурацких стереотипов, что в AVE всегда виноват unmanaged. G>Ок, докажи обратное. Когда чисто managed код вызывает AVE.
Что — обратное?
ГВ>>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так. G>То есть managed код работал, а unmanaged таки падал? Ведь именно unmanaged не был спроектирован под cuncurrency.
Умничка. Именно дотнетный код — работал. Ну, по вашему же, если эксцепшенов нет, значит код — работает! Возьми с полки пирожок. Ты, кстати, не у конкурентов, часом работаешь? Надо посоветовать, чтобы тебе зарплату подняли. Скажи, эдипов папа посоветовал.
ГВ>>3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше; G>Без unmanaged скорее всего косяк был бы найден раньше ибо в managed из unmanaged не попадет сведений о threading model вызываемого кода.
Без unmanaged ошибка не была бы найдена вообще. Но она от этого никуда бы не делась.
ГВ>>В общем, факт остаётся фактом: если бы на хвосте managed не висел сквалыга-unmanaged, ошибку пришлось бы искать гораздо дольше, а то и вообще она проплыла бы мимо. Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг. В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged. G>Я так понимаю что ошибки бы и не было если бы не unmanaged.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, c-smile, Вы писали:
CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
Тут нужно понимать масштабы. Заметная нагрузка на GC это сотни тысяч — миллионы объектов. В типичной WPF форме столько даже близко нет.
CS>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл.
Вот уж на инициализацию вряд ли влияет скорость сборки мусора.
Основные причины тормозов весьма традиционны для МС — медленный рендерер.
CS>В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.
WPF изначально проектировался GPU friendly, в отличие от.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Сам начинает? А он как это делает, по вторникам, или по пятницам?
Бывает и по вторникам, бывает и по пятницам. Ты же понимаешь, что когда программу пишешь только ты, это совсем не тоже самое, когда её пишут человек 100, находящихся в разных отделах. А ты пытаешься свой локальный опыт экстраполировать на все случаи, и говоришь, что мол, я вот никогда с этими проблемами не сталкивался, значит их нет.
ГВ>Да вот тем самым, когда вместо двух объектов оказывался один.
И что? При чем тут управляемость кода?
ГВ>Нет, именно теми словами, которыми написано: трудно искать чёрную кошку в тёмной комнате, когда её нет.
Дак комната то стала темной из-за С++
ГВ>Некоторые детали мне пришлось опустить. А потом проезд по памяти с разносом всего, включая GC-хип бы бы благом, поскольку заставил бы обратить внимание на эту ошибку намного раньше. К слову сказать, AVE в какой-то момент был у меня единственным методом диагностики. AVE и непосредственно предшествующее ему состояние памяти.
ГВ>>>Ведь сложность поиска бага на самом деле зависит не от "управляемости" кода, а от того, какой это баг. T>>Совершенно верно. При этом самые сложные для поиска баги — это баги, специфичные для С++, а именно проход по памяти, некорректная её интерпретация и пр.
ГВ>Мантра. Даже обсуждать не хочу. Как раз из-за того, что не раз такие ошибки и делал, и лечил (не только у себя).
Ну вот, в данный момент разбираю дамп. Бага воспроизвелась только один раз. Что посоветуешь?
ГВ>>>В managed-коде причины багов ничуть не легче раскапывать, чем в unmanaged, а подчас и тяжелее из-за его всепроникающей "корректности", которая позволяет ему проглатывать то, что валит unmanaged. T>>Легче из-а отсутствия наиболее противных багов и наличия нормальных исключений с callstack'ами и сообщениями.
ГВ>Вот странное дело. Сколько пишу на этом кошмарном C++, а самые противные баги — из-за бестолковой спецификации. ЧЯДНТ?
У тебя сколько человек в команде и сколько команд работает над одним продуктом?
ГВ>>>У меня даже закралась крамольная мысль, [...] T>>Контракты тебя спасут. В отличии от С++, в котором даже контракты не помогут, так как ничего не стоит эти контракты кому угодно разрушить без твоего ведома.
ГВ>Ну, в упомянутом случае они спасти не могли, хотя бы в виду исторических причин. А то, знаешь, хорошо решать проблемы с помощью будущих инструментов.
Какой будущий инструмент? Этому инструменту уже много десятков лет. Называется "assert".
T>>Локализованы — это значит, что у тебя не сломается не связанная с этими объектами функциональность. [...] В частности, благодаря наличию метаданных твоя ошибка ищется очень просто: в windbg ты можешь сдампить все объекты интересующиего тебя типа, посмотреть их количество, и проверить все ссылки, кто на что ссылается. В частности, как только тестировщик видит, что приложение падает (из-за нарушения контракта), либо работает некорректно, то он делает дамп, отдает его тебе, ты видишь, что объектов два вместо одного, кричишь WTF, смотришь на код, который их создает и видишь, что этот код ломается в случае параллельного доступа. Все просто и скучно, никакого веселья и гадания на кофейной гуще, как в С++.
ГВ>Хм. Я, вроде, понятно высказался: один объект вместо двух. Если они используются как read-only, ошибок попросту не будет. Вернее, они будут проявляться очень косвенно. Какая именно функциональность поломается — трудно предсказать в любом случае.
А не надо предсказывать. Если ничего не ломается, то и бага нет. Если ломается, то тебе в багтрекере напишут, что именно сломалось и как это воспроизвести.
ГВ>Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи.
В дампе ты бы увидел, что было создано два объекта вместо одного. Дальше все тривиально.
T>>>>2) Наличие коллстеков у всех исключений. ГВ>>>Не надо преувеличивать: сам по себе коллстек показывает лишь на место возникновения сбоя, но ничего не говорит о той цепи причин, которые привели к его возникновению (кроме непосредственной). Об этом было говорено-переговорено лет семь-восемь назад. T>>В 90% случаев этого достаточно. В С++ нет даже этого. Ты просто знаешь, что что-то где-то сломалось. Что и где — неизвестно. Если не удалось поймать дамп в момент падения, то начинается веселье.
ГВ>Чушь. В C++, в случае выбрасывания исключения я знаю о происходящем ровно столько же, сколько и в C#: что в точке файл... строка... вылетело исключение. Информация о стеке... Ну как, может быть полезна с некоторой вероятностью, но не более того. А о действительных причинах в этот момент я всё равно могу только догадываться.
Строчку файла ты узнаешь только если исключение соизволит тебе это сообщить. Код бывает не только твой, но и чужой, на который ты повлиять не можешь.
T>>Ситуация из недавней практики: поскольку проект очень большой, то его части собираются в разное время (чтобы оптимизировать время сборки). Однажды произошла такая ситуация, когда версия хедеров перестала соответствовать бинарям (забыли пересобрать). И продукт при этом работал практически всегда, но иногда в очень редких кейзах начинал течь. Сил угрохали на поиск в коде бага море. А в .NET такое невозможно в принципе.
ГВ>И о чём это говорит? Да ни о чём. Собирать модули надо с соблюдением процедуры, больше ничего.
Это говорит о том, что в С++ проблемы можно получить в любом месте и фраза, что неверная интерпретация памяти бывает только [подставить что-то одно] ложная. Неверная интерпретация памяти может произойти по миллиону причин. И для каждой такой причины можно ответить: "надо делать то-то".
Здравствуйте, Klatu, Вы писали:
V>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. K>ну это просто вранье или полная некомпетентность
Слушай, найди какой-нибудь другой аргумент, а?
V>>то программисты C# допускают намного больше ошибок, чем программисты на C++ K>Я пока что не встречал более пафосных говнокодеров, чем на С++. Вот это — точно медицинский факт. Каждое нубло, которое накропало пару примитивных программок на С++ — уже считает себя гуру
Давай уж начистоту: "вы все [плохое слово по выбору], а я в белом!" Так хоть честно будет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>ЧСХ, без моего желания C++ тоже не начнёт вольным образом реинтерпретировать память. А ошибки, связанные с нарушениями инвариантов могут быть абсолютно в любом коде — managed, unmanaged, свой, чужой — без разницы.
G>>Неверно. Ты напишешь функцию, которая к полю объекта обращается. А кто-то до вызова твоей функции выполнит delete объекта, а потом на его месте новый создаст. Причина ошибки в таких случаях может находиться очень далеко от места возникновения, в отличии от managed, который еще и staktrace покажет и можно будет спокойно по дереву вызовов пройтись и узнать кто неверные данные передал.
ГВ>Ясное дело, в managed с этим намного лучше: ссылку на объект, к которому моя функция будет обращаться, уже давно обнулили, но специально ради моей функции держат в памяти уже забытую всеми остальными копию. Благодарствую за любезность!
Именно. Это позволяет делать unmanaged.
Есть еще более коварный вид ошибок. Когда ты сам держишь ссылку, а кто-то другой объект удаляет, считая его ненужным.
ГВ>>>Дальше всё пошло своим чередом: разобрались, поправили, вытерли пот со лба, облегчённо вздохнули. Однако я вынес из этого несколько очень полезных для себя уроков.
ГВ>>>1) Нельзя вестись на поводу у дурацких стереотипов, что в AVE всегда виноват unmanaged. G>>Ок, докажи обратное. Когда чисто managed код вызывает AVE. ГВ>Что — обратное?
Дальше написано. Пример когда чисто managed код вызывает ave.
ГВ>>>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так. G>>То есть managed код работал, а unmanaged таки падал? Ведь именно unmanaged не был спроектирован под cuncurrency.
ГВ>Умничка. Именно дотнетный код — работал. Ну, по вашему же, если эксцепшенов нет, значит код — работает! Возьми с полки пирожок. Ты, кстати, не у конкурентов, часом работаешь? Надо посоветовать, чтобы тебе зарплату подняли. Скажи, эдипов папа посоветовал.
Не уходит от вопроса. Ты не написал что были какие проблемы непосредственно в managed, ты сказал что он не так вызывал unmanaged, но сам unmanaged этому никак не противился.
То есть переписал unmanaged так чтобы не было этих проблема можно было вообще исключить эту проблему.
ГВ>>>3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше; G>>Без unmanaged скорее всего косяк был бы найден раньше ибо в managed из unmanaged не попадет сведений о threading model вызываемого кода.
ГВ>Без unmanaged ошибка не была бы найдена вообще. Но она от этого никуда бы не делась
А в чем тогда ошибка? И почему она не была бы найдена? Или ты что-то не договариваешь ил просто пытаешься свалить вину.
Здравствуйте, mrTwister, Вы писали:
ГВ>>Сам начинает? А он как это делает, по вторникам, или по пятницам? T>Бывает и по вторникам, бывает и по пятницам. Ты же понимаешь, что когда программу пишешь только ты, это совсем не тоже самое, когда её пишут человек 100, находящихся в разных отделах. А ты пытаешься свой локальный опыт экстраполировать на все случаи, и говоришь, что мол, я вот никогда с этими проблемами не сталкивался, значит их нет.
Если ты заметил, то я на все случаи свой опыт не экстраполирую. Напротив, я говорю о некорректности таких экстраполяций.
ГВ>>Да вот тем самым, когда вместо двух объектов оказывался один. T>И что? При чем тут управляемость кода?
Сама по себе управляемость, может быть, не при чём. А вот гарантирование корректности ссылок — очень даже при чём.
ГВ>>Нет, именно теми словами, которыми написано: трудно искать чёрную кошку в тёмной комнате, когда её нет. T>Дак комната то стала темной из-за С++
Нет, комната стала тёмной по другим причинам. Пафосно выражаясь, C++ — это были те искры, которые позволили найти выход из этой комнаты.
ГВ>>Мантра. Даже обсуждать не хочу. Как раз из-за того, что не раз такие ошибки и делал, и лечил (не только у себя). T>Ну вот, в данный момент разбираю дамп. Бага воспроизвелась только один раз. Что посоветуешь?
Без исходного кода я ничего посоветовать не могу. Если хочешь, свяжись по мылу, может быть, что-нибудь придумаем.
ГВ>>Вот странное дело. Сколько пишу на этом кошмарном C++, а самые противные баги — из-за бестолковой спецификации. ЧЯДНТ? T>У тебя сколько человек в команде и сколько команд работает над одним продуктом?
Скажем так, доводилось работать в разных условиях.
ГВ>>>>У меня даже закралась крамольная мысль, [...] T>>>Контракты тебя спасут. В отличии от С++, в котором даже контракты не помогут, так как ничего не стоит эти контракты кому угодно разрушить без твоего ведома. ГВ>>Ну, в упомянутом случае они спасти не могли, хотя бы в виду исторических причин. А то, знаешь, хорошо решать проблемы с помощью будущих инструментов. T>Какой будущий инструмент? Этому инструменту уже много десятков лет. Называется "assert".
А... Я подумал про design contracts из FW 4. Ну так assert-ом по сути и спаслись.
ГВ>>Хм. Я, вроде, понятно высказался: один объект вместо двух. Если они используются как read-only, ошибок попросту не будет. Вернее, они будут проявляться очень косвенно. Какая именно функциональность поломается — трудно предсказать в любом случае. T>А не надо предсказывать. Если ничего не ломается, то и бага нет. Если ломается, то тебе в багтрекере напишут, что именно сломалось и как это воспроизвести.
Во-во, знакомо. Ошибка — это только если exception, всё остальное — "так и надо".
ГВ>>Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи. T>В дампе ты бы увидел, что было создано два объекта вместо одного. Дальше все тривиально.
Ничего бы я там не увидел... Да и собственно, я говорил о совершенно других вещах.
ГВ>>Чушь. В C++, в случае выбрасывания исключения я знаю о происходящем ровно столько же, сколько и в C#: что в точке файл... строка... вылетело исключение. Информация о стеке... Ну как, может быть полезна с некоторой вероятностью, но не более того. А о действительных причинах в этот момент я всё равно могу только догадываться. T>Строчку файла ты узнаешь только если исключение соизволит тебе это сообщить. Код бывает не только твой, но и чужой, на который ты повлиять не можешь.
Тоже справедливо. А исходников этого самого чужого кода у меня нет?
T>>>Ситуация из недавней практики: поскольку проект очень большой, то его части собираются в разное время (чтобы оптимизировать время сборки). Однажды произошла такая ситуация, когда версия хедеров перестала соответствовать бинарям (забыли пересобрать). И продукт при этом работал практически всегда, но иногда в очень редких кейзах начинал течь. Сил угрохали на поиск в коде бага море. А в .NET такое невозможно в принципе. ГВ>>И о чём это говорит? Да ни о чём. Собирать модули надо с соблюдением процедуры, больше ничего. T>Это говорит о том, что в С++ проблемы можно получить в любом месте и фраза, что неверная интерпретация памяти бывает только [подставить что-то одно] ложная. Неверная интерпретация памяти может произойти по миллиону причин. И для каждой такой причины можно ответить: "надо делать то-то".
Так и надо делать "то-то".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Нет, именно теми словами, которыми написано: трудно искать чёрную кошку в тёмной комнате, когда её нет.
Так вот в том то и дело, что AVE это черная кошка. Означает, что что то не так и ничего больше.
Я буквально неделю назад выловил ошибку в managed коде, тоже с внезапным concurrency связанную. Только там было нарушение инвариантов, а не AVE. Просмотр небольшого кусочка кода, в котором исключение произошло, сразу выявил, что это нарушение могло произойти только из-за гонок. Остальное было тривиально. А было бы AVE, точно так же несколько дней искал бы черную кошку в темной комнате.
ГВ>это, в сущности, не так уж плохо, поскольку заставляет внимательнее относиться к программированию.
Да, этот аргумент меня всегда убивал наповал. Я даже не знаю, что на это ответить.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну как тебе сказать. Я знаю довольно много плюсовиков (во всяком случае, совсем не единицы), которые просто не станут реализовывать свои механизмы управления памятью, поскольку имеющихся общедоступных средств вполне достаточно. Хотя это вполне в их силах. Кстати, никаких "качественных" или "некачественных" политик управления памятью не бывает. Они соответствуют либо одним требованиям, либо другим. И собственно говоря, управление памятью почти всегда согласуется с архитектурой приложения, впрочем, это отдельный разговор.
Вообще то качество и есть соответствие определенным требованиям
Не ясно, что ты хотел сказать "управление памятью почти всегда согласуется с архитектурой приложения" — это как понять ? Кто выполняет это согласование ? какая квалификация должна быть у того кто выполняет это согласование ? Какие архитектуры уже согласованы с той политикой управления что искаропки ?
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Нет, именно теми словами, которыми написано: трудно искать чёрную кошку в тёмной комнате, когда её нет. AVK>Так вот в том то и дело, что AVE это черная кошка. Означает, что что то не так и ничего больше.
"Отсутствующей кошкой" я назвал ошибку в unmanaged. AVE как раз — очень даже ощутимый кошак.
AVK>Я буквально неделю назад выловил ошибку в managed коде, тоже с внезапным concurrency связанную. Только там было нарушение инвариантов, а не AVE. Просмотр небольшого кусочка кода, в котором исключение произошло, сразу выявил, что это нарушение могло произойти только из-за гонок. Остальное было тривиально. А было бы AVE, точно так же несколько дней искал бы черную кошку в темной комнате.
Здесь главное — что искомой "кошки" (ошибки в unmanaged) не было. Было банальное нарушение инварианта порядка доступа и в виду отсутствия защиты от такого нарушения...
P.S.: Прерываюсь до вечера.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mrTwister, Вы писали:
T>Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ!
Ну ты не приводи слова без указания контекста, або даже я упомяну неприятное слово "демагогия".
T>Куча тактов процессора и байтов памяти зазря тратятся.
-1
Достаточно самому написать програму из 3-х строк, с использованием std::auto_ptr, и убедиться на сгенеренном бинарном коде, что использование этого умного указателя ничего не стоит, в сравнении с ручным вариантом, безопасным к исключениям.
T>Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
Наоборот, плюсовики утверждают, что такая лишняя безопасность ничего не стоит... в упор не слышите просто...
Здравствуйте, vdimas, Вы писали:
I>>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
V>Не преувеличивай, есть всего 2 основных способа, относящихся конкретно к дотнету:
Я ничего не преувеличиваю. Все что перечислено — это тупо оптимизации работы с памятью.
V>- это создание относительно "больших" value-type, специально быть приватными полями других объектов. V>- хранение таких же value-type в массивах.
Это слишком короткий список, что бы претендовать на полноту.
V>Оба способа требуют пересмотра внутреннего интерфейса, понятное дело. Твой ref нужен вовсе не всегда, это зависит от того, где ты разместишь функциональность, и
Очевидно, любой из способов нужен не всегда. Иногда перформас дает пул обхектов, а иногда отказ от такого пула. С ref тоже самое. Более того — ни одна оптимизация не гарантирует какой либо эффект. еще раз — ни одна, даже две твои перечисленые. Они, к слову, ничем не отличаются от тех что я перечислил.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Я буквально неделю назад выловил ошибку в managed коде, тоже с внезапным concurrency связанную. Только там было нарушение инвариантов, а не AVE. Просмотр небольшого кусочка кода, в котором исключение произошло, сразу выявил, что это нарушение могло произойти только из-за гонок. Остальное было тривиально. А было бы AVE, точно так же несколько дней искал бы черную кошку в темной комнате.
ГВ>Здесь главное — что искомой "кошки" (ошибки в unmanaged) не было.
Так и в моем случае ошибка была в совсем другом, никак не связанном месте, не в том, где нарушение инвариантов вылазило.
ГВ> Было банальное нарушение инварианта порядка доступа и в виду отсутствия защиты от такого нарушения...
Во-во, и у меня было ровно то же самое.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно.
ГВ>Вот любишь же ты этим своим "качественно" цокать по поводу и без. Неужели GC способен что-нибудь потерять?
Есть такая вещь, как например фрагментация или поколения объектов. В некоторых сценариях GC начинает лажать гораздо сильнее чем С++ные хипы.
I>>Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
ГВ>Сочувствую, без шуток. Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
По трудоёмкости может и не стояли рядом, но глядя на обилие ошибок с указателями в сиплюсных программах, как то возникает сомнение что люди в общей массе вообще способны освоить эти указатели
Здравствуйте, AndrewVK, Вы писали:
V>>Ты сим постом сделал такое предположение о кач-ве дотнетных специалистов, что обсуждать сразу стало нечего.
AVK>А ты этим постом тоже кое что наглядно продемонстрировал.
Согласен, но т.к. сам тоже активно юзаю дотнет, то это был ответный гротеск на гротеск. И да, можешь в другой раз ограничиваться одним тем самым словом, я и так понял.
AVK>И от того, что конкретного человека ты с шарпа на плюсы пересадишь, он умнее не станет.
Ну так, если брать настолько уж "конкретных" специалистов, так они и using() не пользуют в дотнете, что приходилось разруливать ситуацию, когда нейтивная память уже кончается, а дотнетоному GC до лампочки... Как уже говорил тут, причина в отсутствии регулярного взаимного ревью кода, из-за которого молодые специалисты растут не так быстро, как могли бы. Или есть еще вариант ошибки профессией, но в этом варианте и обсуждать опять нечего.
Здравствуйте, vdimas, Вы писали:
T>>Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
V>Наоборот, плюсовики утверждают, что такая лишняя безопасность ничего не стоит... в упор не слышите просто...
Может и ничего не стоит. А кто её умеет и где посмотреть продукты, где бы эта безопасность что ничего ен стоит была использована ? Я чет как ни залезу в чей нибудь С++ код, так вечно хаос с указателями. Такое ощущение что RAII еще не изобрели или изобрели но не рассказали, как правильно им пользоваться
Здравствуйте, vdimas, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок?
Дотнет исключает огромный класс ошибок.
>Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>В pascal или delphi она никак не используется средой выполнения, поэтому managed они не становятся.
FR>Используется, в новых версиях рефлекшен из управляемых языков уже в приличном объеме содран и работает.
Рефлекшн и раньше был, но это не означает что среда исполнения использует эти сведения хоть как-то. С другой стороны этого делфи генерит блоки финализаторов для строк и com-объектов, так что в этом плане можно считать managed языком.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Ikemefula, Вы писали:
I>>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
FR>Прикол в том что точно также падают и глючат и программы на шарпе и яве.
Но не так глючат. В unmanaged легко получить AV если даже ты не трогал сслыку. Просто её delete_нул кто-то другой. А в managed так не бывает. Ты получишь nre только тогда когда на вход тебе nell придет, а это банально проверяется контрактами.
Здравствуйте, MxMsk, Вы писали:
MM>Далее, что выглядит вопиющим разгильдяйством, 20% WPF занималась оповещением о том, что изменилась доступность команд.
Эта претензия снимается. Не нужно было мне скроллбар дергать. Без него команды отняли 3%, а оставшиеся 17% ушли в измерение размеров.
Здравствуйте, Sinclair, Вы писали:
BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру? S>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои.
Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"?
S> Голые указатели, если верить форумам, вообще никто уже десять лет не применяет.
Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры.
S> И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.
Жуткий говнокод есть и на дотнете, не волнуйся.
Особенно когда пишут индусы и проект в финансовой сфере.
S>Ок, давайте возьмём какой-нибудь современный проект, существующий в реальности, а не в хвастливых рассказах. S>Вот, первое, что мне попалось при поиске — Миранда. S>Порыл дальше — вот, вроде не очень давний Blender (http://www.blender.org/):
Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша.
S>http://code.google.com/p/miranda/source/browse/trunk/miranda/src/modules/history/history.cpp S>Что мы тут видим? Умные указатели? S>Как бы не так! S>По-прежнему незамутнённые memcpy(), S>, и явные вызовы mir_free().
Что говорит о том, что это не С++ а С с классами.
К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API.
S>C-style cast (кто там мне рассказывал про обязательность reinterpret_cast?)
Не знаю кто тебе рассказывал. Я сам reinterpret_cast и ему подобные не люблю — громоздко а бонусов никаких.
S> О да, последнее явно говорит о собственном аллокаторе. Да вот же он: http://code.google.com/p/miranda/source/browse/trunk/miranda/src/core/memory.cpp S>Упс, это всего лишь тонкий враппер вокруг malloc и free. Никаких чудес производительности от него ждать не стоит. Скорее наоборот: помимо обычного дорогого free он ещё и занимается обкладкой освобождаемой области 0xDEADBEEF.
Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ".
S>Ок, наверное Миранду пишут гуры недостаточного уровня.
Нормально написанных Opensource проектов — единицы. В основном вот такая вот жуть.
S>Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.
Ты ищешь нормальный код там, где его отродясь не было.
S>Добро пожаловать в реальный мир, Нео.
Реальный мир не состоит из одного опенсурса.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, mrTwister, Вы писали:
T>Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему. А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого. И какая разница, почему программа упала, из-за изолированной ошибки или нет? Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range. Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна. И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек. Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
V>>Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
T>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме.
Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
T>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
V>>Откуда же такое внимание к ошибкам именно в нейтиве?
T>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин: T>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
Легко в тех же ошибках в многопоточном коде.
T>2) Наличие коллстеков у всех исключений.
Помогает только для примитивных ошибок, и доступно для С++ тоже.
T>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что...
Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки, всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII, и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии, что совершенно невозможно в дотнете. Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак. Это надо С++ использовать как голый С, для получения наиболее обсуждаемого здесь эффекта, ну так давай и сравнивать голый С с дотнетом, при чем здесь С++?
По моему ИМХО, самые серьезные ошибки — это конечно плавающие и возникающие связанные с неполной/недостаточной реализацией логики, особенно на микроуровне. Например, причиной для обоих чаще всего служит банальный забытый else где-нить в иерархии if, что может принести столько настоящей головной боли, что врагу не пожелаешь. На любом языке, заметь. Это причина, по которой, я хоть и не пользую активно АлгТД и ПМ в работе, но обеими руками за эту технику, т.к. прекрасно понимаю, какой класс действительно трудоемких в нахождении проблем он способен решить.
Здравствуйте, Ikemefula, Вы писали:
G>>>в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью. BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
I>Средний C# не знает и не умеет указателей. Как то так выходит, что заказчики предлагают проектов примерно на порядок больше, чем могут реализовать умелые сиплюсники, так что unmanaged это вынужденая мера.
Печально это, не спорю.
I>C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.
Мрак. У меня последний раз "не взлетал" код (именно совсем не взлетал, не от скуки, из любви к искусству или стремления к совершенству), примерно, в 1990-м, если не ошибаюсь, это была лаба на ассемблере КР580ИК80А. А всё остальное как-то либо летало, либо не доводилось до "взлётной полосы" по каким-то отвлечённым соображениям. Так что, блин, всё сильнее чувствую себя в башне из бивней мамонта.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
А можно узнать возрастные характеристики этого среднего программиста?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Печально это, не спорю.
I>>C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.
ГВ>Мрак. У меня последний раз "не взлетал" код (именно совсем не взлетал, не от скуки, из любви к искусству или стремления к совершенству), примерно, в 1990-м, если не ошибаюсь, это была лаба на ассемблере КР580ИК80А. А всё остальное как-то либо летало, либо не доводилось до "взлётной полосы" по каким-то отвлечённым соображениям. Так что, блин, всё сильнее чувствую себя в башне из бивней мамонта.
Сейчас вдобавок ко всему сказывается сильный спад в образовании, так что сильно кажется точка невозврата в С++ уже давно пройдена. Нативная разработка может и будет набирать обороты, но это точно будет не олдскульный С++, а чтото более гуманное и безопасное. Может будет медленнее в базовых вещах, чем С++, но более предсказуемее, чем managed, который кое где может и обставлять С++ а кое где может и в 100 раз медленнее работать.
Здравствуйте, Ikemefula, Вы писали:
I>Сейчас вдобавок ко всему сказывается сильный спад в образовании, так что сильно кажется точка невозврата в С++ уже давно пройдена.
Мне кажется, ты несколько заблуждаешься относительно "точки невозврата", но тем не менее, спорить не буду: в конце концов, мне тоже только кажется, а как оно будет на самом деле...
I>Нативная разработка может и будет набирать обороты, но это точно будет не олдскульный С++, а чтото более гуманное и безопасное. Может будет медленнее в базовых вещах, чем С++, но более предсказуемее, чем managed, который кое где может и обставлять С++ а кое где может и в 100 раз медленнее работать.
Ну, посмотрим. C++, конечно, далеко не идеал языка программирования, но пока что ничего лучше для native не придумали (по сумме факторов, конечно).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, mrTwister, Вы писали:
T>>Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
V>И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему. А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого.
Ты путаешь возможность специально уронить или случайно. Можешь вообще с помощью класса Marshal AV получить. Но find all references сразу скажет где это происходит еще до запуска.
V>И какая разница, почему программа упала, из-за изолированной ошибки или нет?
В этом нет разницы. Но есть разница в том что ошибка создавалась специально (то есть не ошибка, а вредительство) или возникла случайно.
Причем именно апологеты unmanaged имеют стремления делать такие вещи в managed среде.
V>Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range. Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна.
outofrange вывалится даже у клиента с полным stacktrace резко сузив область поиска. Если же неуправляемая программа упадет с ошибкой в оптимизированном коде, то придется очень долго её воспроизводить.
V>И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное.
Если не ошибаюсь то для этого нужна debug сборка, которая сводит на нет все преимущества C++.
V>А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек. Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
Да, только наведенных ошибок в managed коде почти нет или легко отлавливаются при тестировании, а в unmanaged их полно.
T>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. V>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
Стектрейс, хотя для nre в продакшене надо сильно постараться
T>>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь. V>Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
Прикол весь в том что AV возникает не там где находится ошибка, что значительно усложняет отладку. Кроме того пропустить на тестировании outofrange и nre довольно сложно.
T>>2) Наличие коллстеков у всех исключений. V>Помогает только для примитивных ошибок, и доступно для С++ тоже.
Ага, но только в дебаг версии.
T>>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы. V>Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что...
Вот только по-умолчанию C# рождает safe код, а unsafe без необходимости даже не ошибка, а вредительство. С++ имеет тяжелое наследие C и не наказывает за попытки писать в стиле С, то есть любой код по умолчанию — unsafe.
Использование только safe части C++ делает программу не быстрее (а зачастую и медленнее) чем .NET
V>Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки
Ага, только они очень часто встречаются в unmanaged.
V>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII
Которым далеко не все пользуются
V>и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии
Ну это когда размер известен на этапе компиляции.
V>что совершенно невозможно в дотнете
Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1.
V>Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак.
v.end()++ не?
V>Это надо С++ использовать как голый С, для получения наиболее обсуждаемого здесь эффекта, ну так давай и сравнивать голый С с дотнетом, при чем здесь С++?
Весь прикол в том что С++ унаследовал все проблемы C и никто тебе не запрещает использовать небезопасный код. А если использовать только безопасный, то C++ начинает сосать.
Кроме того даже если ты напишешь safe код, то менее грамотный коллега напишет unsafe, который заставит твой код работать неправильно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Если ты заметил, то я на все случаи свой опыт не экстраполирую. Напротив, я говорю о некорректности таких экстраполяций.
Ну ты же говоришь, что мол в реальности этих ошибок почти нет. Я охотно верю, что при разработки продукта силами компактной замкнутой команды педантичных плюсовиков этих проблем не будет. Но, к сожалению, не каждый продукт можно разработать в таком режиме за приемлемые сроки.
ГВ>Сама по себе управляемость, может быть, не при чём. А вот гарантирование корректности ссылок — очень даже при чём.
Ты бы предпочел UB?
ГВ>Нет, комната стала тёмной по другим причинам. Пафосно выражаясь, C++ — это были те искры, которые позволили найти выход из этой комнаты.
Предпочитаю фонарик в виде assert искрам из глаз в виде AV
ГВ>Без исходного кода я ничего посоветовать не могу. Если хочешь, свяжись по мылу, может быть, что-нибудь придумаем.
А исходный код тебе ничего не даст. Тот код, что упал вполне себе невинен. Проблема в том, что кто-то испортил общий хип. По дампу понять, кто испортил общий хип невозможно. Под app verifier ошибка не воспроизводится. Общая кодовая база — сотни мегабайт исходников. Понятно, что не надо использовать общий хип, надо делать кастомные хипы для каждого компонента, а еще лучше разносить компоненты по процессам. Но это все костыли, вызванные "особенностями" С++ и из-за которых приходится существенно усложнять архитектуру.
ГВ>А... Я подумал про design contracts из FW 4. Ну так assert-ом по сути и спаслись.
Ну вот видишь. Ассерт — мощная штука, но его не повесишь на порчу памяти.
ГВ>Во-во, знакомо. Ошибка — это только если exception, всё остальное — "так и надо".
Не совсем. Ошибка — это несоответствие требованиям. Все остальное — "так и надо".
ГВ>>>Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи. T>>В дампе ты бы увидел, что было создано два объекта вместо одного. Дальше все тривиально.
ГВ>Ничего бы я там не увидел... Да и собственно, я говорил о совершенно других вещах.
Почему не увидел? Ты хотел привести пример трудноуловимой с точки зрения плюсовика ошибки. Тебе она кажется трудноуловимой, потому что ты не привык, что во время выполнения и во время разбора полетов (дампа) тебе доступны все метаданные, благодаря чему возможностей для анализа существенно больше и ты можешь делать такие вещи, которые очень трудозатратны в случае С++. Ну вот, например, как ты в windbg для С++ сможешь сдампить все объекты заданного типа? Или все произошедшие в последнее время исключения (очень полезно при разборе говнокода, маскирующего исключения)?
ГВ>Тоже справедливо. А исходников этого самого чужого кода у меня нет?
Исходники есть. Но править ты их не можешь.
T>>Это говорит о том, что в С++ проблемы можно получить в любом месте и фраза, что неверная интерпретация памяти бывает только [подставить что-то одно] ложная. Неверная интерпретация памяти может произойти по миллиону причин. И для каждой такой причины можно ответить: "надо делать то-то".
ГВ>Так и надо делать "то-то".
Совершенно верно. То есть другими словами, не надо делать ошибок. Но люди их все равно делают, это данность. В случае с С++ многие такие ошибки оборачиваются большими потерями времени.
Здравствуйте, Ikemefula, Вы писали:
I>>>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол. ГВ>>А можно узнать возрастные характеристики этого среднего программиста?
I>28-30 лет.
Это ты про пост-СССР? Или про Бахрейн, который у тебя в профиле?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей.
У тебя что, отсутствие указателей это признак качества кода?
S>Тем не менее, никаких умных указателей всё же нет — похоже, проще вообще обходиться без них, чем использовать.
Неужто вообще весь код просмотрел?
Правильное использование любого инструмента заключается в использовании его ровно там где он реально нужен.
Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод.
S>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
Operator new может быть перекрыт глобально.
И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен.
S>Итого: кастомные аллокаторы и умные поинтеры в реальной жизни не встречаются.
Скажи, а кенгуру ты вживую видел? Или они тоже в реальной жизни не встречаются?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>Может и ничего не стоит. А кто её умеет и где посмотреть продукты, где бы эта безопасность что ничего ен стоит была использована ? Я чет как ни залезу в чей нибудь С++ код, так вечно хаос с указателями. Такое ощущение что RAII еще не изобрели или изобрели но не рассказали, как правильно им пользоваться
Ну извини. То, что тебя окружают индусокодеры означает совсем не это.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>По трудоёмкости может и не стояли рядом, но глядя на обилие ошибок с указателями в сиплюсных программах, как то возникает сомнение что люди в общей массе вообще способны освоить эти указатели
Встречал людей которые в принципе не могли понять как работает указатель и как им пользоваться. Т.е. в принципе не понимали. Как работает индекс по массиву — понятно, а как работает BYTE* по flat оперативке — полный ступор и пустота в глазах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему.
А кто тебя заставляет это делать?
V>А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого. И какая разница, почему программа упала, из-за изолированной ошибки или нет? Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range.
Ну если ты согласился, то и спорить не о чем
V>Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна. И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек.
Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие! А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?
V>Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
И при этом я не помню случая, когда при наличии на руках дампа процессе не смог бы найти ошибку в managed коде. При этом случаев, аналогичных вышеописанному, когда кто-то портит общий хип, а потом кто-то другой падает из-за чего дамп оказывается бесполезным — полным полно. Потому что хип может испортить кто угодно и в подозреваемых находится весь код на С++. В случае с .NET'ом T>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме.
V>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
Разница в том, что мы получим NRE не где попало, а только там, где мы работаем с общим испорченным состоянием. Такого кода, как правило мало и в результате ошибку проще локализовать.
T>>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
V>Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
Совсем не факт, что проявит и повлиять на это я не могу. А вот ассертов понаставить — это влегкую. Только вот против порчи памяти толку от ассертов мало.
T>>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин: T>>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
V>Легко в тех же ошибках в многопоточном коде.
Выше ответил.
T>>2) Наличие коллстеков у всех исключений.
V>Помогает только для примитивных ошибок, и доступно для С++ тоже.
Примитивных ошибок большинство и суммарное время, потраченное на их исправление довольно большое. Сократить это время в разы тоже большое дело. В С++ доступно только в теории. На практике куча гемора.
T>>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
V>Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что...
Совсем необязательно что-то там хачить. Достаточно воспользоваться указателем на удаленный блок памяти.
Здравствуйте, Banned by IT, Вы писали:
S>>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои. BBI>Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"?
Что именно? Да хоть вот этот топик прочитать. BBI>Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры.
То есть в четырёх из четырёх проектов, рассмотренных в этом топике? М-м.
BBI>Жуткий говнокод есть и на дотнете, не волнуйся. BBI>Особенно когда пишут индусы и проект в финансовой сфере.
Не волнуюсь. Я про код на дотнете ничего особенного не говорю.
Я говорю о том, что все рассказы про легкодостижимость высокого качества на С++ являются, мягко говоря, преувеличением. BBI>Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша.
Если хотите ужасов, откройте исходники любого проекта, разработанного в институте. Ну там — анализ сейсмограмм, или общёт экспериментов. Только не забудьте взять тазик и резиновые сапоги. BBI>Что говорит о том, что это не С++ а С с классами.
Ну так куда ни плюнь — везде С++ с классами.
Надо полагать, остальные фичи плюсов требуют недоступной на рынке квалификации. BBI>К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API.
Я не в курсе. Я честно гуглил в поиске проектов.
BBI>Не знаю кто тебе рассказывал. Я сам reinterpret_cast и ему подобные не люблю — громоздко а бонусов никаких.
Не будем показывать пальцем, но это был Геннадий Васильев.
BBI>Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ".
Я об этом и говорю.
BBI>Нормально написанных Opensource проектов — единицы.
Давайте в студию хотя бы один этот опенсорс проект. BBI>В основном вот такая вот жуть.
А знаете, почему? Потому, что опенсорс-проекты представляют срез комьюнити. Там точно так же, как и в любом другом проекте, есть несколько сильных программистов (иначе проект вообще не взлетит). А средний уровень в индустрии — именно такой, какой вы видите в опен-соурсе.
BBI>Ты ищешь нормальный код там, где его отродясь не было.
Вы имеете в виду — в С++? BBI>Реальный мир не состоит из одного опенсурса.
Я в курсе. По моему опыту, в среднем всё ещё хуже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
T>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно! На каждую аллокацию для объекта получаем еще одну аллокацию для счетчика. В результате нагрузка на и так тормозной менеджер памяти увеличивается в два раза. А какой размер такого счетчика ссылок? 4 байта? Только для этих 4 байтов в стандартной виндосовой куче будет выделено 16. И спрашивается, на кой черт это надо, не проще ли сразу .NET использовать, а на С++ писать только куски, на которые и умного указателя жалко?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mrTwister, Вы писали:
T>>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно! На каждую аллокацию для объекта получаем еще одну аллокацию для счетчика. В результате нагрузка на и так тормозной менеджер памяти увеличивается в два раза. А какой размер такого счетчика ссылок? 4 байта? Только для этих 4 байтов в стандартной виндосовой куче будет выделено 16. И спрашивается, на кой черт это надо, не проще ли сразу .NET использовать, а на С++ писать только куски, на которые и умного указателя жалко?
FR>http://www.boost.org/doc/libs/1_42_0/libs/smart_ptr/make_shared.html
Здравствуйте, mrTwister, Вы писали:
T>Давай лучше рассмотрим умный указатель со счетчиком ссылок. T>Где этот счетчик надо хранить? В хипе?
Гы, неа
Не, ну можно конечно и в хипе, как тебе больше хочется.
Но вариантов на самом деле куда больше.
Домашнее задание: подумать самому о менее брутфорсных вариантах решения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, mrTwister, Вы писали:
T>>Давай лучше рассмотрим умный указатель со счетчиком ссылок. T>>Где этот счетчик надо хранить? В хипе? BBI>Гы, неа BBI>Не, ну можно конечно и в хипе, как тебе больше хочется. BBI>Но вариантов на самом деле куда больше. BBI>Домашнее задание: подумать самому о менее брутфорсных вариантах решения.
То есть мне надо еще самому смартпоинтеры себе писать?
BBI>>Operator new может быть перекрыт глобально. S>Не смешите мои тапочки. Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами. Этот аллокатор не может себе позволить иметь нетривиальный delete. S>А аллокатор с вырожденным delete не удастся использовать глобально.
Вопрос а нужен ли в большинстве случаев (учитывая RAII) такой аллокатор в C++?
BBI>>И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен. S>
Здравствуйте, Banned by IT, Вы писали:
V>>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII G>>Которым далеко не все пользуются BBI>Все вменяемые — пользуются.
Таких сильно меньше чем вменяемых программистов на .NET
Достаточно посмотреть opensource.
V>>>что совершенно невозможно в дотнете G>>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1. BBI>Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный.
Здравствуйте, Sinclair, Вы писали:
S>>>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои. BBI>>Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"? S>Что именно? Да хоть вот этот топик прочитать.
Тут плюсистов по пальцам пересчитать можно.
BBI>>Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры. S>То есть в четырёх из четырёх проектов, рассмотренных в этом топике? М-м.
Тебе уже привели тот же хром в пример.
BBI>>Жуткий говнокод есть и на дотнете, не волнуйся. BBI>>Особенно когда пишут индусы и проект в финансовой сфере. S>Не волнуюсь. Я про код на дотнете ничего особенного не говорю. S>Я говорю о том, что все рассказы про легкодостижимость высокого качества на С++ являются, мягко говоря, преувеличением. Где, где ты увидел что высокое качество легкодостижимо?
BBI>>Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша. S>Если хотите ужасов, откройте исходники любого проекта, разработанного в институте. Ну там — анализ сейсмограмм, или общёт экспериментов. Только не забудьте взять тазик и резиновые сапоги.
Не, ну там вообще за пределами бобра и козла.
BBI>>Что говорит о том, что это не С++ а С с классами. S>Ну так куда ни плюнь — везде С++ с классами.
Нухз, может ты плюёшь куда то не туда. У меня на расстоянии плевка есть проекты которые без поддержки C++0x просто не соберутся, т.к. используют фичи языка.
S>Надо полагать, остальные фичи плюсов требуют недоступной на рынке квалификации.
Ну берём же мы откуда то квалифицированных людей.
BBI>>К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API. S>Я не в курсе. Я честно гуглил в поиске проектов.
Я просто код history почитал.
BBI>>Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ". S>Я об этом и говорю.
Ты говорил "О да, последнее явно говорит о собственном аллокаторе.". Абы потроллить, не подумав зачем так было там сделано.
BBI>>Нормально написанных Opensource проектов — единицы. S>Давайте в студию хотя бы один этот опенсорс проект.
BBI>>В основном вот такая вот жуть. S>А знаете, почему? Потому, что опенсорс-проекты представляют срез комьюнити.
Какого именно комьюнити?
Из известных мне сильных разработчиков никто не тратит время на опенсурс.
S> Там точно так же, как и в любом другом проекте, есть несколько сильных программистов (иначе проект вообще не взлетит). А средний уровень в индустрии — именно такой, какой вы видите в опен-соурсе.
А средний уровень managed разработчиков тогда выходит это та самая масса говнокодеров, которые приползли туда с почившего вижуалбасика и прочего индусского стаффа, 5 копеек пучок?
BBI>>Ты ищешь нормальный код там, где его отродясь не было. S>Вы имеете в виду — в С++?
Я имею в виду опенсурс.
BBI>>Реальный мир не состоит из одного опенсурса. S>Я в курсе. По моему опыту, в среднем всё ещё хуже.
А средняя температура по больнице 36.6.
И чо?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
S>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем.
S>А нам, дотнетчикам, хочется, чтобы от программистов зависело поменьше. Потому что программисты — компонент самый ненадёжный.
Ваньке на печке тоже много чего хотелось, но чудес не бывает. Уже есть неоднократные случаи, когда дотнетные приложения опять переписывали на нейтив. И не только из-за WPF. Примерные потери на такие "эксперименты" можешь прикинуть сам...
У дотнетных приложений есть своя ниша, где эффективность не важна. Утилиты какие-нить, всякие SOAP-сервисы, генерация HTML и прочее из той же оперы... ИМХО, споры возникают по причине неправильного позиционирования дотнета. Как только обсуждающие сходятся на том, что каждому инструменту своя ниша, так споры утихают сами собой.
Здравствуйте, Ikemefula, Вы писали:
I>Сейчас вдобавок ко всему сказывается сильный спад в образовании, так что сильно кажется точка невозврата в С++ уже давно пройдена. Нативная разработка может и будет набирать обороты, но это точно будет не олдскульный С++, а чтото более гуманное и безопасное.
Если убрать из стандарта C++ приведение в стиле С, то этого было бы достаточно. Никак не могут пойти на этот важный шаг, бо сломается туева хуча программ. Но результат, ИМХО, того стоит, бо всякие reinterpret_cast видны, т.е. не представляют из себя тех самых "незаметных мин" в коде... а во всех остальных местах код будет несильно уступать Хаскелю по типобезопасности.
I>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные. Допускаю, что окружающие тебя 99% коллег пишут на дотнете, это лишь значит, что у тебя такая выборка. Попробуй на досуге набрать в гугле "новости софта", или зайти на любой пиратский торрент и посмотреть в топах, что народ качает. Дотнет там оч редко, только в утилитах каких-нить, администраторских.
Подозреваю, что дотнет цветет и пахнет на рынке заказных программ. Я тоже грешен, делал много подобных халявок, пока не надоело. (Вернее, пока окончательно не разочаровался дотнете, т.к. свою собственную задумку так и не смог на нем заставить работать с нужной отдачей, и рост производительности железа в пересчете на ядро, уже совсем не тот, что раньше). Но это же масштабы разработок не те, напр. такое для одной известной конторки: http://files.rsdn.ru/21096/ss1.PNG
Хотя в рамках проекта был писан полноценный дотнетный ActiveX-host для out of proc COM-серверов, типа офисных приложений (см на вкладки и кнопки на форме с объектом ворда), и всевозможные реализации IPersistentStorage к ним, но это всё-равно несравнимо с реальными проектами... просто на уровне хобби, "посчупать там", "подергать здесь", скуки ради...
Здравствуйте, c-smile, Вы писали:
CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
Мне требуется ликбез. Что в данном случае входит в понятие DOM? Я провел небольшой тест
, по которому получается, что само чтение XAML-а, загрузка его контента, превращение стилей и шаблонов в описательные .Net объекты — вещь достаточно быстрая, плюс вовсю используется отоложенная загрузка по требованию. Однако, построение визуального дерева контролов уже затратная операция. Так вот, DOM — это загруженный описательный контент XAML или сформированное визуальное дерево контролов?
Здравствуйте, mrTwister, Вы писали:
T>>>Давай лучше рассмотрим умный указатель со счетчиком ссылок. T>>>Где этот счетчик надо хранить? В хипе? BBI>>Гы, неа BBI>>Не, ну можно конечно и в хипе, как тебе больше хочется. BBI>>Но вариантов на самом деле куда больше. BBI>>Домашнее задание: подумать самому о менее брутфорсных вариантах решения.
T>То есть мне надо еще самому смартпоинтеры себе писать?
Хотя бы подумай как их можно реализовать не "в лоб".
А то почему то тут всегда предполагают наитупейший вариант имплементации.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
Ага, но при этом 90% софта native. Вот ведь парадокс.
Это ж ведь только с твоей колокольни такой вид открывается.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>>>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1. BBI>>Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный. G>Микротесты на массивах чтоли? А толку от них?
если jit профейлил на простых микротестах то думаешь в более сложной ситуации он поведёт себя лучше?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
BBI>>Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод. S>Можно, я буду это цитировать в будущих спорах с плюсистами?
Можно. Я для тебя даже оформлю цитату:
"Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод." (С)
S>>>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new. BBI>>Operator new может быть перекрыт глобально. S>Не смешите мои тапочки.
А что смешного. Ты утверждаешь что раз используется new то значит нету никакого кастомного аллокатора. Что неверно.
S>Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами.
Такой аллокатор уже порвал .NET GC где то в недрах КСВ.
S> Этот аллокатор не может себе позволить иметь нетривиальный delete.
Может. Почему нет.
Самый простой пример:
Здравствуйте, gandjustas, Вы писали:
G>Микротесты ничего не доказывают так как по их результатам нельзя судить о более сложном коде.
Как раз в тестах с генерацией кода fail в микротесте достаточно наглядно показывает что оптимизация не работает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
V>>И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему. T>А кто тебя заставляет это делать?
Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы.
V>>А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого. И какая разница, почему программа упала, из-за изолированной ошибки или нет? Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range. T>Ну если ты согласился, то и спорить не о чем
Дык, это не тот класс ошибок, который действительно напрягает.
T>Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие!
Если не пользовать механизмы исключений как способ организации логики программы, то до фени быстродействие абсолютно, если уж произошла исключительная ситуация. Не зря C++ потоки не бросают исключений при открытии файла, это нормальная логика, по которой надо всегда делать if, бо там вероятность этой т.н. "исключительной ситуации" чуть ли не 50%. Как раз тут упомянул про эти детские ошибки, наблюдаемые в дотнетных программах: http://www.rsdn.ru/forum/philosophy/4505981.1.aspx
T>А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?
На этапе беты — да, а что?
В клинических случаях даже для релизных продуктов шлем клиентам PDB, просим положить рядом и воспроизвести.
V>>Помогает только для примитивных ошибок, и доступно для С++ тоже. T>Примитивных ошибок большинство и суммарное время, потраченное на их исправление довольно большое.
Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки". И как-то всегда забываете, что далеко не всё может быть поймано во время тестирования, т.е. у клиентов все-равно программы выкидывают ошибку на дотнете аж бегом. А теперь, внимание, что на дотнете мы заплатку слали на следующий день, после баг-репорта (с учетом всех процедур и повторного тестирования), что на С++ аналогично. С т.з. клиента пох глубоко. В общих процедурах по обслуживанию бага, собвственно его поиск и исправление — это капля в море. Ну не 1 мин это заняло, а пол-часа, и что? У клиента баг уже произошел, осадочек остался...
И я опять утверждаю, что дотнетные программы чаще плюют баги у клиентов, чем плюсовые, по итогам наблюдений за 8 лет. И как общую картину исправит тот факт, что на стороне разработчика этот баг потом проще найти? Не принципиально абсолютно. Да и не помню я, чтобы сложные в поиске баги, т.е. занявшие хотя бы пол-дня на поиски, выскакивали чаще, чем раз в несколько лет.
T>Совсем необязательно что-то там хачить. Достаточно воспользоваться указателем на удаленный блок памяти.
Тю, блин, а я то думал... Для этого надо следить за ресурсами в стиле голого С. Начинаем шарманку сначала, или остановимся?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>В С++ стиле это будет так:
... S>А как с массивами, чей размер определяется в процессе выполнения? switch
Там же:
Дык, а в других случаях самописанина ничего не дает в сравнении со стандартными контейнерами. Да и эскалацию привилегий ты при проходе по куче не получишь (по стеку надо идти, чтобы передать куда надо управление в текущем кольце), т.е. не получится той самой дырки в безопасности и обсуждать сразу нечего.
На всяк случай расшифровываю: для случая динамических массивов, т.е. хранящих свое тело на куче, самописные контейнеры будут не лучше уже имеющихся безопасных реализаций из стандартной библиотеки, которые, в свою очередь, безопаснее всего использовать через предоставляемые ими же итераторы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>А как с массивами, чей размер определяется в процессе выполнения? switch
V>Там же: V>
V>Дык, а в других случаях самописанина ничего не дает в сравнении со стандартными контейнерами. Да и эскалацию привилегий ты при проходе по куче не получишь (по стеку надо идти, чтобы передать куда надо управление в текущем кольце), т.е. не получится той самой дырки в безопасности и обсуждать сразу нечего.
V>На всяк случай расшифровываю: для случая динамических массивов, т.е. хранящих свое тело на куче, самописные контейнеры будут не лучше уже имеющихся безопасных реализаций из стандартной библиотеки, которые, в свою очередь, безопаснее всего использовать через предоставляемые ими же итераторы.
Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.
Здравствуйте, FR, Вы писали:
FR>Хоть бы ключик отключающий ввели в массовые компиляторы. FR>Хотя лучше конечно как в D http://www.d-programming-language.org/safed.html выделить безопасное подмножество языка.
А че-то D совсем притих... Никто там его покупать не собирается, случайно?
S>Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.
А кто мешает сделать "точку входа" для любого типа-контейнера, отвечающего стандартам STL?
Это один из примеров насчет того, что типобезопасность времени компиляции дается относительно дешево на шаблонах. Т.е. вместо повторения каждый раз одного и того же критичного кода (в данном случае, проверка размера перед вызовом at(0)), можно сделать самотипизируемую точку входа однократно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.
V>А кто мешает сделать "точку входа" для любого типа-контейнера, отвечающего стандартам STL? V>
V>Это один из примеров насчет того, что типобезопасность времени компиляции дается относительно дешево на шаблонах. Т.е. вместо повторения каждый раз одного и того же критичного кода (в данном случае, проверка размера перед вызовом at(0)), можно сделать самотипизируемую точку входа однократно.
Я прикопался не к типобезопасности, а именно к передаче размера массива темплейт параметром. Если такой метод используется часто с массивами различной длины, то будет взрыв размера бинариев, как я понимаю.
Здравствуйте, samius, Вы писали:
S>А как с массивами, чей размер определяется в процессе выполнения? switch
Контейнеры есть для создания таких массивов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Отлично, но ведь такую точку входа не подружить с
V>Подружить запросто. Перегрузки ф-ий отличаются, будет выбрана более специализированная версия. Перегружается же как-то operator<< для всевозможных типов.
V>Например, у меня стоит такая ловушка для самого общего случая: V>Которая генерит следующую ошибку при отсутствии специализации: V>Для аналогичного показанному в пред.посте случаю есть специализация: V>
а тот template<size_t N> inline void dosomething... был чисто оберткой над небезопасной функцией? Если да, то я зря запаниковал. Я просто подумал, что это и есть сама функция.
S>>Я прикопался не к типобезопасности, а именно к передаче размера массива темплейт параметром. Если такой метод используется часто с массивами различной длины, то будет взрыв размера бинариев, как я понимаю.
V>Да, в первых компиляторах С++ происходил именно взрыв размера бинарника. А потом оптимизатор link-time научился "склеивать" одинаковые куски кода. Что характерно, эта техника работает даже для нешаблонных и даже для виртуальных ф-ий, например:
Я тут как-то налабал комбинаторный парсер CSS на шаблонах. Ну то есть совершенно не постеснялся их использовать по случаю и без, любая комбинация принимала выводила типы параметров-парсеров и выдавала в качестве результата новый тип. Получил 5Мб бинарников. В этом случае оптимизатор link-time ничего сделать не мог даже теоретически.
Пришлось выделять абстракцию и учить комбинаторы работать с ней.
V>Признаюсь, я был сильно в 2002-м году удивлен, когда в релизном коде обнаружил, что getI и getF имеют один и тот же адрес, т.е. вместо двух ф-ий в бинарнике осталась только одна.
V>Для случая doSomething наиболее вероятным будет несколько сгенеренных точек входа (настоящих точек входа, без call и дополнительного фрейма стека, а просто jump потом на общее тело) с инициализацией какого-нить регистра или push в стек разных значений.
Вот, общее тело ведь принимает длину параметром метода, а не template-параметром? Если да, то вопрос снят.
V>Достоверно обещать не могу, это уж как оптимизатор выкрутится для конкретного кода, но использование нескольких легковесных точек входа, без создания лишних фреймов, наблюдаю постоянно. Особенно это неплохо смотрится если помнить, что в современных процах (со времен 2-го пня) безусловный jump занимает ровно 0 тактов.
Я использую точки входа, просто подумал на тот template что он есть общее тело.
, по которому получается, что само чтение XAML-а, загрузка его контента, превращение стилей и шаблонов в описательные .Net объекты — вещь достаточно быстрая, плюс вовсю используется отоложенная загрузка по требованию. Однако, построение визуального дерева контролов уже затратная операция.
Дык, начинает работать "загрузка по требованию".
И не только всего, что связано с XAML, но и всей дотнетной инфраструктуры.
Кроме того, любой биндинг выполняет последовательно все probe на наличие той или иной технологии/соглашений для биндинга и выбирает первый подходящий вариант (см рефлектром). По моим замерам, это в среднем вдвое тормозило в сравнении с WinForms, бо там вариантов меньше рассматривается, и все эти варианты работают на рефлексии.
Ну и помимо прочего, не забываем про большее кол-во библиотек и типов, в т.ч. специализированных генериками, например, чуть ли не каждый экземпляр DependencyProperty — это новый тип, который требует инициализации. А вот иницализация типов — очень затратное дело. Ну и затем инициализация статиков практически в каждом типе WPF, а вызов каждого статического конструктора сопровождается глобальной блокировкой и ожиданием из других потоков (межпотоковые сигналы во всей красе). В общем, много чего набегает.
MM>Так вот, DOM — это загруженный описательный контент XAML или сформированное визуальное дерево контролов?
Елки, ну конечно дерево. Дерево — это и есть описательная часть композиции, которая по описанию строится нейтивным потоком, а XAML — это описание над описанием. Особенно шаблоны.
Здравствуйте, AndrewVK, Вы писали:
V>>Теоретически работает? AVK>Теоретически. Но ты ж за фундаментальное ограничение это выдавал.
Ну да. Просто инлайн, т.е. простая экономия на фреймах стека, это далеко еще не вся оптимизация. Но запрет на трансформацию представления данных, ввиду того, что
в дотнете, вообще все ф-ии экспортируемые с этой т.з. зрения
и там же вывод
т.е. согласно тех же гайдов по оптимизации программ, заведомо делают невозможными подавляющую часть приемов оптимизатора.
AVK>А ты смотрел? Навскидку — основные изменения в 4 рантайме?
Я изменения смотрю по замерам, с некоторых пор.
AVK>Многие оптимизации можно сделать руками. В т.ч. с передвиганием в стек и обратно. Их отсутствие — никак не show stopper.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>Комбинаторные парсеры — это антинаучная лажа. Сорри, но сие так.
А я не наукой занимаюсь.
V>Более менее попытались вывести мат-аппарат для популярного здесь PEG-семейств грамматик (тоже близко к комбинаторным), но почитай критику и тонкие моменты таких парсеров. Я так и не созрел их юзать.
Я тоже, потому и набросал комбинаторные. V>А использовать произвольные комбинаторные парсеры — ну это разве что для "по-быстрому на коленке". Твои 5МB говорят о том, что минипарсеров было оч. много, т.е. на примитивный случай там никак не тянет.
Я написал, что каждый минипарсер представлял собой новый тип, параметризованный типами составляющих минипарсеров. Тут дело не вколичестве минипарсеров, а в глубине комбинаций. А вот как раз глубина комбинаций в CSS нехилая. Т.е. пока мы от тривиальных Char парсеров накомбинируем до stylesheet-парсера, набежит очень много типов парсеров. Когда ввел абстракцию, объем бинариев как рукой сняло, но все равно что-то около мегабайта было. V>Надо было делать как положено: брать семейства GLR/LALR или LL(K). Навскидку, в CSS грамматике оч мало неодногзначностей (или нет совсем, так?), поэтому GLR или LL(1) парсеры будут отрабатывать за время, близкое к O(n), что комбинаторным и не снилось никогда. Ну и размер бинарника собственно парсера максимум в десятки К.
На как положено нет времени, скорость работы парсера не критична. Кстати, XML он парсил не сильно медленнее MSXML (навсикдку).
V>Правда, продолжать тему не буду, уже когда-то ломали копья и по поводу PEG и по поводу комбинаторных парсеров, легче найти те обсуждения, чем повторяться.
Не, не будем. У меня все работает, AST моё, парсеры мои, куда хочу, туда и расширяю, уговаривать переезжать на "как положенные варианты" меня не надо.
V>>>Признаюсь, я был сильно в 2002-м году удивлен, когда в релизном коде обнаружил, что getI и getF имеют один и тот же адрес, т.е. вместо двух ф-ий в бинарнике осталась только одна. S>>
V>угу, размер-то типов одинаков, т.е. в терминах машинного кода всё одинаково.
И поле по тому же смещению... Совпадение. Рассчитывать на такую пруху, наверное не стоит.
S>>Вот, общее тело ведь принимает длину параметром метода, а не template-параметром? Если да, то вопрос снят.
V>ммм... поясни мне, чем для снипета: V>
V>std::copy(src, src + size, dst);
V>
V>разница, откуда был взят size, из параметра шаблона, или как константный параметр ф-ии? Для шаблонного, то бишь инлайного исполнения, эта разница стирается.
Смущен. стоит ли мне напоминать о том, что константный параметр функции может быть определен во время выполнения, а параметр шаблона должен быть определен во время компиляции?
V>Это код относительно безопасен в месте декларации (т.к. в одном экземпляре и скрее всего обложен юнит-тестом), но опасен во всевозможных местах вызова из всех сценариев и оперируемых типов данных, поэтому его неплохо иметь во внутреннем неймспейсе или в приватном методе, а в открытых иметь типобезопасные инлайные "точки входа".
Согласен.
S>>Я использую точки входа, просто подумал на тот template что он есть общее тело.
V>Иногда он и есть единственное и неповторимое тело, если сами пишем, какие проблемы?
Проблемы в размере бинарников, если неповторимое нетривиальное тело параметризовано size-ом. Так, например, если я в основу CSS парсера клал тривиальные парсеры char-ов в виде CharParser<char C>(), то размер бинарника увеличивался на десятки килобайт по сравнению с использованием CharParser(char c). Что уж говорить о более высокоуровенвых комбинациях.
V>Все-равно внутри будет вызвана итерация по элементам через какой-нить STL/boost algorithm с каким-нить bind-замыканием, так что "точкой входа" было бы неплохо сделать код, выполняющий итерирование. И для контейнеров, совместимых с STL, тоже. Поэтому код точек входа мог быть другой, чем я приводил, если бы целевое тело писалось нами, а не было бы неким АПИ в стиле С, над которым мы делаем типобезопасные обертки.
Я теперь очкую размножить какой-нибудь код, потому обертки делаю, а нетривиальные тела делаю без template параметризации по мере возможности.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Klatu, Вы писали:
V>>>>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. K>>>>ну это просто вранье или полная некомпетентность ГВ>>>Слушай, найди какой-нибудь другой аргумент, а? K>>Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил [...]
ГВ>На этом варианты закончились? Только глобальное/статическое?
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, Klatu, Вы писали:
K>>Я пока что не встречал более пафосных говнокодеров, чем на С++. Вот это — точно медицинский факт. Каждое нубло, которое накропало пару примитивных программок на С++ — уже считает себя гуру BBI>Брысь зелёный, еды не будет. Тоньше надо троллить, тоньше!
да у вас троллефобия, голубчик. не запускайте, это опасно
Здравствуйте, samius, Вы писали:
V>>угу, размер-то типов одинаков, т.е. в терминах машинного кода всё одинаково. S>И поле по тому же смещению... Совпадение. Рассчитывать на такую пруху, наверное не стоит.
Разумеется не стоит. Задача компилятора колдовать как угодно, но обеспечить исходную семантику. Где повезет, там повезет. Но чем больше проект, тем больше доля относительного везения.
S>Смущен. стоит ли мне напоминать о том, что константный параметр функции может быть определен во время выполнения, а параметр шаблона должен быть определен во время компиляции?
Дык, и исходная размерность может быть известна не только в compile-time. Да и уточнил уже ниже абзацем.
V>>Иногда он и есть единственное и неповторимое тело, если сами пишем, какие проблемы? S>Проблемы в размере бинарников, если неповторимое нетривиальное тело параметризовано size-ом. Так, например, если я в основу CSS парсера клал тривиальные парсеры char-ов в виде CharParser<char C>(), то размер бинарника увеличивался на десятки килобайт по сравнению с использованием CharParser(char c). Что уж говорить о более высокоуровенвых комбинациях.
Вообще, для случая inline-исполнения оба варианта эквивалентны, и там и там протягивается константа времени компиляции. Ты, случайно, не определял тела методов за пределами класса без inline?
Есть еще версия, что уровень максимальной вложенности, рассматриваемый компилятором, ограничен (оно так и есть, иначе бы программа компиллировалась бесконечно, бо слишком много комбинаций получалось бы на самом верхнем уровне). Но мы не знаем ни уровня такой вложенности компилятора (для GCC недавно было 8 вроде), ни получаемого у тебя уровня вложенности на верхнем уровне.
Возможно, стоило вывести несколько "промежуточных" достаточно высокоуровневых фиксированных типов парсеров (параметризируемых обычными аргументами, а не шаблонными), именно на них уменьшив общее комбинаторное число, а не на самых низкоуровневых. Смотреть надо и пробовать.
V>>Все-равно внутри будет вызвана итерация по элементам через какой-нить STL/boost algorithm с каким-нить bind-замыканием, так что "точкой входа" было бы неплохо сделать код, выполняющий итерирование. И для контейнеров, совместимых с STL, тоже. Поэтому код точек входа мог быть другой, чем я приводил, если бы целевое тело писалось нами, а не было бы неким АПИ в стиле С, над которым мы делаем типобезопасные обертки. S>Я теперь очкую размножить какой-нибудь код, потому обертки делаю, а нетривиальные тела делаю без template параметризации по мере возможности.
А я просто пользуюсь тем, что декомпозиция в С++ практически бесплатна, в отличие от. Оч удобно декомпозировать на совсем маленькие типы с некоторым заведомо безопасным интерфейсом, с проверкой всех контрактов и прочим, затем построить глобальные операции вокруг таких типов (тоже оч удобно в отличие от ). В таком подходе высокоуровневые объекты "по месту" собираются уже из отлаженных запчастей такой инфраструктуры, которая получается высокоуровневой сама по себе, потому что в прикладном коде мы уже оперируем прикладными сущностями из инфраструктуры.
В этом и есть С+ философия: как можно больше прикладной логики отразить во взаимоотношениях типов и операций м/у ними. Т.к. операции порой довольно-таки обоюдные, чтобы не ломать голову, методом какого объекта организовать операцию, её таки удобнее делать глобальной на основе самого базового публичного интерфейса прикладных типов (которые суть отвечают за безопасность и соблюдение инвариантов приватного состояния).
Более высокоуровневые типы и операции м/у ними строятся точно так же на основе низкоуровневых и далее по иерархии, и вот тут, если принять некие единообразные правила игры, то типизируемость на шаблонах начинает показывать весь свой профит. Потому как они действительно многократно повторно используемы могут быть лишь в глобальных ф-ях, обслуживая от простых операций, до целых сложных "паттернов" (местного разлива в т.ч.) в отличие от, где низкое повторное использование кода, да еще с ограничением размещения лишь в методах, и где библиотечная/обобщенная реализация паттернов затруднительна, из-за ограничений технологии генериков.
Здравствуйте, vdimas, Вы писали:
V>Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем.
Осталось показать код. А то получается, что теоретически программисты владеют всеми приёмами на уровне мозжечка, а на практике пишут совершенно без них.
V>У дотнетных приложений есть своя ниша, где эффективность не важна. Утилиты какие-нить, всякие SOAP-сервисы, генерация HTML и прочее из той же оперы... ИМХО, споры возникают по причине неправильного позиционирования дотнета. Как только обсуждающие сходятся на том, что каждому инструменту своя ниша, так споры утихают сами собой.
Ну, это правда. Да.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Проблемы в размере бинарников, если неповторимое нетривиальное тело параметризовано size-ом. Так, например, если я в основу CSS парсера клал тривиальные парсеры char-ов в виде CharParser<char C>(), то размер бинарника увеличивался на десятки килобайт по сравнению с использованием CharParser(char c). Что уж говорить о более высокоуровенвых комбинациях.
V>Вообще, для случая inline-исполнения оба варианта эквивалентны, и там и там протягивается константа времени компиляции. Ты, случайно, не определял тела методов за пределами класса без inline?
Случайно тела методов были в теле класса. Те методы однострочные, жалко было места для дублирования сигнатуры. Но раз я обнаружил разницу в размере бинарников, то очевидно что варианты не эквивалентны. Тем более, что класс во втором случае имеет поле, в котором хранит переданный в конструкторе char.
V>Есть еще версия, что уровень максимальной вложенности, рассматриваемый компилятором, ограничен (оно так и есть, иначе бы программа компиллировалась бесконечно, бо слишком много комбинаций получалось бы на самом верхнем уровне). Но мы не знаем ни уровня такой вложенности компилятора (для GCC недавно было 8 вроде), ни получаемого у тебя уровня вложенности на верхнем уровне.
комбинаций немало (http://www.w3.org/TR/CSS2/grammar.html#scanner, http://www.w3.org/TR/CSS2/grammar.html#grammar)
V>Возможно, стоило вывести несколько "промежуточных" достаточно высокоуровневых фиксированных типов парсеров (параметризируемых обычными аргументами, а не шаблонными), именно на них уменьшив общее комбинаторное число, а не на самых низкоуровневых. Смотреть надо и пробовать.
Я так и сделал. Параметризовал тип парсера лишь типом его результата, и убрал типы парсеров-участников комбинации.
S>>Я теперь очкую размножить какой-нибудь код, потому обертки делаю, а нетривиальные тела делаю без template параметризации по мере возможности.
V>А я просто пользуюсь тем, что декомпозиция в С++ практически бесплатна, в отличие от. Оч удобно декомпозировать на совсем маленькие типы с некоторым заведомо безопасным интерфейсом, с проверкой всех контрактов и прочим, затем построить глобальные операции вокруг таких типов (тоже оч удобно в отличие от ). В таком подходе высокоуровневые объекты "по месту" собираются уже из отлаженных запчастей такой инфраструктуры, которая получается высокоуровневой сама по себе, потому что в прикладном коде мы уже оперируем прикладными сущностями из инфраструктуры.
Если я все верно понял, то это справедливо не только для C++
V>В этом и есть С+ философия: как можно больше прикладной логики отразить во взаимоотношениях типов и операций м/у ними. Т.к. операции порой довольно-таки обоюдные, чтобы не ломать голову, методом какого объекта организовать операцию, её таки удобнее делать глобальной на основе самого базового публичного интерфейса прикладных типов (которые суть отвечают за безопасность и соблюдение инвариантов приватного состояния).
V>Более высокоуровневые типы и операции м/у ними строятся точно так же на основе низкоуровневых и далее по иерархии, и вот тут, если принять некие единообразные правила игры, то типизируемость на шаблонах начинает показывать весь свой профит. Потому как они действительно многократно повторно используемы могут быть лишь в глобальных ф-ях, обслуживая от простых операций, до целых сложных "паттернов" (местного разлива в т.ч.) в отличие от, где низкое повторное использование кода, да еще с ограничением размещения лишь в методах, и где библиотечная/обобщенная реализация паттернов затруднительна, из-за ограничений технологии генериков.
генерики они другие. На темплейтах можно делать то, что нельзя на генериках и наоборот. Например, был жестоко обломан тем что темлейт функции-мемберы не могут быть виртуальными
Вот еще пример, рекурсивный полиморфизм невозможно юзать во времени выполнения в C++, но вполне работает в C#. Если что — я об Purely Functional Data Structures (Queues based on implicit recursive slowdown).
Здравствуйте, Klatu, Вы писали:
K>>>Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил [...] ГВ>>На этом варианты закончились? Только глобальное/статическое? K>ну попробуй придумай другой вариант
Слишком длинный список получится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mrTwister, Вы писали:
ГВ>>Если ты заметил, то я на все случаи свой опыт не экстраполирую. Напротив, я говорю о некорректности таких экстраполяций. T>Ну ты же говоришь, что мол в реальности этих ошибок почти нет. Я охотно верю, что при разработки продукта силами компактной замкнутой команды педантичных плюсовиков этих проблем не будет. Но, к сожалению, не каждый продукт можно разработать в таком режиме за приемлемые сроки.
Это мои проблемы? Ищите нормальных плюсовиков, или хотя бы не распугивайте тех, кто есть.
ГВ>>Сама по себе управляемость, может быть, не при чём. А вот гарантирование корректности ссылок — очень даже при чём. T>Ты бы предпочел UB?
Я не знаю, как могла бы выглядеть упомянутая возможность.
ГВ>>Нет, комната стала тёмной по другим причинам. Пафосно выражаясь, C++ — это были те искры, которые позволили найти выход из этой комнаты. T>Предпочитаю фонарик в виде assert искрам из глаз в виде AV
Аналогично. По сути я рассказал историю о поиске двух ошибок: в managed и в unmanaged. Ошибка в unmanaged — как раз пропущенная проверка инварианта.
ГВ>>Без исходного кода я ничего посоветовать не могу. Если хочешь, свяжись по мылу, может быть, что-нибудь придумаем. T>А исходный код тебе ничего не даст. Тот код, что упал вполне себе невинен. Проблема в том, что кто-то испортил общий хип. [...]
Короче, исходники ты мне давать не собираешься? Тогда говорить не о чем. И — да, программы на C++ сейчас принято писать как набор раздельно тестируемых компонент.
ГВ>>А... Я подумал про design contracts из FW 4. Ну так assert-ом по сути и спаслись. T>Ну вот видишь. Ассерт — мощная штука, но его не повесишь на порчу памяти.
Спасибо, рассказал. А то я был не в курсе.
ГВ>>Во-во, знакомо. Ошибка — это только если exception, всё остальное — "так и надо". T>Не совсем. Ошибка — это несоответствие требованиям. Все остальное — "так и надо".
Вот как раз о неудовлетворении некоторых требований речь и идёт.
ГВ>>>>Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи. T>>>В дампе ты бы увидел, что было создано два объекта вместо одного. Дальше все тривиально.
ГВ>>Ничего бы я там не увидел... Да и собственно, я говорил о совершенно других вещах. T>Почему не увидел? Ты хотел привести пример трудноуловимой с точки зрения плюсовика ошибки. Тебе она кажется трудноуловимой, потому что ты не привык [после слова "привык" остальное можно не читать].
Трудноуловимость связана ещё и с количеством одновременно существующих объектов, временем их жизни... Короче, дампом не отделаешься.
T>Ну вот, например, как ты в windbg для С++ сможешь сдампить все объекты заданного типа? Или все произошедшие в последнее время исключения (очень полезно при разборе говнокода, маскирующего исключения)?
Никак, но оно никогда мне и не требовалось. Кроме редких и довольно давних случаев.
ГВ>>Тоже справедливо. А исходников этого самого чужого кода у меня нет? T>Исходники есть. Но править ты их не можешь.
Ну смотреть-то могу?
T>>>Это говорит о том, что в С++ проблемы можно получить в любом месте и фраза, что неверная интерпретация памяти бывает только [подставить что-то одно] ложная. Неверная интерпретация памяти может произойти по миллиону причин. И для каждой такой причины можно ответить: "надо делать то-то". ГВ>>Так и надо делать "то-то". T>Совершенно верно. То есть другими словами, не надо делать ошибок. Но люди их все равно делают, это данность. В случае с С++ многие такие ошибки оборачиваются большими потерями времени.
Да, правильно, и что? Собственно топик о том, что снова набирают силу аргументы типа Perf/Watt, Perf/Cycle, Perf/Cent. Ы?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Klatu, Вы писали:
K>>>>Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил [...] ГВ>>>На этом варианты закончились? Только глобальное/статическое? K>>ну попробуй придумай другой вариант
ГВ>Слишком длинный список получится.
Ясно. Значит, придумать ничего вразумительного не смог.
ГВ>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
А можно поподробнее мне объяснить, за счёт чего произойдёт этот "ой"?
Вот я обращаюсь int a = p->m_InstanceCount. Понятное дело, что никаких AV я не дождусь — AV работают только если я далеко промахнулся мимо памяти программы. А тут всё по прежнему в пределах хипа, всё в порядке.
Прочитал я себе целую переменную и пошёл хреначить дальше. Продолжу работать с чем-то другим — 0xDEADBEEF если повезло, или, скажем, с 0, если не повезло и в это место распределился совершенно другой объект. Всё выглядит нормально, только глючит неестественным образом.
Или, ещё лучше, я пишу p->m_InstanceCount--. Кто ж его знает, что я там такое декрементировал?
За счёт какой магии я получу "ой", и в чём он выразится?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А можно поподробнее мне объяснить, за счёт чего произойдёт этот "ой"? S>Вот я обращаюсь int a = p->m_InstanceCount. Понятное дело, что никаких AV я не дождусь — AV работают только если я далеко промахнулся мимо памяти программы. А тут всё по прежнему в пределах хипа, всё в порядке.
Ну а теперь, давай сделаем простую индукцию. Код принципиально рассчитан на работу в одном потоке, следовательно, хитрых смарт-пойнтеров в нём делать не будут. Просто ни к чему. А значит, вызывающий код с некоторой очень ненулевой вероятностью будет выглядеть примерно так:
void processData() {
while(...) {
delete m_pData;// <- вот тут и будет "ой"
m_pData = callReadingCode();
int x = m_pData->prop1;
// ...
}
}
Может быть, какой-то смарт-пойнтер, конечно и будет на случай исключений, но без особых наворотов.
S>Прочитал я себе целую переменную и пошёл хреначить дальше. Продолжу работать с чем-то другим — 0xDEADBEEF если повезло, или, скажем, с 0, если не повезло и в это место распределился совершенно другой объект. Всё выглядит нормально, только глючит неестественным образом.
На практике чаще всего выстреливается сообщение о развале хипа.
S>Или, ещё лучше, я пишу p->m_InstanceCount--. Кто ж его знает, что я там такое декрементировал? S>За счёт какой магии я получу "ой", и в чём он выразится?
За счёт разваливания разметки динамической памяти (хипа). Да-да, ты не ослышался.
P.S.: Ой, что сейчас начнётся...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Заблуждение. Если бы отлавливались при тестировании, их бы не было. А по факту на сегодня я не видел еще ни одной достаточно большой дотнетной неглюкавой программы. Хреново в дотнете со статикой-то, а в динамике не всё поймаешь, бесконечным и дейтсвительно всеобъемлющим тестирование не бывает, это миф, бо такое тестирование на пару порядков обойдется дороже собственно разработки.
А у меня их и нет. IndexOutOfRange уже забыл когда получал, NRE в продакшене был крайний раз года два назад.
Причем тупо потому что не использую for, и не передаю null (это контрактами проверяется).
Тестирование позволяет гораздо более сложные ошибки выловить.
T>>>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. V>>>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference? G>>Стектрейс, хотя для nre в продакшене надо сильно постараться
V>Не льсти себе. Тебя послушать как в дотнете, то "надо просто контрактами обложить", а как в С++, то "обязательно нарушат контракт". Эдак можно много до чего договориться.
См выше. Я не пытаюсь льстить, это прерогатива C++ников, я только привожу свои наблюдения.
V>По моим наблюдениям за глюкавостью дотнетных программ, они ловятся на совершенно детских тестах: например часто при попытке сохранить файл в директорию, защищенную от записи или почти в 100% случаев, при исчерпании какого-нить ресурса (кол-ва сокетов, поверхностей для рисования, свободного места на диске). Такое ощущение, что дотнетчики поголовно пишут код из расчета "всё будет хорошо", проверяя максимум контракты на входные параметры методов, во всех остальных случаях тупо плюя эксепшен, который (удивительно!) никто нигде не ждет.
Так это же прекрасно, если вылетит exception то его быстрее поправят чем если он не вылетит. Писать в стиле let it crash полезно даже для десктопа, потому что позволяет быстро повесить обработку exception на верхнем уровне и выдавать пользователю адекватное сообщение.
V>Понятие безопасного к исключениям кода — это нечто из другой реальности,\
Именно, так как в .NET exception может вылететь где угодно. Пытаться писать код который не кидается исключениями — слишком затратно и абсолютно бесполезно.
V>отсюда дотнет — просто рассадник наведенных ошибок (по опыту своей помощи в ловле ошибок коллег), бо после первой же обработанной (якобы обработанной) ошибочной ситуации, отваливается работоспособность в другом месте, потому как один или несколько объектов остаются в некоем промежуточном невалидном состоянии.
Ты уже взаимоисключающие вещи писать начал. То тебе не нравится что валятся эксепшены, то не нравятся как их обрабатывают.
Кстати адекватно обрабатывать эксепшены могут довольно малое число программистов, причем независимо от языка и платформы.
V>И хоть подобные ошибки от платформы не зависят, но почему-то дотнетные программы болеют ими чаще, по моим сугубо личным наблюдениям.
Да, тупо порог вхождения ниже. И это прекрасно, .NET позволяет создавать достаточно хорошие продукты с меньшими затратами в среднем.
V>Да, "вы" правы, на плюсах в среднем приходится быть малость внимательней, чем на дотнете, но зато типичных детских ошибок вижу всяко поменьше. ИМХО, от рабочего настроя тоже кое-что зависит. А в дотнет диктует некий расслабон (даже по собственным ощущениям, в сравнении с писаниной на плюсах).
Это смотря то считать типичной ошибкой. Самая типичная ошибка с C++ которую я видел — обращение по невалидному указателю, которое вызывает в лучшем случае AV по месту вызова, а в худшем — перезапись стека или других объектов (наведенная ошибка). Для делфи напрмиер типичная ошибка — неосвобождение памяти, 95% программ на делфи, что я видел, текли. Для .NET типчная ошибка — возврат null и отсутствие проверки, то в худшем случае приводит nre где-то в другом методе.
V>>>Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что... G>>Вот только по-умолчанию C# рождает safe код, а unsafe без необходимости даже не ошибка, а вредительство. С++ имеет тяжелое наследие C и не наказывает за попытки писать в стиле С, то есть любой код по умолчанию — unsafe.
V>А как меня наказвают за исопльзование unsafe в дотнете, не пояснишь?
1 )Компилятор по умолчанию запрещает
2) Без fulltrust не работает
3) В некоторых реализациях .NET просто отсутствует
V>И почему хак типов в стиле C есть на твой взгляд "нормально"?
Потому что так пишут.
G>>Использование только safe части C++ делает программу не быстрее (а зачастую и медленнее) чем .NET
V>Стоило бы просить обосновать, но вряд ли справишься. По моим наблюдениям — ровно наоборот, чем больше типизированной информации у компилятора, тем агрессивнее оптимизация.
Только компилятор C++ может использовать такую информацию только в шаблонах. В других местах он бессилен, слишком нестрогая семантика досталась в наследство от C.
V>И да, safe С++ не означает только библиотеки STL. Это просто типизированный подход, например, набивший оскомину выход за пределы массива на стеке, стиле С это так: V>
V>void doSomething(char * array, size_t size);
V>char array[N];
V>doSomething(array, sizeof(array)); // вот здесь могут подать не тот sizeof в результате многих актов рефакторинга
V>
Совершенно бесполезный пример. Я вот порылся в своих проектах и знаешь сколько у меня массивов с фиксированным на момент компиляции числом элементов? Я насчитал ровно 3 за полгода.
Даже не буду считать насколько ничтожный выйгрыш типа_безопасность даст с таком случае если даст еще.
V>>>Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки G>>Ага, только они очень часто встречаются в unmanaged. V>В сравнении с остальными ошибками, в т.ч. логическими — не видно и под микроскопом. Какая разница, падает программа или неверно работает? Лажа в обоих случаях.
Ты еще не учел что такие ошибки могут приводить к проблема безопасности: повышение привелегий, раскрытие информации, отказ в обслуживании.
V>>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII G>>Которым далеко не все пользуются
V>Ну я же говорил. V>Рассуждая так, и контракты в C# мало кто проверяет, это же прямо такое "хакерство" (С).
Контрактами в .NET пользуются еще меньше, чем RAII, но это другой уровень проверок и гарантий.
90% raii уже выполняет clr, ему не хватает только escape-анализа для idisposable объектов чтобы явно не писать using.
V>>>и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии G>>Ну это когда размер известен на этапе компиляции.
V>Дык, а в других случаях самописанина ничего не дает в сравнении со стандартными контейнерами. Да и эскалацию привилегий ты при проходе по куче не получишь (по стеку надо идти, чтобы передать куда надо управление в текущем кольце), т.е. не получится той самой дырки в безопасности и обсуждать сразу нечего.
Почитай Secure Code, там описано какие уязвимости несет проход по куче. Кроме эскалации привилегий есть еще проблемы.
V>>>что совершенно невозможно в дотнете G>>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1. V>Это если мы по всему массиву итерируем, а если нет, то лишней проверки не избежать. Уже обсуждали 4 года назад.
Да, тогда получается дешевле сделать копию и бегать по ней. А там где performance нужен можно бегание по массиву переписать на C. Те же 4 года назад обсуждали.
V>>>Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак. G>>v.end()++ не?
V>Не. Кто мешает мне компилируемую бредятину и на C# писать с тем же успехом? V>Чем не коровья лепешка? V>
то что ты пишешь — называется вредительством, а код вроде for(auto i = v.begin(); i<=v.end(); i++) { } вполне можно и неспециально написать.
В .NET будет outofrange, а в C++ что? Heap Corruption?
G>>Кроме того даже если ты напишешь safe код, то менее грамотный коллега напишет unsafe, который заставит твой код работать неправильно.
V>Менее грамотный, это год работы. Кто ж ему даст весь код трогать? В любом проекте при хоть какой-то организации полно изолированных мест, где могут разгуляться разработчики любого уровня. Ну и code review определенно рулит.
Code Review не отменяет недостатки языка.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
Да, и managed программа будет работать и работать корректно. В unmanaged в лучшем случае упадет. Разницу понимаешь?
ГВ>>>>>2) Managed-код превосходно замаскировал ошибки concurrency и маскировал бы их дальше, если бы именно unmanaged не разорался во всю глотку о том, что что-то пошло не так. G>>>>То есть managed код работал, а unmanaged таки падал? Ведь именно unmanaged не был спроектирован под cuncurrency. ГВ>>>Умничка. Именно дотнетный код — работал. Ну, по вашему же, если эксцепшенов нет, значит код — работает! Возьми с полки пирожок. Ты, кстати, не у конкурентов, часом работаешь? Надо посоветовать, чтобы тебе зарплату подняли. Скажи, эдипов папа посоветовал. G>>Не уходит от вопроса. Ты не написал что были какие проблемы непосредственно в managed, ты сказал что он не так вызывал unmanaged, но сам unmanaged этому никак не противился.
ГВ>Да банальные проблемы — несколько потоков лезли одновременно к одному и тому же объекту без синхронизации.
И что? При обращении к любому объекту надо синхронизироваться чтоли? Или на нем как-то написано? В .NET принято в документации указывать о threadsafety.
Давай конкретику что за unmanaged был и что с ним managed делал?
G>>То есть переписал unmanaged так чтобы не было этих проблема можно было вообще исключить эту проблему. ГВ>Там было написано: соответствующая проверка была убрана ради оптимизации.
Ага, "ради оптимизации" теперь отмазка чтобы писать ненадежный код? Это "ради оптимизации" было зафиксировано в документации? И что вообще код делал?
ГВ>>>>>3) Если бы не unmanaged, поиски тщательно замаскированной ошибки стали бы для нас чем-то вроде специальной олимпиады: главное не победа, главное — держаться подальше; G>>>>Без unmanaged скорее всего косяк был бы найден раньше ибо в managed из unmanaged не попадет сведений о threading model вызываемого кода. ГВ>>>Без unmanaged ошибка не была бы найдена вообще. Но она от этого никуда бы не делась G>>А в чем тогда ошибка? И почему она не была бы найдена? Или ты что-то не договариваешь ил просто пытаешься свалить вину.
ГВ>Скажем так: unmanaged создавал некий объект, который передавался в managed, читал он его из некоей большой-пребольшой базы данных (действительно большой, но это к делу не относится). Один вызов unmanaged — один новый объект. В дальнейшем эти объекты с данными поочерёдно помещались в поле объекта-получателя и юзались как read-only (до следующей транзакции). Грубо где-то так:
ГВ>
ГВ>public class SomeDataProcessing {
ГВ> // Текущая порция данных
ГВ> SomeData portion;
ГВ> // Чтение данных обращением к unmanaged
ГВ> public void readDataPortion() {
ГВ> portion = callUnmanagedCode();
ГВ> }
ГВ> // Цикл обработки. Работает в отдельном потоке.
ГВ> public void processData() {
ГВ> while(...) {
ГВ> readDataPortion();
ГВ> // Обработка того, что положили в portion:
ГВ> int a = portion.prop1;
ГВ> int b = portion.prop2;
ГВ> // ...
ГВ> }
ГВ> }
ГВ>}
ГВ>
ГВ>То есть вызывающему коду было без разницы, в скольки потоках работать — данные он не модифицирует, только читает. И если чтение вдруг происходит в два потока, то один из полученных объектов пропадает (portion-то у нас одно, правильно?), и оба обратившихся потока будут пользоваться ссылкой на один объект данных. Но никаких конфликтов в managed-коде эта ситуация не вызовет. Разве что когда-то потом могло быть отслежено нарушение целостности данных... Но это же ещё надо сначала это нарушение обнаружить, а для этого нужно создать специфичные условия, чтобы два потока создались вместо одного, а в тестовых условиях всё тихо.
Тут получается что просто не договорились между managed и unmanaged о tread safety. Вообще по-умолчанию считается что любой код в .NET не threadsafe, особенно итераторы. Но данный код не совсем итератор и по внешнему виду делать вывод сложно.
Здравствуйте, Banned by IT, Вы писали:
I>>А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол. BBI>Ага, но при этом 90% софта native. Вот ведь парадокс.
Кто тебе такое сказал ?
BBI>Это ж ведь только с твоей колокольни такой вид открывается.
Нативный софт начали писать еще в 80х и с каждым годом в общей массе его становится меньше и меньше.
Так что, извини, я тебя невольно запутал.
ГВ>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом. S>А можно поподробнее мне объяснить, за счёт чего произойдёт этот "ой"? S>Вот я обращаюсь int a = p->m_InstanceCount. Понятное дело, что никаких AV я не дождусь — AV работают только если я далеко промахнулся мимо памяти программы. А тут всё по прежнему в пределах хипа, всё в порядке.
Да, правильно. AV в данном случае, скорее всего не будет, хотя это совсем не обязательно: если ты читаешь не целое число, а какой-нибудь указатель по указателю, то можешь налететь и на AV. В общем, куча загадочных эффектов таки случится.
S>Прочитал я себе целую переменную и пошёл хреначить дальше. Продолжу работать с чем-то другим — 0xDEADBEEF если повезло, или, скажем, с 0, если не повезло и в это место распределился совершенно другой объект. Всё выглядит нормально, только глючит неестественным образом.
DEADBEEF — это, считай, удача.
S>Или, ещё лучше, я пишу p->m_InstanceCount--. Кто ж его знает, что я там такое декрементировал? S>За счёт какой магии я получу "ой", и в чём он выразится?
Никакой магии. Банальная ошибка, которыми вы тут всех пугали, со всеми её прелестями и непредсказуемостями. Разница только в том, что managed такую ошибку не продиагностирует вообще никак, а unmanaged — хоть как-то.
Похоже, что у нас с тобой просто разное отношение к таким ошибкам: я к ним отношусь без излишнего паникёрства. Понятно, что в качестве нормы такой подход к диагностике ошибок использовать нельзя, но если уж ошибка допущена, то...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Banned by IT, Вы писали:
I>>Может и ничего не стоит. А кто её умеет и где посмотреть продукты, где бы эта безопасность что ничего ен стоит была использована ? Я чет как ни залезу в чей нибудь С++ код, так вечно хаос с указателями. Такое ощущение что RAII еще не изобрели или изобрели но не рассказали, как правильно им пользоваться
BBI>Ну извини. То, что тебя окружают индусокодеры означает совсем не это.
Здравствуйте, Banned by IT, Вы писали:
I>>По трудоёмкости может и не стояли рядом, но глядя на обилие ошибок с указателями в сиплюсных программах, как то возникает сомнение что люди в общей массе вообще способны освоить эти указатели BBI>Встречал людей которые в принципе не могли понять как работает указатель и как им пользоваться. Т.е. в принципе не понимали. Как работает индекс по массиву — понятно, а как работает BYTE* по flat оперативке — полный ступор и пустота в глазах.
Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём. Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ...
Здравствуйте, vdimas, Вы писали:
I>>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.
V>Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные.
и много этих популярных программ ?
>Допускаю, что окружающие тебя 99% коллег пишут на дотнете, это лишь значит, что у тебя такая выборка.
Неправильное допущение и выводы следовательно неправильные.
>Попробуй на досуге набрать в гугле "новости софта", или зайти на любой пиратский торрент и посмотреть в топах, что народ качает. Дотнет там оч редко, только в утилитах каких-нить, администраторских.
Расклад по тому, что нынче пишется в каких объемах можно сделать тупо по количеству вакансий. Как то я не вижу значительного кол.ва вакансий на с++ и не вижу, что бы ЗП в с++ отражали спрос на с++
Здравствуйте, vdimas, Вы писали:
V>Кроме того, любой биндинг выполняет последовательно все probe на наличие той или иной технологии/соглашений для биндинга и выбирает первый подходящий вариант (см рефлектром). По моим замерам, это в среднем вдвое тормозило в сравнении с WinForms, бо там вариантов меньше рассматривается, и все эти варианты работают на рефлексии.
В моем примере сплошные шаблоны контролов, поэтому там нет Рефлексии. Привязка свойств двух DependencyObject работает без нее.
V>Ну и помимо прочего, не забываем про большее кол-во библиотек и типов, в т.ч. специализированных генериками, например, чуть ли не каждый экземпляр DependencyProperty — это новый тип, который требует инициализации. А вот иницализация типов — очень затратное дело. Ну и затем инициализация статиков практически в каждом типе WPF, а вызов каждого статического конструктора сопровождается глобальной блокировкой и ожиданием из других потоков (межпотоковые сигналы во всей красе). В общем, много чего набегает.
Не понимаю, почему каждый DependencyProperty — это новый тип? Тип всегда один — DependencyProperty. Затраты на DependencyProperty.RegisterCommon вышли еще меньше, чем сборка мусора. И потом, я все объекты создаю до того, как WPF вступает в действие, поэтому инициализация статики — ничтожная вещь. Тяжелым получилось воплощение XAML в контролах, но ведь и контролов у меня свыше 5000(!). Если уменьшить до 75 скажем, то затраты по WPF составляют лишь 25% времени. В-общем, я пришел к выводу, что долгий старт не столько из-за WPF, сколько из-за .Net в принципе. Студия 2010-я, кстати, тоже тому пример. Первый запуск долгий, повторный — почти что пшик. И это мой рабочий комп всего с 2 Гб оперативы
Здравствуйте, samius, Вы писали:
V>>Вообще, для случая inline-исполнения оба варианта эквивалентны, и там и там протягивается константа времени компиляции. Ты, случайно, не определял тела методов за пределами класса без inline? S>Случайно тела методов были в теле класса. Те методы однострочные, жалко было места для дублирования сигнатуры. Но раз я обнаружил разницу в размере бинарников, то очевидно что варианты не эквивалентны. Тем более, что класс во втором случае имеет поле, в котором хранит переданный в конструкторе char.
Ну и что, если объект временный на стеке, его класс инлайный, происходит инициализация значением времени компиляции — это одно и то же в итоге. В общем, надо посмотреть на код, тогда я мог бы не гадать на кофейной куче... Может у тебя подчиненные парсеры хранятся как мемберы более высокоуровневых. Тоды ой.
V>>Есть еще версия, что уровень максимальной вложенности, рассматриваемый компилятором, ограничен (оно так и есть, иначе бы программа компиллировалась бесконечно, бо слишком много комбинаций получалось бы на самом верхнем уровне). Но мы не знаем ни уровня такой вложенности компилятора (для GCC недавно было 8 вроде), ни получаемого у тебя уровня вложенности на верхнем уровне. S>комбинаций немало (http://www.w3.org/TR/CSS2/grammar.html#scanner, http://www.w3.org/TR/CSS2/grammar.html#grammar)
Большой вложенности цепочек не вижу, однако.
V>>Возможно, стоило вывести несколько "промежуточных" достаточно высокоуровневых фиксированных типов парсеров (параметризируемых обычными аргументами, а не шаблонными), именно на них уменьшив общее комбинаторное число, а не на самых низкоуровневых. Смотреть надо и пробовать. S>Я так и сделал. Параметризовал тип парсера лишь типом его результата, и убрал типы парсеров-участников комбинации.
Я про то, что низкоуровневые моли идти через кодогенерацию, а высокоуровневые — работать по данным, то бишь некоторые парсеры, назовем их среднего уровня, должны предоставлять унифицированный интерфейс, и более высокоуровневые парсеры строятся как интерпретатор на их основе. Все равно быстродействие критично на самом низком уровне только.
V>>А я просто пользуюсь тем, что декомпозиция в С++ практически бесплатна, в отличие от. Оч удобно декомпозировать на совсем маленькие типы с некоторым заведомо безопасным интерфейсом, с проверкой всех контрактов и прочим, затем построить глобальные операции вокруг таких типов (тоже оч удобно в отличие от ). В таком подходе высокоуровневые объекты "по месту" собираются уже из отлаженных запчастей такой инфраструктуры, которая получается высокоуровневой сама по себе, потому что в прикладном коде мы уже оперируем прикладными сущностями из инфраструктуры. S>Если я все верно понял, то это справедливо не только для C++
К сожалению, в дотнете не так шоколадно, из-за того, что если тип по некоторому сценарию нужен для как ref, то такую декомпозицию с его участием в других местах легковесной не назовешь, ибо он везде пойдет как ref, добавляя уровень косвенности. В общем случае для дотнета описанный сценарий крайне вреден.
S>генерики они другие. На темплейтах можно делать то, что нельзя на генериках и наоборот.
Генерики только имеют одно преимущество, позволяют оперировать с заранее неизвестным типом в рантайм, создавая экземпляры через рефлексию. Это такой же плюс, как и любые другие сценарии вокруг рефлексии. Так же удобны ограничения в виде специального синтаксиса, но ограничения можно использовать и в С++ через ср-ва языка, и даже эти ограничения могут поразнообразнее, но синтаксис не заточен именно под ограничения. Во всех остальных случаях генерики неизмеримо беднее.
S>Например, был жестоко обломан тем что темлейт функции-мемберы не могут быть виртуальными
Потому что никакой динамики, а только статика. И первый вызов такого метода у генерика оч дорогой. И почему жестоко-то? Приведи задачу, посмотрим, что под нее подходит. На шаблонах же что угодно делать можно, включая параметризируемую базу. Мне ни разу не нужна была упомянутая тобой фича в шаблонах, хотя в генериках без нее вообще никак. Но в генериках и выбора особого нет.
S>Вот еще пример, рекурсивный полиморфизм невозможно юзать во времени выполнения в C++, но вполне работает в C#. Если что — я об Purely Functional Data Structures (Queues based on implicit recursive slowdown).
Не уверен, что это так, если речь не идет о брутфорсной рефлексии времени исполнения. Приведи пример на C#. Потому как если наоборот, то в плане метаинформации времени компиляции, ситуация в С++ всяко получше. Ну и есть такая фишка, как т.н. статические визиторы. Т.е. это аналогичный обычному визитору механизм, полностью заресолвленный в статике там, где в аналогичном месте в C# он был бы заресолвлен лишь в динамике через двойную диспетчеризацию.
Здравствуйте, Ikemefula, Вы писали:
I>Нативный софт начали писать еще в 80х [...]
Щито???
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
V>>По моим наблюдениям за глюкавостью дотнетных программ, они ловятся на совершенно детских тестах: например часто при попытке сохранить файл в директорию, защищенную от записи или почти в 100% случаев, при исчерпании какого-нить ресурса (кол-ва сокетов, поверхностей для рисования, свободного места на диске). Такое ощущение, что дотнетчики поголовно пишут код из расчета "всё будет хорошо", проверяя максимум контракты на входные параметры методов, во всех остальных случаях тупо плюя эксепшен, который (удивительно!) никто нигде не ждет. G>Так это же прекрасно, если вылетит exception то его быстрее поправят чем если он не вылетит. Писать в стиле let it crash полезно даже для десктопа, потому что позволяет быстро повесить обработку exception на верхнем уровне и выдавать пользователю адекватное сообщение.
А толку, если программа после этого перешла в невалидное состояние, показав пользователю сообщение? Где уж тут let it crash? Это возможно только в транзакционной по духу системе, так что не раскидывайся терминами, которых не понимаешь.
V>>Понятие безопасного к исключениям кода — это нечто из другой реальности,\ G>Именно, так как в .NET exception может вылететь где угодно. Пытаться писать код который не кидается исключениями — слишком затратно и абсолютно бесполезно.
Наоборот, при наличии механизма GC организовать атомарность смены состояний можно оч дешево, в сравнении с нейтивом. Но в твоем коде будут точно такие же мины, это уже понятно по твоему ответу. Ты показал, что не в курсе о чем речь.
Не поинтересуешься у тестовой команды, какова доля негативных тестов в общей доле тестов? Если меньше 70%-80% (грубо), то при игнорировании устойчивости к исключениям в вашей дисциплине кода, мы обсуждаем сейчас стандартный дотнетный говнокод, с детскими ошибками внутри.
V>>отсюда дотнет — просто рассадник наведенных ошибок (по опыту своей помощи в ловле ошибок коллег), бо после первой же обработанной (якобы обработанной) ошибочной ситуации, отваливается работоспособность в другом месте, потому как один или несколько объектов остаются в некоем промежуточном невалидном состоянии. G>Ты уже взаимоисключающие вещи писать начал. То тебе не нравится что валятся эксепшены, то не нравятся как их обрабатывают.
Ладно, про безопасный к исключениям код мы не слышали, отсюда ответы совершенно невпопад. Давай пока прервемся, а вернемся к теме лишь тогда, когда будет что сказать, чтобы ветка обсуждения зря не пропадала.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
G>>Да, и managed программа будет работать и работать корректно.
ГВ>Разницу между "корректно" и "без выбрасывания исключений" надо объяснять?
Да, опиши что такое "корректно". Почему ты считаешь некорректным держать ссылку на объект? Это как-то повлияет на результат?
G>>В unmanaged в лучшем случае упадет. Разницу понимаешь? ГВ>Естественно, понимаю.
Похоже что нет. Хотя это зависит от твоего понимания корректности.
ГВ>[...]
G>>Тут получается что просто не договорились между managed и unmanaged о tread safety.
ГВ>Вот, живой пример вреда code samples: собеседник начинает делать далеко идущие выводы из ничего. Код сугубо иллюстративный и показывает только то место, где возникала потеря объекта данных.
Есои он полностью не описывает ситуацию тогда зачем ты его привел?
ГВ>В реальности и сам код был сложней, и ещё довольно сложная логика перезапуска потоков, из-за которой, в общем, всё и случилось. Но к тому, на что я хотел обратить внимание, это не относится. А про однопоточность unmanaged всем и так было известно.
В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое.
А то получается что ты низкую квалификацию писавшего код на C# выставляешь за недостаток языка.
Здравствуйте, Ikemefula, Вы писали:
I>>>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол. V>>Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные. I>и много этих популярных программ ?
Тулзы типа SVN, игрушки, OpenOffice, Skype, компиляторы (без счёта), мессенджеры, браузеры, оболочки (KDE, Gnome, Explorer), графические пакеты... Ты, правда, хочешь, чтобы их тут перечисляли?
>>Попробуй на досуге набрать в гугле "новости софта", или зайти на любой пиратский торрент и посмотреть в топах, что народ качает. Дотнет там оч редко, только в утилитах каких-нить, администраторских.
I>Расклад по тому, что нынче пишется в каких объемах можно сделать тупо по количеству вакансий. Как то я не вижу значительного кол.ва вакансий на с++ и не вижу, что бы ЗП в с++ отражали спрос на с++
Нативный софт часто пишется стабильными долгоиграющими командами, отсюда и относительно небольшое количество вакансий. З/п отражают не количество разрабатываемого софта, а совсем другое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну а теперь, давай сделаем простую индукцию. Код принципиально рассчитан на работу в одном потоке, следовательно, хитрых смарт-пойнтеров в нём делать не будут. Просто ни к чему. А значит, вызывающий код с некоторой очень ненулевой вероятностью будет выглядеть примерно так:
ГВ>
ГВ>void processData() {
ГВ> while(...) {
ГВ> delete m_pData;// <- вот тут и будет "ой"
ГВ> m_pData = callReadingCode();
ГВ> int x = m_pData->prop1;
ГВ> // ...
ГВ> }
ГВ>}
ГВ>
Я, наверное, какой-то очень странный. Мне совершенно неочевидно, почему начинать цикл нужно именно с delete, и кто будет удалять результат последнего чтения (я в курсе про валидность первого вызова delete до инициализации m_pData).
Я бы ожидал чего-то вроде
Впрочем, это не совсем важно. Важно то, что вызов delete, даже в таком цикле — относительно редкая штука. Тело цикла будет прекрасно себе работать с уже убитым объектом, а если повезёт — то и со следующим, размещённым на его месте.
ГВ>За счёт разваливания разметки динамической памяти (хипа). Да-да, ты не ослышался.
А-а. Ну тогда ладно. Интересно только, какая избыточность в хипе тратится на метаинформацию о распределённых блоках, чтобы можно было определить такие косяки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
ГВ>>>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом. G>>>Да, и managed программа будет работать и работать корректно. ГВ>>Разницу между "корректно" и "без выбрасывания исключений" надо объяснять?
G>Да, опиши что такое "корректно". Почему ты считаешь некорректным держать ссылку на объект? Это как-то повлияет на результат?
Вход: число N.
Выход: N x 2.
Пример неправильного выхода без выбрасывания исключения: N x 2 + 1.
G>>>В unmanaged в лучшем случае упадет. Разницу понимаешь? ГВ>>Естественно, понимаю. G>Похоже что нет. Хотя это зависит от твоего понимания корректности.
Ну похоже, так похоже. Мне-то что?
ГВ>>[...]
G>>>Тут получается что просто не договорились между managed и unmanaged о tread safety.
ГВ>>Вот, живой пример вреда code samples: собеседник начинает делать далеко идущие выводы из ничего. Код сугубо иллюстративный и показывает только то место, где возникала потеря объекта данных. G>Есои он полностью не описывает ситуацию тогда зачем ты его привел?
Очевидно, затем, чтобы показать, как терялся объект данных, сгенерированный unmanaged-кодом. Только для этого. Поверь, советов по проектированию я спрашивать не собирался.
ГВ>>В реальности и сам код был сложней, и ещё довольно сложная логика перезапуска потоков, из-за которой, в общем, всё и случилось. Но к тому, на что я хотел обратить внимание, это не относится. А про однопоточность unmanaged всем и так было известно.
G>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое.
Ты правда, прочёл то сообщение, которое обсуждаешь?
G>А то получается что ты низкую квалификацию писавшего код на C# выставляешь за недостаток языка.
Мой тебе добрый совет: не надо рассуждать о чужой квалификации с через третьи руки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Я, наверное, какой-то очень странный. Мне совершенно неочевидно, почему начинать цикл нужно именно с delete, и кто будет удалять результат последнего чтения (я в курсе про валидность первого вызова delete до инициализации m_pData). S>Я бы ожидал чего-то вроде [...]
Ну, я сознательно усложнил. В твоём варианте всё будет ещё проще: появится утечка, а по ней уже легко выйти на причины.
ГВ>>За счёт разваливания разметки динамической памяти (хипа). Да-да, ты не ослышался. S>А-а. Ну тогда ладно. Интересно только, какая избыточность в хипе тратится на метаинформацию о распределённых блоках, чтобы можно было определить такие косяки.
Довольно значительная (навскидку не скажу). Но это классический хип, в случае кастомных хипов объёмы метаданных меньше, и проявления ошибок, соответственно, тоже отличаются.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
V>>>Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные. I>>и много этих популярных программ ?
ГВ>Тулзы типа SVN, игрушки, OpenOffice, Skype, компиляторы (без счёта), мессенджеры, браузеры, оболочки (KDE, Gnome, Explorer), графические пакеты... Ты, правда, хочешь, чтобы их тут перечисляли?
Если не считать игрушек, то это все слабенькие примеры. А вот только корпоративных сайтов будет в разы бОльше чем мессенджеров, браузеров, оболочек, графических пакетов и тулзовин вроде SVN вместе взятых. Да-да.
Здравствуйте, Ikemefula, Вы писали:
V>>>>Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные. I>>>и много этих популярных программ ? ГВ>>Тулзы типа SVN, игрушки, OpenOffice, Skype, компиляторы (без счёта), мессенджеры, браузеры, оболочки (KDE, Gnome, Explorer), графические пакеты... Ты, правда, хочешь, чтобы их тут перечисляли? I>Если не считать игрушек, то это все слабенькие примеры. А вот только корпоративных сайтов будет в разы бОльше чем мессенджеров, браузеров, оболочек, графических пакетов и тулзовин вроде SVN вместе взятых. Да-да.
За время работы в индустрии у меня сложилось устойчивое убеждение, что "корпоративный сайт" (а чуть раньше — "корпоративная база данных") — это такая штука, написать которую просто дело чести для каждого программиста и тем более — для разработчика инструментальных средств. Почти уверен, что можно найти корпоративные [что-то] на шелле.
Собственно, корпоративный софт не релевантен популярности в данном случае, поскольку пишется под требования определённого, достаточно узкого круга лиц, под более или менее определённую аппаратуру, системное ПО и т.п. Ну вот возьму я, напишу для себя нечто на batch-файлах, ну и что?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I>>>Нативный софт начали писать еще в 80х [...] ГВ>>Щито??? I>Офис, вындоус и куча всякой всячины тянется ажно оттуда.
Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>За время работы в индустрии у меня сложилось устойчивое убеждение, что "корпоративный сайт" (а чуть раньше — "корпоративная база данных") — это такая штука, написать которую просто дело чести для каждого программиста и тем более — для разработчика инструментальных средств. Почти уверен, что можно найти корпоративные [что-то] на шелле.
Корпоративные сайты включают достаточно много функционала, часто это часть большей системы управления предприятием(чтото вроде), которая нынче редко пишется в нативном виде. В любом случае веб это вагоны проектов самых разных масштабов. А Офисов, к слову, хорошо если десяток наберется.
ГВ>Собственно, корпоративный софт не релевантен популярности в данном случае, поскольку пишется под требования определённого, достаточно узкого круга лиц, под более или менее определённую аппаратуру, системное ПО и т.п. Ну вот возьму я, напишу для себя нечто на batch-файлах, ну и что?
Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций. Вот размер кодовой базы или трудозатрат это более подходящий критерий для отделения софта от не-cофта. Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.
Здравствуйте, Геннадий Васильев, Вы писали:
I>>>>Нативный софт начали писать еще в 80х [...] ГВ>>>Щито??? I>>Офис, вындоус и куча всякой всячины тянется ажно оттуда.
ГВ>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман?
У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?
Здравствуйте, Ikemefula, Вы писали:
I>Расклад по тому, что нынче пишется в каких объемах можно сделать тупо по количеству вакансий. Как то я не вижу значительного кол.ва вакансий на с++ и не вижу, что бы ЗП в с++ отражали спрос на с++
Дык, я же говорю, дефицит. Как ни посмотришь требования к С++-программисту, от года, или типа таких:
Требования к кандидату
• Понимание ООП проектирования и программирования
• Практический опыт разработки программ на С++ (MS Windows)
• Знания и практический опыт использование библиотек MFC, STL, Boost
• Практический опыт разработки многопоточных приложений (синхронизация, разделяемые данные, обмен сообщениями)
• Опыт командной работы
Последние годы требования к плюсовикам настолько деградировали в объявлениях, что эти объявления можно читать как "ну придите же хоть кто-то". И предлагают там же ЗП, сопоставимую с разработчиками ASP.Net, для которых нехилый конкретный список требований, технологий, практик и т.д.
Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место. Лучше посмотреть на каком-нить http://nyjobsource.com/ , бо у нас 99% спецов-плюсистов тупо уехало и не вернулось. Когда я последний раз внимательно смотрел, то ЗП С++ разработчиков легко были 140-170к, аналогичных по опыту дотнетчиков 100-120к.
Здравствуйте, vdimas, Вы писали:
V>Ты показал, что не в курсе о чем речь.
Я не в курсе о чем ты говоришь. В твоем тексте постоянно взаимоисключающие параграфы встречаются.
V>Не поинтересуешься у тестовой команды, какова доля негативных тестов в общей доле тестов? Если меньше 70%-80% (грубо), то при игнорировании устойчивости к исключениям в вашей дисциплине кода, мы обсуждаем сейчас стандартный дотнетный говнокод, с детскими ошибками внутри.
Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?
V>>>отсюда дотнет — просто рассадник наведенных ошибок (по опыту своей помощи в ловле ошибок коллег), бо после первой же обработанной (якобы обработанной) ошибочной ситуации, отваливается работоспособность в другом месте, потому как один или несколько объектов остаются в некоем промежуточном невалидном состоянии. G>>Ты уже взаимоисключающие вещи писать начал. То тебе не нравится что валятся эксепшены, то не нравятся как их обрабатывают.
V>Ладно, про безопасный к исключениям код мы не слышали, отсюда ответы совершенно невпопад. Давай пока прервемся, а вернемся к теме лишь тогда, когда будет что сказать, чтобы ветка обсуждения зря не пропадала.
Ты уже перешел в демагогию. Вместо описания каких-то проблем ты пишешь общие слова, которые все по разному понимают.
Давай пиши конкретнее что ты имеешь ввиду.
ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман? I>У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?
Unix.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом. G>>>>Да, и managed программа будет работать и работать корректно. ГВ>>>Разницу между "корректно" и "без выбрасывания исключений" надо объяснять?
G>>Да, опиши что такое "корректно". Почему ты считаешь некорректным держать ссылку на объект? Это как-то повлияет на результат?
ГВ>Вход: число N. ГВ>Выход: N x 2.
ГВ>Пример неправильного выхода без выбрасывания исключения: N x 2 + 1.
Причем тут ссылка на объект? Не уходи от вопроса, ты же сказал что ссылку на объект держать "неправильно".
G>>>>В unmanaged в лучшем случае упадет. Разницу понимаешь? ГВ>>>Естественно, понимаю. G>>Похоже что нет. Хотя это зависит от твоего понимания корректности.
ГВ>Ну похоже, так похоже. Мне-то что?
А то что ты продолжаешь вести разговор не понимая проблем.
ГВ>Очевидно, затем, чтобы показать, как терялся объект данных, сгенерированный unmanaged-кодом. Только для этого. Поверь, советов по проектированию я спрашивать не собирался.
Ты написал не-threadsafe код, причем тут unmanaged непонятно. Причем этот пример больше на говнокод смахивает. Говнокод — не проблема языка.
ГВ>>>В реальности и сам код был сложней, и ещё довольно сложная логика перезапуска потоков, из-за которой, в общем, всё и случилось. Но к тому, на что я хотел обратить внимание, это не относится. А про однопоточность unmanaged всем и так было известно.
G>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое. ГВ>Ты правда, прочёл то сообщение, которое обсуждаешь?
Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.
G>>А то получается что ты низкую квалификацию писавшего код на C# выставляешь за недостаток языка. ГВ>Мой тебе добрый совет: не надо рассуждать о чужой квалификации с через третьи руки.
Мой тебе совет, не лезь со своими советами. Толку от них ноль.
Давай посмотри правде в глаза: 90% посчитают за говнокод то что ты привел, неважно был ли он написан так или ты упросил его до такого состояния.
Здравствуйте, Ikemefula, Вы писали:
ГВ>>За время работы в индустрии у меня сложилось устойчивое убеждение, что "корпоративный сайт" (а чуть раньше — "корпоративная база данных") — это такая штука, написать которую просто дело чести для каждого программиста и тем более — для разработчика инструментальных средств. Почти уверен, что можно найти корпоративные [что-то] на шелле.
I>Корпоративные сайты включают достаточно много функционала, часто это часть большей системы управления предприятием(чтото вроде), которая нынче редко пишется в нативном виде. В любом случае веб это вагоны проектов самых разных масштабов. А Офисов, к слову, хорошо если десяток наберется.
Ну и что?
ГВ>>Собственно, корпоративный софт не релевантен популярности в данном случае, поскольку пишется под требования определённого, достаточно узкого круга лиц, под более или менее определённую аппаратуру, системное ПО и т.п. Ну вот возьму я, напишу для себя нечто на batch-файлах, ну и что?
I>Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций.
Потому что это единственный критерий, однозначно определяющий популярность.
I>Вот размер кодовой базы или трудозатрат это более подходящий критерий для отделения софта от не-cофта.
Размер кодовой базы — это просто размер кодовой базы. Максимум, о чём он может сказать, так это о том, какой язык популярен у разработчиков. Ну и что такое "не-софт" я не очень представляю. Автомобили, что ли?
I>Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.
ИМХО, главное — это то, что популярность публично распространяемого софта прямо зависит от его потребительских качеств. Тут всё вместе: и выбор функциональности, и надёжность, и требовательность к ресурсам, и совместимость с неизвестно-каким-зоопарком. А корпоративный софт — совсем другая песня. Хотя бы потому, что затраты на него зачисляются на капитализацию, требования к аппаратуре и ПО может выставить и исполнитель, многое зависит от личных договорённостей или традиций "отдела автоматизации", а пользователи по указанию руководства сожрут любой кактус. То есть это совсем другая штука, на которую влияют другие факторы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое. ГВ>>Ты правда, прочёл то сообщение, которое обсуждаешь? G>Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.
В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности.
"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое. ГВ>>>Ты правда, прочёл то сообщение, которое обсуждаешь? G>>Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.
ГВ>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности.
Ну ты же начал про managed-unmanaged, а привел говнокод, который на любом языке мог бы так работать.
ГВ>"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило.
А это еще один интересный вопрос. Видимо помимо проблем в managed были еще и в unmanaged проблемы, которые приводили к ave. Тоже что-то вроде разделяемых данных без синхронизации.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.
ГВ>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно".
Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.
ГВ>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь".
Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.
Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем.
Здравствуйте, gandjustas, Вы писали:
ГВ>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. ГВ>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно". G>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.
Правильно. Но принципиально тут планировался ровно один поток. Поэтому ошибка была вовсе не в отсутствии примитивов синхронизации, а в коде управления потоками (создание-пуск-остановка). В чём конкретно она состояла — сейчас совершенно не важно.
ГВ>>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь". G>Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.
Естественно. Только для этого надо приложить специальные усилия. Например — добавить защиту от многопоточности там, где многопоточность ни разу не планируется.
G>Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем.
Как оказалось, очень даже при чём.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Говнокод он и в африке говнокод [...]
Всё хочу у тебя спросить: тебе слово "говнокод" нравится, что ли? Прям в каждом сообщении — говнокод, говнокод, говнокод. Ты не отличаешь иллюстративные примеры от реального кода? Или я как-то непонятно ситуацию описываю?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>Говнокод он и в африке говнокод [...]
ГВ>Всё хочу у тебя спросить: тебе слово "говнокод" нравится, что ли? Прям в каждом сообщении — говнокод, говнокод, говнокод. Ты не отличаешь иллюстративные примеры от реального кода? Или я как-то непонятно ситуацию описываю?
Оно очень ясно выражает то что код плохой и написан так скорее не из-за объективных причин, типа ограниченности ресурсов, а банально из-за некомпетентности разработчика.
Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. ГВ>>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно". G>>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.
ГВ>Правильно. Но принципиально тут планировался ровно один поток. Поэтому ошибка была вовсе не в отсутствии примитивов синхронизации, а в коде управления потоками (создание-пуск-остановка). В чём конкретно она состояла — сейчас совершенно не важно.
Да ну? Ты же начал говорить что проблема была в managed коде, но показать её не можешь. Приводишь только кусок кода к делу и не относящийся (судя по твои словам).
ГВ>>>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь". G>>Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.
ГВ>Естественно. Только для этого надо приложить специальные усилия. Например — добавить защиту от многопоточности там, где многопоточность ни разу не планируется.
Нет, чтобы написать такой же бажный код не потребовалось бы ничего.
G>>Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем. ГВ>Как оказалось, очень даже при чём.
Где оказалось? Выйди из сумрака.
Меня всегда прикалывали мнения вроде: вот Вася писал прогу на C#, она получилась глючной и медленной, он решил переписать её на C++. Знаете что обычно получается у таких вась и их программ?
Хороший кодер сможет на любом языке написать хорошую программу, плохой кодер на любом языке напишет плохую. Глупо приписывать эти свойства языку.
Здравствуйте, gandjustas, Вы писали:
G>Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?
По-видимому, я всё-таки невнятно это как-то обозначил: приведённый код принципиально однопоточный. Многопоточным он "становился" только из-за ошибки в управлении потоками.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?
V>При оперировании состояниями в небезопасном к исключению коде это еще оптимистично, бо негативных сценариев всегда больше позитивных. Я бы сформулировал так: на каждый позитивный сценарий есть целая куча негативных.
Не спорю. Но ты на вопрос ответь. Ты предлагаешь тестировать негативные сценарии, которые по сути не нужны пользователю. Зачем это делать?
G>>Ты уже перешел в демагогию. Вместо описания каких-то проблем ты пишешь общие слова, которые все по разному понимают. G>>Давай пиши конкретнее что ты имеешь ввиду. V>Это общеупотребительные термины и мемы.
Как обычно за "общеупотребительными терминами" у каждого свое понимание. Дай ссылку на какие-нить источники, хоть википедию чтоли.
G>>ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.
V>Совсем другое дело десктоп.
Ага, но если в десктопе писать большую часть приложения в таком же stateless стиле, то получается не хуже чем в вебе.
Стейт как всегда присутствует в двух местах: интерфейс и хранилище данных. Первый нормально изолируется с помощью паттернов mv*, второй с помощью грамотно проработанных интерфейсов.
Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее. А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.
Здравствуйте, gandjustas, Вы писали:
ГВ>>>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. ГВ>>>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно". G>>>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить. ГВ>>Правильно. Но принципиально тут планировался ровно один поток. Поэтому ошибка была вовсе не в отсутствии примитивов синхронизации, а в коде управления потоками (создание-пуск-остановка). В чём конкретно она состояла — сейчас совершенно не важно.
G>Да ну? Ты же начал говорить что проблема была в managed коде, но показать её не можешь. Приводишь только кусок кода к делу и не относящийся (судя по твои словам).
Именно. Я ж не алгоритмы управления потоками обсуждать собираюсь, а показываю именно кусок, прямо не относящийся к проблеме, который в unmanaged-варианте стал бы работать чёрт-те как, а в managed-исполнении работал вполне гладко (кроме иногда возникавших конфликтов в unmanaged-части).
Повторяю в ...-й раз: код, который вызывал unmanaged-часть, планировался, проектировался, разрабатывался и тестировался, как однопоточный.
G>Меня всегда прикалывали мнения вроде: вот Вася писал прогу на C#, она получилась глючной и медленной, он решил переписать её на C++. Знаете что обычно получается у таких вась и их программ? G>Хороший кодер сможет на любом языке написать хорошую программу, плохой кодер на любом языке напишет плохую. Глупо приписывать эти свойства языку.
А я ничего никому не приписываю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I>Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём.
Не, из этих персонажей один сидит на жаббе, двое вовсе потерялись из программирования.
I>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ...
С моей конторы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол. BBI>>Ага, но при этом 90% софта native. Вот ведь парадокс. I>Кто тебе такое сказал ?
Реальность. Тупо пошарился по всем доступным компам.
BBI>>Это ж ведь только с твоей колокольни такой вид открывается. I>Нативный софт начали писать еще в 80х и с каждым годом в общей массе его становится меньше и меньше.
А ты это откуда взял?
У меня к примеру весь новый софт которым можно пользоваться почему то исключительно native.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Случайно тела методов были в теле класса. Те методы однострочные, жалко было места для дублирования сигнатуры. Но раз я обнаружил разницу в размере бинарников, то очевидно что варианты не эквивалентны. Тем более, что класс во втором случае имеет поле, в котором хранит переданный в конструкторе char.
V>Ну и что, если объект временный на стеке, его класс инлайный, происходит инициализация значением времени компиляции — это одно и то же в итоге. В общем, надо посмотреть на код, тогда я мог бы не гадать на кофейной куче... Может у тебя подчиненные парсеры хранятся как мемберы более высокоуровневых. Тоды ой.
Да, мемберы. Я пока не могу рассчитывать на auto-typed variables, потому мне надо как-то декларировать типы результатов комбинаций, т.к. я не хочу записывать высокоуровневый парсер одним выражением. Но и записывать в типе переменной тип комбинации тоже как-то лениво. Кроме того, там очень нехилые символические имена получаются (если парсеры низкого уровня записывать template параметрами). Пришлось создать виртуальные обертки для высокоуровневых парсеров, в которых записан лишь тип результата разбора, но нет типов парсеров-компонент.
В итоге, получившиеся парсеры стали выпадать из времени-компиляции во время выполнения, что и привело к необходимости хранить мемберы для парсеров более высокого уровня. В конце-концов я пришел к тому что вся информация, необходимая парсерам, хранится у них в мемберах.
S>>комбинаций немало (http://www.w3.org/TR/CSS2/grammar.html#scanner, http://www.w3.org/TR/CSS2/grammar.html#grammar)
V>Большой вложенности цепочек не вижу, однако.
Что считать большой?
num [0-9]+|[0-9]*"."[0-9]+
пусть [0-9]- тривиальный парсер, и "." — тоже. Квантифиакторы — повышают вложенность на уровень. Алтернативы (|) тоже. Ну и сиквенсинг само собой. Итого навскидку глубина num равна 5.
В свою очередь num используется вот в таких шнягах
...
G g|\\0{0,4}(47|67)(\r\n|[ \t\r\n\f])?|\\g
...
{num}{D}{E}{G} {return ANGLE;}
считать глубину вложенности ANGLE мне уже лениво.
ANGLE учавствует в term, term в expr, expr дальше, каждый уровень подымает вложенность единиц на 3-5. В итоге, когда доберемся до stylesheet, вложенность может измеряться десятками этажей. Большая? Ну не знаю. Смотря для чего. Для символических имен — запредельная.
V>Я про то, что низкоуровневые моли идти через кодогенерацию, а высокоуровневые — работать по данным, то бишь некоторые парсеры, назовем их среднего уровня, должны предоставлять унифицированный интерфейс, и более высокоуровневые парсеры строятся как интерпретатор на их основе. Все равно быстродействие критично на самом низком уровне только.
А быстродейстиве не критично вообще. Скажем так, быстродействие разбора CSS — меньшее, что меня беспокоит среди быстродействия в текущем проекте. Сейчас оно более чем удовлетворительное. Больше беспокоит объем бинариев, именно по этому поводу я вспомнил о template-взрыве.
V>К сожалению, в дотнете не так шоколадно, из-за того, что если тип по некоторому сценарию нужен для как ref, то такую декомпозицию с его участием в других местах легковесной не назовешь, ибо он везде пойдет как ref, добавляя уровень косвенности. В общем случае для дотнета описанный сценарий крайне вреден.
Не понял.
S>>генерики они другие. На темплейтах можно делать то, что нельзя на генериках и наоборот.
V>Генерики только имеют одно преимущество, позволяют оперировать с заранее неизвестным типом в рантайм, создавая экземпляры через рефлексию. Это такой же плюс, как и любые другие сценарии вокруг рефлексии. Так же удобны ограничения в виде специального синтаксиса, но ограничения можно использовать и в С++ через ср-ва языка, и даже эти ограничения могут поразнообразнее, но синтаксис не заточен именно под ограничения. Во всех остальных случаях генерики неизмеримо беднее.
Последний раз создавал экземпляры генериков через рефлексию где-то в 2004-м.
S>>Например, был жестоко обломан тем что темлейт функции-мемберы не могут быть виртуальными
V>Потому что никакой динамики, а только статика. И первый вызов такого метода у генерика оч дорогой. И почему жестоко-то? Приведи задачу, посмотрим, что под нее подходит. На шаблонах же что угодно делать можно, включая параметризируемую базу. Мне ни разу не нужна была упомянутая тобой фича в шаблонах, хотя в генериках без нее вообще никак. Но в генериках и выбора особого нет.
Мультиметоды. Точнее — двойная диспетчеризация шаблонного метода.
S>>Вот еще пример, рекурсивный полиморфизм невозможно юзать во времени выполнения в C++, но вполне работает в C#. Если что — я об Purely Functional Data Structures (Queues based on implicit recursive slowdown).
V>Не уверен, что это так, если речь не идет о брутфорсной рефлексии времени исполнения.
Нет, не рефлексия. Типы создавал JIT, на сколько я помню. V>Приведи пример на C#.
Я его встречал где-то пару лет назад, сейчас не найду. V>Потому как если наоборот, то в плане метаинформации времени компиляции, ситуация в С++ всяко получше.
Времени JIT компиляции в случае с C#. V>Ну и есть такая фишка, как т.н. статические визиторы. Т.е. это аналогичный обычному визитору механизм, полностью заресолвленный в статике там, где в аналогичном месте в C# он был бы заресолвлен лишь в динамике через двойную диспетчеризацию.
Да, есть, я знаю эту фишку. Но на этой фишке в C++ не построить живую очередь, которая сможет изменять свой размер в рантайме, скажем до размера нескольких десятков тысяч элементов. А на C# она работает (конечно, скорость ее работы далека от System.Generic.Collections.Queue<T>).
Здравствуйте, samius, Вы писали:
V>>Ну и что, если объект временный на стеке, его класс инлайный, происходит инициализация значением времени компиляции — это одно и то же в итоге. В общем, надо посмотреть на код, тогда я мог бы не гадать на кофейной куче... Может у тебя подчиненные парсеры хранятся как мемберы более высокоуровневых. Тоды ой. S>Да, мемберы. Я пока не могу рассчитывать на auto-typed variables, потому мне надо как-то декларировать типы результатов комбинаций, т.к. я не хочу записывать высокоуровневый парсер одним выражением. Но и записывать в типе переменной тип комбинации тоже как-то лениво. Кроме того, там очень нехилые символические имена получаются (если парсеры низкого уровня записывать template параметрами). Пришлось создать виртуальные обертки для высокоуровневых парсеров, в которых записан лишь тип результата разбора, но нет типов парсеров-компонент. S>В итоге, получившиеся парсеры стали выпадать из времени-компиляции во время выполнения, что и привело к необходимости хранить мемберы для парсеров более высокого уровня. В конце-концов я пришел к тому что вся информация, необходимая парсерам, хранится у них в мемберах.
Так... тут надо выбрать время и вникнуть. Диагноз я поставил правильно, но чтобы показать решение, надо видеть, из чего оно состоит. Нет у тебя той старой версии, которая будет 5MB в бинарнике?
S>ANGLE учавствует в term, term в expr, expr дальше, каждый уровень подымает вложенность единиц на 3-5. В итоге, когда доберемся до stylesheet, вложенность может измеряться десятками этажей. Большая? Ну не знаю. Смотря для чего. Для символических имен — запредельная.
Дык, если мемберами не хранить, т.е. не специализировать целевой парсер подчиненными, а использовать их как временные на стеке, то и не будет эскалации шаблонов в объявлениях.
V>>Я про то, что низкоуровневые моли идти через кодогенерацию, а высокоуровневые — работать по данным, то бишь некоторые парсеры, назовем их среднего уровня, должны предоставлять унифицированный интерфейс, и более высокоуровневые парсеры строятся как интерпретатор на их основе. Все равно быстродействие критично на самом низком уровне только. S>А быстродейстиве не критично вообще. Скажем так, быстродействие разбора CSS — меньшее, что меня беспокоит среди быстродействия в текущем проекте. Сейчас оно более чем удовлетворительное. Больше беспокоит объем бинариев, именно по этому поводу я вспомнил о template-взрыве.
С твоим вариантом уже разобрались, наверно же интересно, как оно бы выглядело, если бы...
V>>К сожалению, в дотнете не так шоколадно, из-за того, что если тип по некоторому сценарию нужен для как ref, то такую декомпозицию с его участием в других местах легковесной не назовешь, ибо он везде пойдет как ref, добавляя уровень косвенности. В общем случае для дотнета описанный сценарий крайне вреден. S>Не понял.
Много маленьких объектов и развесистые графы внутренностей целевых объектов из этих маленьких не есть хорошо для дотнета. Большая косвенность будет на примитивных операциях и ГЦ не любит.
S>>>Например, был жестоко обломан тем что темлейт функции-мемберы не могут быть виртуальными
V>>Потому что никакой динамики, а только статика. И первый вызов такого метода у генерика оч дорогой. И почему жестоко-то? Приведи задачу, посмотрим, что под нее подходит. На шаблонах же что угодно делать можно, включая параметризируемую базу. Мне ни разу не нужна была упомянутая тобой фича в шаблонах, хотя в генериках без нее вообще никак. Но в генериках и выбора особого нет. S>Мультиметоды. Точнее — двойная диспетчеризация шаблонного метода.
Ну так и думал, что же еще... Пора мне приз битвы экстрасенсов вручать, по итогам сей ветки.
Ну так когда вспомнишь задачу, посмотрим на статический С++ визитор в ее рамках.
S>>>Вот еще пример, рекурсивный полиморфизм невозможно юзать во времени выполнения в C++, но вполне работает в C#. Если что — я об Purely Functional Data Structures (Queues based on implicit recursive slowdown).
V>>Ну и есть такая фишка, как т.н. статические визиторы. Т.е. это аналогичный обычному визитору механизм, полностью заресолвленный в статике там, где в аналогичном месте в C# он был бы заресолвлен лишь в динамике через двойную диспетчеризацию. S>Да, есть, я знаю эту фишку. Но на этой фишке в C++ не построить живую очередь, которая сможет изменять свой размер в рантайме, скажем до размера нескольких десятков тысяч элементов. А на C# она работает (конечно, скорость ее работы далека от System.Generic.Collections.Queue<T>).
Мне нечего ответить, пока я не вижу о чем речь. С очередями и конвейерами я вожусь чуть более чем в каждом проекте, поэтому не понимаю пока, в чем проблема.
Здравствуйте, vdimas, Вы писали:
V>А че-то D совсем притих... Никто там его покупать не собирается, случайно?
Не слышал такого.
Радует хоть что в последнее время новых фич не добавляют http://www.d-programming-language.org/changelog.html
в основном багфиксы и расширение поддерживаемых платформ.
Вообще по моему для небольших проектов он уже вполне годен.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>В итоге, получившиеся парсеры стали выпадать из времени-компиляции во время выполнения, что и привело к необходимости хранить мемберы для парсеров более высокого уровня. В конце-концов я пришел к тому что вся информация, необходимая парсерам, хранится у них в мемберах.
V>Так... тут надо выбрать время и вникнуть. Диагноз я поставил правильно, но чтобы показать решение, надо видеть, из чего оно состоит. Нет у тебя той старой версии, которая будет 5MB в бинарнике?
Я пошукаю. Та версия была еще во время прототипирования, под контролем версий ее нет. Но где-то обязательно должна быть. Надо будет повыкидывать оттуда не относящееся к вопросу, вобщем займет какое-товремя.
S>>ANGLE учавствует в term, term в expr, expr дальше, каждый уровень подымает вложенность единиц на 3-5. В итоге, когда доберемся до stylesheet, вложенность может измеряться десятками этажей. Большая? Ну не знаю. Смотря для чего. Для символических имен — запредельная.
V>Дык, если мемберами не хранить, т.е. не специализировать целевой парсер подчиненными, а использовать их как временные на стеке, то и не будет эскалации шаблонов в объявлениях.
Э не, мне же нужен реюз. Т.е. однажды сконструированный парсер используется многократно, см. тот же num. Я не могу получить его на стеке и не запомнить где-то. А что бы запомнить нужно либо объявить тип (без auto) либо обернуть абстракцией (но тогда запомненное невзоможно будет передать лишь template параметром, надо будет еще и ссылку на абстрккцию тянуть и хранить ее в мемберах).
V>С твоим вариантом уже разобрались, наверно же интересно, как оно бы выглядело, если бы...
Мне тоже
V>Много маленьких объектов и развесистые графы внутренностей целевых объектов из этих маленьких не есть хорошо для дотнета. Большая косвенность будет на примитивных операциях и ГЦ не любит.
Насколько развесистые графы? Вот что ГЦ не любит — это большие объекты. А маленькие пережует, дай время
S>>Мультиметоды. Точнее — двойная диспетчеризация шаблонного метода.
V>Ну так и думал, что же еще... Пора мне приз битвы экстрасенсов вручать, по итогам сей ветки. V>Ну так когда вспомнишь задачу, посмотрим на статический С++ визитор в ее рамках.
Не спасет меня статический визитор, т.к. структура данных динамическая (дерево разнотипных элементов, создаваемое в динамике). Дерево динамическое, задач для диспетчеризации много, но не хочется писать диспетчеризацию под множество задач. Так что приза не будет. Обошелся шаблоном с условной логикой на тайп-тесте, благо значительного расширения типов иерархии предвидится.
V>Мне нечего ответить, пока я не вижу о чем речь. С очередями и конвейерами я вожусь чуть более чем в каждом проекте, поэтому не понимаю пока, в чем проблема. www.cs.cmu.edu/~rwh/theses/okasaki.pdf (8.4 Queues and Deques)
Здравствуйте, MxMsk, Вы писали:
ГВ>>>Вон, как здесь уже договорились до того, что аллокатор=гуру, скоро до указателей дойдёте. BBI>>Этот момент нереально повеселил. Шарпист добровольно по сути признал меня гуру, цирк на конной тяге!!! MM>Господа Шарписты, я не понимаю, для чего вы тратите силы и время на спор с такими людьми. Стоит завязать, причем насовсем.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.
Сурово. Но справедливо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
V>>Так... тут надо выбрать время и вникнуть. Диагноз я поставил правильно, но чтобы показать решение, надо видеть, из чего оно состоит. Нет у тебя той старой версии, которая будет 5MB в бинарнике? S>Я пошукаю. Та версия была еще во время прототипирования, под контролем версий ее нет. Но где-то обязательно должна быть. Надо будет повыкидывать оттуда не относящееся к вопросу, вобщем займет какое-товремя.
ок
S>Э не, мне же нужен реюз. Т.е. однажды сконструированный парсер используется многократно, см. тот же num. Я не могу получить его на стеке и не запомнить где-то.
У классических комбинаторных парсеров нет состояния по окончании их работы. Комбинаторный парсер — это суть алгоритм, инкапсулирующий конкретную ветку правил. Только в самих правилах и есть отличия экземпляров парсеров (т.е. типов в данной схеме). А вся механика по построению AST и прочее — абсолютно одинакова, и эту механику можно из парсеров вынести и подавать как контекст/параметр со своим АПИ. Итого, в парсере не будет состояния, кроме состояния стека вызовов подчиненных парсеров, пока идет разбор по его алгоритму. Поэтому создание экземпляра — 0 тактов, удаление тоже 0 тактов. Хранить необязательно.
S>Насколько развесистые графы? Вот что ГЦ не любит — это большие объекты. А маленькие пережует, дай время
Это если на них ссылок нет и они из 0-го поколения. А если у нас все объекты состоят из десятка мелких, те в свою очередь еще из нескольких, то это мертвый груз для GC. Лишняя косвенность, ну и лишняя память, ведь блок в куче имеет служебную информацию, плюс надо дополнительно вместо самого объекта еще хранить ссылку на него, что в x64 оч много байт занимает. Неэффективно в общем. В дотнете я из-за этого делал отдельно value-type объекты, описывающие состояние, отдельно к ним ref-type обертки... двойная работа, в общем.
S>Не спасет меня статический визитор, т.к. структура данных динамическая (дерево разнотипных элементов, создаваемое в динамике). Дерево динамическое, задач для диспетчеризации много, но не хочется писать диспетчеризацию под множество задач. Так что приза не будет. Обошелся шаблоном с условной логикой на тайп-тесте, благо значительного расширения типов иерархии предвидится.
Пусть так. На C++, в отличие от, можно реализовать паттерн визитора в библиотечном виде. Я имею ввиду классический, который без тайп-тестов. И да, ни методы визитора, ни посещаемых объектов не обязаны быть виртуальными. По крайней сия библиотечная реализация не требует. Цимус визитора в возможности расширения функциональности над семейством типов без изменения самого семейства, а остальные подробности несущественны.
V>>Мне нечего ответить, пока я не вижу о чем речь. С очередями и конвейерами я вожусь чуть более чем в каждом проекте, поэтому не понимаю пока, в чем проблема. S>www.cs.cmu.edu/~rwh/theses/okasaki.pdf (8.4 Queues and Deques)
Предположим, что с основными структурами данных я знаком, и даже представляю, как они организуются в функциональной парадигме. У нас же был вполне конкретный вопрос по механике С++ и сравнении возможностей генериков из C#, для какого-то совсем конкретного момента реализации, который не был показан. ИМХО, реализаций любого абстрактного алгоритма может быть гораздо больше одной, поэтому почти всегда можно выкрутиться.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Э не, мне же нужен реюз. Т.е. однажды сконструированный парсер используется многократно, см. тот же num. Я не могу получить его на стеке и не запомнить где-то.
V>У классических комбинаторных парсеров нет состояния по окончании их работы. Комбинаторный парсер — это суть алгоритм, инкапсулирующий конкретную ветку правил. Только в самих правилах и есть отличия экземпляров парсеров (т.е. типов в данной схеме). А вся механика по построению AST и прочее — абсолютно одинакова, и эту механику можно из парсеров вынести и подавать как контекст/параметр со своим АПИ. Итого, в парсере не будет состояния, кроме состояния стека вызовов подчиненных парсеров, пока идет разбор по его алгоритму. Поэтому создание экземпляра — 0 тактов, удаление тоже 0 тактов. Хранить необязательно.
Это все мне известно. Но цепочка построения типов упирается в некоторые сложности. Допустим, мне нужно записать
(p1 | p2)+
Есть вариант строить типы:
typedef ... p1;
typedef ... p2;
typedef Many<
a, // тип результата разбора
OrElse<b, p1, p2> // b-тип парсера, который квантифицируем, p1 и p2 - типы парсеров
1, // минимальное число вложений
inf, // максимальное число вложений
acc // аккумуляторная функция аки в fold-е
> MyParser;
Мне этот вариант ох как не нравится, потому как из короткой записи мы получаем очень длинную и практически нечитаемую. В непосредственном комбинировании типов мы не можем использовать перегруженные операторы.
Еще вариант, комбинировать выражения. Но по результату выражения мы не можем ввести тип результата (что бы его за-typedef-ить):
auto p1 = ...
auto p2 = ...
auto MyParser = Many<1, inf, acc>(p1 | p2);
// auto MyParser = OneOrMore<acc>(p1 | p2);
Так вот, проблема в том, что написать вместо auto, если Many возвращает результат типа ManyParser<1,inf,acc,Tp1,Tp2>, притом что p1 и p2 нетривиальные парсеры?
Мы рассмотрели тривиальное выражение (p1|p2)+, а нужны куда более серьезные...
(Писал навскидку, такого кода у меня нет)
Это только синтаксиеческая проблема подхода без состояний. Есть еще взрыв... Мне сложно прикинуть, сколько в грамматике CSS использован квантификатор. Допустим, 100 раз (явно меньше, чем есть на самом деле). Это значит, что метод разбора ManyParser::Parse будет размножен именно 100 раз.
Можно пойти путем вытаскивания необходимой информации из template параметров, например превратить RangeParser<'0','9'> в RangeParser, хранящий состояния '0' и '9'. Таким образом, парсеры, разбирающие диапазоны кодепоинтов, будут иметь один тип. Но мы внесли состояние, правда неизменяемое. Я пошел еще дальше и унифицировал все парсеры, результатом которых является значение определенного типа. Т.е. все парсеры, разбирающие отдельные символы, имеют один тип, парсеры, разбирающие строки (std::wstring) имеют другой тип и т.п.
Тогда мы существенно уменьшим количество типов, получающихся при комбинации парсеров. Т.е. сколько бы мы ни комбинировали парсеры, разбирающие отдельные символы, результатом (|) получим парсер, разбирающий символы и только. Т.е. удалось избежать комбинаторного взрыва типов парсеров за счет внесения состояния в парсеры. Естественно, состояние не изменяется в процессе разбора, но оно есть и его надо хранить в мемберах.
Кстати, система типов дотнета позволяет построить такой парсер практически без напряга. Не знаю, в какой объем разворачивается IL, но на диске его порядка 150Кб.
V>Это если на них ссылок нет и они из 0-го поколения. А если у нас все объекты состоят из десятка мелких, те в свою очередь еще из нескольких, то это мертвый груз для GC. Лишняя косвенность, ну и лишняя память, ведь блок в куче имеет служебную информацию, плюс надо дополнительно вместо самого объекта еще хранить ссылку на него, что в x64 оч много байт занимает. Неэффективно в общем. В дотнете я из-за этого делал отдельно value-type объекты, описывающие состояние, отдельно к ним ref-type обертки... двойная работа, в общем.
То есть это было причиной падения производительности (лишняя косвенность, напряги GC)?
S>>Не спасет меня статический визитор, т.к. структура данных динамическая (дерево разнотипных элементов, создаваемое в динамике). Дерево динамическое, задач для диспетчеризации много, но не хочется писать диспетчеризацию под множество задач. Так что приза не будет. Обошелся шаблоном с условной логикой на тайп-тесте, благо значительного расширения типов иерархии предвидится.
V>Пусть так. На C++, в отличие от, можно реализовать паттерн визитора в библиотечном виде. Я имею ввиду классический, который без тайп-тестов. И да, ни методы визитора, ни посещаемых объектов не обязаны быть виртуальными. По крайней сия библиотечная реализация не требует.
При отсутствии виртуальных методов и тайп-теста (либо его заменителей) мы не сможем работать с subtype-полиморфными данными. А именно это мне требовалось.
V>Цимус визитора в возможности расширения функциональности над семейством типов без изменения самого семейства, а остальные подробности несущественны.
Это известно.
S>>www.cs.cmu.edu/~rwh/theses/okasaki.pdf (8.4 Queues and Deques)
V>Предположим, что с основными структурами данных я знаком, и даже представляю, как они организуются в функциональной парадигме. У нас же был вполне конкретный вопрос по механике С++ и сравнении возможностей генериков из C#, для какого-то совсем конкретного момента реализации, который не был показан. ИМХО, реализаций любого абстрактного алгоритма может быть гораздо больше одной, поэтому почти всегда можно выкрутиться.
Естественно можем, но в случае с C++ придется ослабить типизацию, для того что бы работать с такой структурой в рантайме.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Расклад по тому, что нынче пишется в каких объемах можно сделать тупо по количеству вакансий. Как то я не вижу значительного кол.ва вакансий на с++ и не вижу, что бы ЗП в с++ отражали спрос на с++
V>Дык, я же говорю, дефицит. Как ни посмотришь требования к С++-программисту, от года, или типа таких: V>
V>Требования к кандидату
V>• Понимание ООП проектирования и программирования
V>• Практический опыт разработки программ на С++ (MS Windows)
V>• Знания и практический опыт использование библиотек MFC, STL, Boost
V>• Практический опыт разработки многопоточных приложений (синхронизация, разделяемые данные, обмен сообщениями)
V>• Опыт командной работы
Это ищут студента на поддержку наследия 90-х?
V>Последние годы требования к плюсовикам настолько деградировали в объявлениях, что эти объявления можно читать как "ну придите же хоть кто-то". И предлагают там же ЗП, сопоставимую с разработчиками ASP.Net, для которых нехилый конкретный список требований, технологий, практик и т.д.
Это список с чем работал или читал,- он не отражает, какой сложности задача по силам.
V>Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место. Лучше посмотреть на каком-нить http://nyjobsource.com/ , бо у нас 99% спецов-плюсистов тупо уехало и не вернулось. Когда я последний раз внимательно смотрел, то ЗП С++ разработчиков легко были 140-170к, аналогичных по опыту дотнетчиков 100-120к.
Это вообще феерический бред. За "Знания и практический опыт использование библиотек MFC, STL, Boost" и опыт от 3 лет в Сиднее, к примеру, ищут на 65к, в глубокой ж за Westmead автобусом 20 минут.
Ваки на C++ на 140-200 есть, но они подразумевают нехилые знания финансов и какой-то опыт юниксового C++ (упор на финансы).
Здравствуйте, vdimas, Вы писали:
V>Еще посмотри популярный "read copy update". Дополнительно к блокировке писателей в этой модели удобно применить lock-free парадигму для любых многопоточных обновлений любых объектов, представляющих из себя состояние (не везде сказан про этот неплохой сценарий, приведу почти рабочий псевдокод): V>
V>Resource target; // целевой ресурс для обновления, лежит где-то мембером или статиком.
V>...
V>Resource resCurrent = target; // запоминаем локально ссылку на текущий экземпляр
V>do {
V> Resource res = resCurrent; // промежуточная переменная для оптимизации сценария CompareExchange
V> Resource resNew = MakeCopyOfSomeDeep(res); // здесь будет 1% всех исключений
V> Update(resNew, data); // обновляем локальную копию, здесь будет 99% всех исключений
V> // атомарно обновляем ссылку на данные, если до этого все прошло успешно
V>} while((currentTarget = Interlocked.CompareExchange(ref target, resNew, res)) != res);
V>
1) Зачем ты это написал?
2) Где тут блокировка писателей?
3) Если писать в функциональном стиле именно такой код и получается.
Еще раз, что ты хочешь сказать?
G>>Не спорю. Но ты на вопрос ответь. Ты предлагаешь тестировать негативные сценарии, которые по сути не нужны пользователю. Зачем это делать? G>>Ага, но если в десктопе писать большую часть приложения в таком же stateless стиле, то получается не хуже чем в вебе.
V>Не выйдет, ты же не только с данными работаешь, а со всем окружением вокруг программы, от которого изолирован в вебе. Если в вебе в случае ошибки ты отправил ее текс клиенту и "вышел", то в десктопе некуда выходить. Практически в КАЖДОМ сценарии тебе надо максимально адекватно обыграть любую ошибку. Без состояний на клиенте не обойтись. Напр, для твоего веба состоянием клиентской программы распоряжается браузер, + частично куки (хотя и тут гонки), и если для веба "нормально" показать ошибку и потерять нафик все результаты, например сообщение, которое тщательно 15 мин писал в этот форум прямо в браузере, то в обычной десктопной программе такое не прощается.
Ты не понял мысль. В десктопе можно точно также как в вед разделить state и логику. Логика stateless, state — это данные и интерфейс.
Логика будет "нейтральный по отношению к исключениям код", а изменение состояния интерфейса происходит только тогда когда отработала логика без ошибок. Естественно "сообщение которое писал 15 минут" не потеряется.
Обработка исключений будет сконцентрировала в PL, причем её можно не писать руками, а использовать runtime aop и policy injection для обработки.
V>А что я вижу порой и что имею ввиду? Такие лихие зацикливания в попытках "правильно" обработать ошибки в клиентских программах... В половине случаев в цикле начинают мне показывать сообщения об ошибке, избавиться от этого никак, только снять процесс. Помнится, первые версии решарпера это нам тоже демонстрировали во всей красе. Непервые ночные билды тоже. Это тебе дотнетная прога из первых рук. Или, например, программа работала нормально, но после первой же странной ошибки, стала показывать сообщения об ошибке на каждое действие. Я такого в нейтивных программах не помню оч. давно.
Нот, это происходит тупо потому что вставляют try\catch, который только и выводит сообщение, в итоге программа продолжает работать, но данные порушены и сразу же вылетает следующий exception итд. Причем от native\managed такое не зависит вообще, я видел подобно поведение и в программах на delphi, и на C++, и .NET или java.
Даже на курсах постоянно рассказываю истории про то что я видел именно в нативном коде на делфи. Там вообще ужос был с исключениями.
G>>Стейт как всегда присутствует в двух местах: интерфейс и хранилище данных. Первый нормально изолируется с помощью паттернов mv*, второй с помощью грамотно проработанных интерфейсов.
V>Ес-но, только у тебя "хранилище данных" — это и есть состояние твоей десктопной программы. С миллионном флагов и просто значений. И если ты сумеешь организовать транзакционность, т.е. чтобы обновление, скажем сотни полей, прошли либо все успешно, либо никто не прошел, то всё будет ок. Прямо как буд-то работаешь с транзакционной БД. О чем и речь. Просто в С++, ввиду того, что иногда приходится вручную следить, кто кем владеет и когда, безопасная схема слежения за ресурсами может быть только транзакционной или никакой. Устойчивость прикладной логики в этом случае — приятный бонус.
В .NET не надо схем городить, во-первых сборка мусора есть, во-вторых есть IoC-контейнеры, позволяющие централизовано управлять владением жизни объектов, в третьих писать логику надо с использованием immutable.
G>>Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее. А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.
V>Ну, если ты только клиента для БД пишешь, то у тебя тоже, большая часть сценариев сводится к staless, а транзакционность за тебя БД умеет.
А причем тут БД вообще? И что от того что она умеет транзакционность? Я вот видел "клиент для БД" который постоянно выдавал messagebox с ошибкой, причем он на вполне нативном delphi был написан.
Здравствуйте, samius, Вы писали:
V>>Пусть так. На C++, в отличие от, можно реализовать паттерн визитора в библиотечном виде. Я имею ввиду классический, который без тайп-тестов. И да, ни методы визитора, ни посещаемых объектов не обязаны быть виртуальными. По крайней сия библиотечная реализация не требует. S>При отсутствии виртуальных методов и тайп-теста (либо его заменителей) мы не сможем работать с subtype-полиморфными данными. А именно это мне требовалось.
Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут.
Поинт в том, что целевое мн-во объектов
V>>Цимус визитора в возможности расширения функциональности над семейством типов без изменения самого семейства, а остальные подробности несущественны. S>Это известно.
S>>>www.cs.cmu.edu/~rwh/theses/okasaki.pdf (8.4 Queues and Deques)
V>>Предположим, что с основными структурами данных я знаком, и даже представляю, как они организуются в функциональной парадигме. У нас же был вполне конкретный вопрос по механике С++ и сравнении возможностей генериков из C#, для какого-то совсем конкретного момента реализации, который не был показан. ИМХО, реализаций любого абстрактного алгоритма может быть гораздо больше одной, поэтому почти всегда можно выкрутиться. S>Естественно можем, но в случае с C++ придется ослабить типизацию, для того что бы работать с такой структурой в рантайме.
Во-первых, не вижу, откуда это следует. Во-вторых, там вообще работа по несчастным Cons, т.е. организации очереди на односвязанном списке, чтобы время доступа к обоим концам было O(n). Сорри, но я на коленке накатаю очередь, которая порвет эту многократно, и уж конечно будет тоже O(n). Бо мутабельный двусвязанный список всех описанных в той работе приседаний не требует... И там такой разный K при этом O(n) получается, что мама не горюй. Посмотри что происходит при двусторонней выборке. В общем, пусть у функциональщиков будут свои тараканы... ИМХО, в основу должны идти не алгоритмы, а требования. А уж алгоритмы берутся те, которые подходящие для инструмента, на котором мы решились эти требования удовлетворить.
Здравствуйте, gandjustas, Вы писали:
V>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения. G>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные
И ты, естественно, предположил, что обозначенный код выполнен однопоточным только из-за такого "неумения"? Силён, бродяга, ничего не скажешь.
Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации.
G>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.
Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Banned by IT, Вы писали:
I>>Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём. BBI>Не, из этих персонажей один сидит на жаббе, двое вовсе потерялись из программирования.
Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет.
I>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ... BBI>С моей конторы?
Здравствуйте, vdimas, Вы писали:
V>Дык, я же говорю, дефицит.
Странный какой то дефицит. В других областях дефицит разрабов — растет ЗП. Дефицит проектов — ЗП падает. А с С++ какой то особый дефицит
V>Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место.
Это вобщем признак того, что область сокращается и превращается в кружок по интересам, если приходися хедхантеров нанимать. У лисперов всяких еще лучше — "стукнул в аську и трое отозвались". Тонкость в том, что любой в городе кому нужны лисперы и так знает этих трёх С С++ скоро будет точно так же.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман? I>>У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?
ГВ>Unix.
Юник давно здох, его убил лялих который вышел в начале 90х. Остатки юникса это соляра, кое где еще встречается, да.
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Корпоративные сайты включают достаточно много функционала, часто это часть большей системы управления предприятием(чтото вроде), которая нынче редко пишется в нативном виде. В любом случае веб это вагоны проектов самых разных масштабов. А Офисов, к слову, хорошо если десяток наберется.
ГВ>Ну и что?
Цитирую себя:
"на менеджед пишется примерно 99% всех проектов"
I>>Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций.
ГВ>Потому что это единственный критерий, однозначно определяющий популярность.
"на менеджед пишется примерно 99% всех проектов"
А какое отношение к нашему вопросу имеет эта популярность ? Или идея в том, что писать надо только популярные проекты ?
ГВ>Размер кодовой базы — это просто размер кодовой базы. Максимум, о чём он может сказать, так это о том, какой язык популярен у разработчиков.
Размер кодовой базы позволяет оценить трудозатраты и худо бедно масштабы проекта. Это как раз к твоему вопросу про batch файлы. Но если хочешь, можешь все скрипты записывать в софт. Тогда и считать будем соответсвенно и доля с++ даже по популярным программам сокращается до нуля.
I>>Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.
ГВ>ИМХО, главное — это то, что популярность публично распространяемого софта прямо зависит от его потребительских качеств. Тут всё вместе: и выбор функциональности, и надёжность, и требовательность к ресурсам, и совместимость с неизвестно-каким-зоопарком.
РСДН как пример проекта который менеджед, годится или нет ? Если нет, то почему ?
>А корпоративный софт — совсем другая песня. Хотя бы потому, что затраты на него зачисляются на капитализацию, требования к аппаратуре и ПО может выставить и исполнитель, многое зависит от личных договорённостей или традиций "отдела автоматизации", а пользователи по указанию руководства сожрут любой кактус. То есть это совсем другая штука, на которую влияют другие факторы.
И что с того ? Это все равно индустрия софтописания и от этого никуда не деться. Сейчас в большинстве случаев кроме игр и единичных тобой перечисленых выгоднее иметь серверный софт == web == managed процентов на 90. Корпоративный это слабо сказал. Web будет гораздо лучше.
Здравствуйте, gandjustas, Вы писали:
V>>>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения. G>>>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные ГВ>>И ты, естественно, предположил, что обозначенный код выполнен однопоточным только из-за такого "неумения"? Силён, бродяга, ничего не скажешь. G>Да, я уверен в этом.
На каком основании?
G>Ты же сам говорил что код "читает из большой базы данных", но все известные мне движки СУБД отлично работают с несколькими соединениями из разных потоков. Потом привел код, который использует состояние объекта для передачи данных внтури метода, что тоже является признаком неумения.
1. Я сказал, что "движок СУБД" к делу не относится.
2. Ручаюсь, ты знаешь не про все "движки СУБД".
В общем, ты попал пальцем в небо. И если ты не понял: я не намерен раскрывать каких-либо фактических деталей, вроде "марки движка" или того, что я на самом деле скрыл под этим термином. Посему, давай, ты сосредоточишься только на тех аспектах, которые я назвал значимыми для этой истории.
На всякий случай ограничу контекст ещё раз:
— Код однопоточный и целесообразность такого решения не обсуждается;
— Многопоточность стряслась по ошибке, и причины этой ошибки тоже не обсуждаются (как бы тебе ни хотелось помахать жезлом архитектора);
— Квалификация специалистов, обратно, не обсуждается;
— Ошибки случаются у всех, тем более, если речь идёт об "исторических причинах";
Важно только то, что managed-среда молча проглотила коллизию, которая наверняка привела бы к падению unmanaged-аналога. Это самое проглатывание весьма затруднило поиски причин сбоя.
ГВ>>Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации. G>Ага, то есть саначла написали локи, потом оно начала дико тормозить,
Смешно. Где я говорил "локах", тем более, во множественном числе?
G>потом локи убрали возложив отвественность за синхронизацию на вызывающий код. А вызывающий код был написан вообще без мыслей о многопоточности, а потом она внезапно появилась. Причем как ты сам пишешь что race появился по ошибке.
О! Единственное более или менее правильное предположение (правда, оно почти полностью повторяет то, что я сказал). Да, код "стал многопоточным" по ошибке. Но ошибка была не где-то там в архитектуре (к чему ты клонишь), а в коде управления пуском-остановкой соответствующего потока. Однако, в чём конкретно она заключалась — снова выходит за рамки рассмотрения.
G>В итоге одна ошибка на другой.
Ну да, только с поправкой, что перечисленные тобой ошибки существуют исключительно в твоём воображении.
G>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики. ГВ>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию. G>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.
Конечно я не понимаю, куда мне? Один только gandjustas, который и рядом не стоял, уже разобрался в причинах, вплоть до архитектурных и готов развешивать всем сёстрам по серьгам.
Короче, перестань играть в Шерлока Холмса, у тебя не получается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I> I>>Кто тебе такое сказал ?
I> BBI>Реальность. Тупо пошарился по всем доступным компам.
I> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
А что сайты? Сайты крутятся на вполне себе нативных серверах Ну а что там используется в роли скриптового клея вообще параллельно. Впрочем, до распространенности похапэ, аспнету усе равно как до луны.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ikemefula, Вы писали:
I>> I>>Кто тебе такое сказал ?
I>> BBI>Реальность. Тупо пошарился по всем доступным компам.
I>> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
H>А что сайты? Сайты крутятся на вполне себе нативных серверах Ну
OS под которой серверы работают, вполне нативная. Вероятно я плохо выразился, речь была про серверные приложения, это чуть больше чем сайты-сервисы.
>а что там используется в роли скриптового клея вообще параллельно.
Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.
>Впрочем, до распространенности похапэ, аспнету усе равно как до луны.
И то и другое не нативная разработка, так что все в порядке.
Здравствуйте, Ikemefula, Вы писали:
I> I>> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
I> H>А что сайты? Сайты крутятся на вполне себе нативных серверах Ну
I> OS под которой серверы работают, вполне нативная. Вероятно я плохо выразился, речь была про серверные приложения, это чуть больше чем сайты-сервисы.
То есть именно слой клея ты назвал серверными приложениями?
I> >а что там используется в роли скриптового клея вообще параллельно.
I> Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.
А я о чем написал?
I> >Впрочем, до распространенности похапэ, аспнету усе равно как до луны.
I> И то и другое не нативная разработка, так что все в порядке.
Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
Здравствуйте, Ikemefula, Вы писали:
I>>>Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём. BBI>>Не, из этих персонажей один сидит на жаббе, двое вовсе потерялись из программирования.
I>Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет.
Ну так это проблемы с головой у этих контор.
I>>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ... BBI>>С моей конторы? I>Да.
Можно ознакомиться?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>Кто тебе такое сказал ? BBI>>Реальность. Тупо пошарился по всем доступным компам.
I>А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
Apache — native
IIS — native (где то там есть managed support)
MSSQL — native
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, hattab, Вы писали:
I>> OS под которой серверы работают, вполне нативная. Вероятно я плохо выразился, речь была про серверные приложения, это чуть больше чем сайты-сервисы.
H>То есть именно слой клея ты назвал серверными приложениями?
Кода в этом слое часто больше, чем нативном десктоп-приложении.
I>> Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.
H>А я о чем написал?
Так речь о том, что 99% софта это менеджед.
I>> И то и другое не нативная разработка, так что все в порядке.
H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.
Здравствуйте, Ikemefula, Вы писали:
I> H>То есть именно слой клея ты назвал серверными приложениями?
I> Кода в этом слое часто больше, чем нативном десктоп-приложении.
В среднем по больнице мерял?
I> I>> Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.
I> H>А я о чем написал?
I> Так речь о том, что 99% софта это менеджед.
Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?
I> I>> И то и другое не нативная разработка, так что все в порядке.
I> H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
I> То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.
Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.
Здравствуйте, Banned by IT, Вы писали:
I>>Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет. BBI>Ну так это проблемы с головой у этих контор.
Это проблемы не у этих контор, это общая проблема — количество заказов намного превывает возможности девелоперских контор.
I>>>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ... BBI>>>С моей конторы? I>>Да. BBI>Можно ознакомиться?
Здравствуйте, Banned by IT, Вы писали:
I>>А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ? BBI>Apache — native BBI>IIS — native (где то там есть managed support) BBI>MSSQL — native BBI>
Три штуки. А серверных приложений только на моем прошлом проекте с котороыми мне приходилось работать было несколько десятков, часть джава, часть дотнет.
Здравствуйте, hattab, Вы писали:
I>> Кода в этом слое часто больше, чем нативном десктоп-приложении.
H>В среднем по больнице мерял?
У меня достаточно широкий опыт
I>> Так речь о том, что 99% софта это менеджед.
H>Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?
Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.
I>> То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.
H>Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.
WoW является смешаным приложением Это ты сам хочешь назвать его нативным.
Здравствуйте, Ikemefula, Вы писали:
I> I>> Кода в этом слое часто больше, чем нативном десктоп-приложении.
I> H>В среднем по больнице мерял?
I> У меня достаточно широкий опыт
Не, ну ты давай уже конкретикой то делись: насколько часто, какие приложения рассматривал и т.д. А обтекаемыми формулировками говорить мы все умеем
I> H>Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?
I> Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.
И с чего ты решил, что все это в 99% реализуется на управляемом коде?
I> H>Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.
I> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.
Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является, он сам есть реализация исполняющей среды для внутренних скриптов.
Здравствуйте, hattab, Вы писали:
I>> Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.
H>И с чего ты решил, что все это в 99% реализуется на управляемом коде?
Разумеется не всё, иначе бы я написал 100% Цифра 99 очевидно это я утрировал имеющийся расклад. Если вычесть игры, то остаются долгоиграющие крупные проекты завязаные на железо, кишки ос и перформанс. Т.е. людей много, масштабы ого-го, а на выходе ровно один продукт. И, да, я знаю, игры пишутся на С++, представь себе. Зато в них вагоны кода _не_ C++ и даже не нативного. БОлее того, сейчас в чистом виде нативные С++ приложения уже сильно большая редкость, а вот чисто менеджед — запросто.
I>> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.
H>Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является,
Вот так новость — среда не является средой !
H>он сам есть реализация исполняющей среды для внутренних скриптов.
И тут же ты сам себя поправляешь Внутренние скрипты или не внутренние, разницы никакой, главное что модуль работает внутри управляющей(исполняющей) среды. Потому все скриптуемые приложения они смешаные, нативные + манеджед.
Здравствуйте, Ikemefula, Вы писали:
I> H>И с чего ты решил, что все это в 99% реализуется на управляемом коде?
I> Разумеется не всё, иначе бы я написал 100% Цифра 99 очевидно это я утрировал имеющийся расклад. Если вычесть игры, то остаются долгоиграющие крупные проекты завязаные на железо, кишки ос и перформанс. Т.е. людей много, масштабы ого-го, а на выходе ровно один продукт. И, да, я знаю, игры пишутся на С++, представь себе. Зато в них вагоны кода _не_ C++ и даже не нативного. БОлее того, сейчас в чистом виде нативные С++ приложения уже сильно большая редкость, а вот чисто менеджед — запросто.
Наличие скриптов в том или ином виде не делает приложение ненативным, не говори ерунды. Скрипты, часто, это просто легкая форма связывания кода.
I> I>> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.
I> H>Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является,
I> Вот так новость — среда не является средой !
I> H>он сам есть реализация исполняющей среды для внутренних скриптов.
I> И тут же ты сам себя поправляешь Внутренние скрипты или не внутренние, разницы никакой, главное что модуль работает внутри управляющей(исполняющей) среды. Потому все скриптуемые приложения они смешаные, нативные + манеджед.
Отлично, теперь я понял почему для тебя 99% софта является менеджед.
Здравствуйте, AndrewVK, Вы писали:
AVK> BBI>IIS — native (где то там есть managed support)
AVK> В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала.
Неотъемлемый кусок? Без него IIS перестанет быть веб-сервером?
Здравствуйте, AndrewVK, Вы писали:
AVK>В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала.
Ну вот висит у меня запущенный IIS. И в нём Procexp не показывает ничего managed.
Сайт при этом работает. Значит не такой уж и важный этот функционал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Константин Л., Вы писали:
КЛ>меня всегда смущало default-initialization вместо value-init. (если я верно помню термины из стандарта, но ты понял о чем я)
Ну здесь-то заведомо нетривиальный тип с конструктором, или ты о самой привычке?
Здравствуйте, AndrewVK, Вы писали:
AVK> H>Неотъемлемый кусок? Без него IIS перестанет быть веб-сервером?
AVK> IIS 7 это далеко не просто веб-сервер, это полноценный сервер приложений.
Ну так в том, что у IIS есть менеджед кусок для обеспечения функционирования менеджед аппов никто и не сомневался.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Л., Вы писали:
КЛ>>меня всегда смущало default-initialization вместо value-init. (если я верно помню термины из стандарта, но ты понял о чем я)
V>Ну здесь-то заведомо нетривиальный тип с конструктором, или ты о самой привычке?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Константин Л., Вы писали:
CS>>>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap. CS>>>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
КЛ>>что это за десяток things?
CS>Каждый DOM элемент в WPF это Common Language Runtime object instance. CS>Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д. CS>Десятки GCable things и набегают.
ну и черт с ними
CS>Во всех текущих HTML DOM имплементациях включая мою собственную DOM живет в non-manageable memory space (в терминах .NET) — используется простой и эффективный ref counting. CS>Если script не работает или он не трогает какие-то элементы то для них GCable wrapper и не создается. Т.е. GC скрипта сканирует очень ограниченный subset объектов.
ты реально знаешь за все текущие dom-имплементации?
CS>Плюс алгоритмы layout и rendering работают нативно и с нативными объектами. CS>Например у меня чтобы определить скажем значение overflow свойства из style элемента нужно просто прочитать значение поля struct style {...}. CS>Это одна машинная команда. Со всеми вытекающими.
ээ, а сколько машинных команд нужно в дотнете для такой же операции?
но не его имплементация
CS>Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser.
нельзя. WPF — реализация, HTML DOM — абстракция. Кто мне запретит реализовать WPF\xaml на unmanaged?
CS>Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий. CS>Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.
посыпаю голову пеплом — про evernote слышал только краем уха. Но быстрота нативного ни о чем не говорит.
H>Наличие скриптов в том или ином виде не делает приложение ненативным, не говори ерунды. Скрипты, часто, это просто легкая форма связывания кода.
Приложение со скриптами не может быть чисто нативным, потому что это приложение со скриптами. Потому получается простое разделение — нативные, смешаные, управляемые.
I>> H>он сам есть реализация исполняющей среды для внутренних скриптов.
I>> И тут же ты сам себя поправляешь Внутренние скрипты или не внутренние, разницы никакой, главное что модуль работает внутри управляющей(исполняющей) среды. Потому все скриптуемые приложения они смешаные, нативные + манеджед.
H>Отлично, теперь я понял почему для тебя 99% софта является менеджед.
Уже давно прошли времена, когда приложение приравнивалось к .exe файлу. Сейчас приложение это не только exe, но может быть даже и не exe, например js, bas и тд и тд и тд и тд.
Здравствуйте, Banned by IT, Вы писали:
AVK>>В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала. BBI>Ну вот висит у меня запущенный IIS. И в нём Procexp не показывает ничего managed. BBI>Сайт при этом работает. Значит не такой уж и важный этот функционал.
Согласно букварю по логике твой сайт не требует этот функционал.
Здравствуйте, Ikemefula, Вы писали:
I> H>Наличие скриптов в том или ином виде не делает приложение ненативным, не говори ерунды. Скрипты, часто, это просто легкая форма связывания кода.
I> Приложение со скриптами не может быть чисто нативным, потому что это приложение со скриптами. Потому получается простое разделение — нативные, смешаные, управляемые.
А приложение прочитавшее конфиг и выполнившее в зависимости от настроек те или иные действия тоже не может считаться нативным (явно же интерпретация проглядывает)? А чего, конфиг вполне себе вырожденный случай скрипта
I> I>> H>он сам есть реализация исполняющей среды для внутренних скриптов.
I> I>> И тут же ты сам себя поправляешь Внутренние скрипты или не внутренние, разницы никакой, главное что модуль работает внутри управляющей(исполняющей) среды. Потому все скриптуемые приложения они смешаные, нативные + манеджед.
I> H>Отлично, теперь я понял почему для тебя 99% софта является менеджед.
I> Уже давно прошли времена, когда приложение приравнивалось к .exe файлу. Сейчас приложение это не только exe, но может быть даже и не exe, например js, bas и тд и тд и тд и тд.
Здравствуйте, vdimas, Вы писали:
S>>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
V>Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем.
Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты.
V>У дотнетных приложений есть своя ниша, где эффективность не важна. Утилиты какие-нить, всякие SOAP-сервисы, генерация HTML и прочее из той же оперы... ИМХО, споры возникают по причине неправильного позиционирования дотнета. Как только обсуждающие сходятся на том, что каждому инструменту своя ниша, так споры утихают сами собой.
Здравствуйте, hattab, Вы писали:
I>> Приложение со скриптами не может быть чисто нативным, потому что это приложение со скриптами. Потому получается простое разделение — нативные, смешаные, управляемые.
H>А приложение прочитавшее конфиг и выполнившее в зависимости от настроек те или иные действия тоже не может считаться нативным (явно же интерпретация проглядывает)? А чего, конфиг вполне себе вырожденный случай скрипта
Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной.
XML и большая часть языков в конфигах не обладают полнотой по тьюрингу.
I>> H>Отлично, теперь я понял почему для тебя 99% софта является менеджед.
I>> Уже давно прошли времена, когда приложение приравнивалось к .exe файлу. Сейчас приложение это не только exe, но может быть даже и не exe, например js, bas и тд и тд и тд и тд.
H>Это ты к чему вообще?
99% софта не является нативным. В понятие "софт" включаем и все модули-плагны-аддоны-расширения и все сайты-сервисы и тд и тд какие только были написаны по сей день.
V>>Последние годы требования к плюсовикам настолько деградировали в объявлениях, что эти объявления можно читать как "ну придите же хоть кто-то". И предлагают там же ЗП, сопоставимую с разработчиками ASP.Net, для которых нехилый конкретный список требований, технологий, практик и т.д. AG>Это список с чем работал или читал,- он не отражает, какой сложности задача по силам.
И раньше не отражал. Но это объективное наблюдение, что требования к программистам С++ год от года выхолащиваются... готовы брать кого угодно, лишь бы проявлял интерес к писанине на плюсах. Лет 10 назад это было немыслимо.
V>>Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место. Лучше посмотреть на каком-нить http://nyjobsource.com/ , бо у нас 99% спецов-плюсистов тупо уехало и не вернулось. Когда я последний раз внимательно смотрел, то ЗП С++ разработчиков легко были 140-170к, аналогичных по опыту дотнетчиков 100-120к. AG>Это вообще феерический бред. За "Знания и практический опыт использование библиотек MFC, STL, Boost" и опыт от 3 лет в Сиднее, к примеру, ищут на 65к, в глубокой ж за Westmead автобусом 20 минут.
А в Киеве дядька.
AG>Ваки на C++ на 140-200 есть, но они подразумевают нехилые знания финансов и какой-то опыт юниксового C++ (упор на финансы).
А что в финансах знать-то надо конкретно разработчику? Не столько именно финансы надо знать, сколько уметь обслуживать требования к IT в финансовой сфере, что является чуть более универсальными навыками. Да и не только в финансовых областях около 140 и выше вакансии наблюдал. Практически везде, где речь идет о чем-то нетривиальном.
Здравствуйте, Ikemefula, Вы писали:
I> H>А приложение прочитавшее конфиг и выполнившее в зависимости от настроек те или иные действия тоже не может считаться нативным (явно же интерпретация проглядывает)? А чего, конфиг вполне себе вырожденный случай скрипта
I> Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной.
А Ворд нативный софт (доки могут иметь полноценные скрипты)? А, скажем, сервер БД с поддержкой хранимых процедур? Ты видимо думаешь, что это софт смешанный. Но этот софт нативный т.к. нативность определяется не наличием или отсутствием скриптового движка, а реализацией непосредственной функциональности софта.
Здравствуйте, Ikemefula, Вы писали:
I>А у тебя что, монопольное право тыкать в недостатки платформы ? Или дотнетчиками надо молча слушать твои плевки в сторону дотнета ?
Дабы не растекаться мысию по древу, отошлю тебя к вот этому
моему сообщению, там, по-моему, достаточно подробно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
S>>>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов. V>>Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем. I>Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты.
К чему это ты?
V>>У дотнетных приложений есть своя ниша, где эффективность не важна. Утилиты какие-нить, всякие SOAP-сервисы, генерация HTML и прочее из той же оперы... ИМХО, споры возникают по причине неправильного позиционирования дотнета. Как только обсуждающие сходятся на том, что каждому инструменту своя ниша, так споры утихают сами собой. I>Ты путаешь производительность и эффективность.
Значение слова "эффективность" определяется контекстом, а тут понятно, что речь идёт именно о производительности. Короче, не цепляйся к словам попусту.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
S>>>>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов. V>>>Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем. I>>Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты.
ГВ>К чему это ты?
Да к тому же что и раньше — нет и не будет никакого ренесанса С++ и подобной ерунды. Доля нативной разработки чуток увеличится и все. Сначала была мода на джаву и дотнет и потому многие кинулись чуть не драйвера и низкоуровненвый рендеринг писать на C#. Вот такие проекты отсохнут сами собой и за счет этого увеличится доля нативной разработки.
Но рассуждатели по твоей ссылке почему то не учли рост объемов памяти, воможность значительно расширения возможностей системной шины, векторную графику и тд и тд. Так что нет никакого конца нересурсов. То есть, нынче узким местом является не процессорное время, а ввод-вывод тот же. Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
Здравствуйте, Ikemefula, Вы писали:
I>Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной. I>XML и большая часть языков в конфигах не обладают полнотой по тьюрингу. I>99% софта не является нативным. В понятие "софт" включаем и все модули-плагны-аддоны-расширения и все сайты-сервисы и тд и тд какие только были написаны по сей день.
Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, hattab, Вы писали:
I>> Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной.
H>А Ворд нативный софт (доки могут иметь полноценные скрипты)?
Не знаю, использует ли ворд скрипты внутри приложения. Доки это не ворд и нативного в них ничего нет.
>А, скажем, сервер БД с поддержкой хранимых процедур? Ты видимо думаешь, что это софт смешанный. Но этот софт нативный т.к. нативность определяется не наличием или отсутствием скриптового движка, а реализацией непосредственной функциональности софта.
Я определяею нативность в зависимости от реализации непосредственной функциональности софта. Если это нативный с++ , то прилага нативная. Если это нативный с++ вперемешку с js, vb или lua — это смешаное. Если же только js, то очевидно это вообще не нативное приложение.
Реализации непосредственной функциональности ворда никак не зависит от документов, которые ты открываешь в ворде. Вот если движок для скриптов, работы с доками и тд полностью нативный, значит ворд нативная софтина. Если там есть скрипты — значит смешаная.
Здравствуйте, Ikemefula, Вы писали:
I>>>Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты. ГВ>>К чему это ты? I>Да к тому же что и раньше — нет и не будет никакого ренесанса С++ и подобной ерунды. Доля нативной разработки чуток увеличится и все. Сначала была мода на джаву и дотнет и потому многие кинулись чуть не драйвера и низкоуровненвый рендеринг писать на C#. Вот такие проекты отсохнут сами собой и за счет этого увеличится доля нативной разработки.
Хм. Взаимопротиворечивые предложения detected.
I>Но рассуждатели по твоей ссылке почему то не учли рост объемов памяти, воможность значительно расширения возможностей системной шины, векторную графику и тд и тд. Так что нет никакого конца нересурсов. То есть, нынче узким местом является не процессорное время, а ввод-вывод тот же.
Рассуждатели по моей ссылке делают такие выводы:
Applying these conservative scaling
projections, half of that ideal gain vanishes; the path to 8nm in
2018 results in a best-case average 3.7 speedup; approximately
14% per year for highly parallel codes and optimal per-benchmark
configurations. The returns will certainly be lower in practice.
I>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
Производительность CPU от диска не зависит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%.
Для кого он не является узким местом?
I>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс. ГВ>>Производительность CPU от диска не зависит.
I>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.
Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%.
ГВ>Для кого он не является узким местом?
Для приложений.
I>>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс. ГВ>>>Производительность CPU от диска не зависит.
I>>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.
ГВ>Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?
Смотря какой. Судя по тому, что в последние годы менеджед появился даже в HPC, не все так просто.
Здравствуйте, Ikemefula, Вы писали:
I> I>> Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной.
I> H>А Ворд нативный софт (доки могут иметь полноценные скрипты)?
I> Не знаю, использует ли ворд скрипты внутри приложения. Доки это не ворд и нативного в них ничего нет.
Доки никто нативными не называет. Но доки могу содержать скрипты на Тьюринг-полном языке, а Ворд умеет их выполнять. Так Ворд нативный или нет?
I> >А, скажем, сервер БД с поддержкой хранимых процедур? Ты видимо думаешь, что это софт смешанный. Но этот софт нативный т.к. нативность определяется не наличием или отсутствием скриптового движка, а реализацией непосредственной функциональности софта.
I> Я определяею нативность в зависимости от реализации непосредственной функциональности софта. Если это нативный с++ , то прилага нативная. Если это нативный с++ вперемешку с js, vb или lua — это смешаное. Если же только js, то очевидно это вообще не нативное приложение.
Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется. Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).
I> Реализации непосредственной функциональности ворда никак не зависит от документов, которые ты открываешь в ворде. Вот если движок для скриптов, работы с доками и тд полностью нативный, значит ворд нативная софтина. Если там есть скрипты — значит смешаная.
Непосредственная функциональность Ворда заключается в том числе и в корректной интерпретации документов имеющих скрипты. С игрушками точно также. Что такое игрушка? Грубо говоря, это движок способный корректно интерпретировать данные уровня и его скрипты.
Здравствуйте, Ikemefula, Вы писали:
I>>>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%. ГВ>>Для кого он не является узким местом? I>Для приложений.
Для каких? Ты сейчас говорил только о настольных, притом нативных.
I>>>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс. ГВ>>>>Производительность CPU от диска не зависит. I>>>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU. ГВ>>Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?
I>Смотря какой. Судя по тому, что в последние годы менеджед появился даже в HPC, не все так просто.
HPC — это high performance computing? Если так, то где там появился managed?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Ikemefula, Вы писали:
I>>>>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%. ГВ>>>Для кого он не является узким местом? I>>Для приложений.
ГВ>Для каких? Ты сейчас говорил только о настольных, притом нативных.
десктоп, веб, серверные приложения всяких сортов. Процессор критичен для HPC и всякая всячина связаная с обработкой изображений, видео, звука и тд.
I>>Смотря какой. Судя по тому, что в последние годы менеджед появился даже в HPC, не все так просто.
ГВ>HPC — это high performance computing? Если так, то где там появился managed?
Здравствуйте, Ikemefula, Вы писали:
I>Гуру это не тот кто знает всё, это тот кто знат намного больше средней массы и встречается в силу этого сильно редко. Ты просто не понял иронии. Бывает.
Это ты щас сам придумал? Сходи что ли в толковый словарь загляни.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
ГВ>>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. BBI>>Это синдром VladD2
I>Угу, и у Сиплюсников он проявляется слишком остро.
Что, опять у тебя острый приступ попаболи?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
BBI>>Сайт при этом работает. Значит не такой уж и важный этот функционал. I>Согласно букварю по логике твой сайт не требует этот функционал.
Спасибо Кэп!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
I>>Гуру это не тот кто знает всё, это тот кто знат намного больше средней массы и встречается в силу этого сильно редко. Ты просто не понял иронии. Бывает. BBI>Это ты щас сам придумал? Сходи что ли в толковый словарь загляни.
"Индийский термин, более или менее соответствующий слову учитель."
Учитель это, к слову, не тот, кто знает всё. Это тот кто знает намного больше средней массы да еще способен учить.
Здравствуйте, Banned by IT, Вы писали:
BBI>>>Сайт при этом работает. Значит не такой уж и важный этот функционал. I>>Согласно букварю по логике твой сайт не требует этот функционал. BBI>Спасибо Кэп!
Не за что. Вопрос, как ты вывел "не такой уж и важный этот функционал." остаётся открытым согласно тому же букварю. Надеюсь в твоем сайте больше одной странички ?
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, Ikemefula, Вы писали:
ГВ>>>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. BBI>>>Это синдром VladD2
I>>Угу, и у Сиплюсников он проявляется слишком остро.
BBI>Что, опять у тебя острый приступ попаболи?
Не у меня, а у тебя. Это ж ты выискиваешь синдромы.
Здравствуйте, Ikemefula, Вы писали:
I> H>Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется. Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).
I> Если сервер БД свой непосредтсвенный функционал реализует в т.ч. на скриптах, то это смешаное приложение. Например если в консольном олдскульном WINAPI приложении на языке с напишу примерно следуеющее
I>
I> ТО очевидно приложение сразу становится смешаным, т.к. использует джаваскрипт для реализации своего функционала.
Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:
new Window(320, 240);
Window.Add(new Button(10, 10, 'OK'));
Window.Show;
Приложение использующее такой скрипт не будет являться смешанным.
I> H>Непосредственная функциональность Ворда заключается в том числе и в корректной интерпретации документов имеющих скрипты.
I> Интерпретатор может быть и нативным, представь себе весь ужас.
А кто спорит?
I> >С игрушками точно также. Что такое игрушка? Грубо говоря, это движок способный корректно интерпретировать данные уровня и его скрипты.
I> Вот раз "и его скрипты", то следовательно приложение смешаное.
Его — уровня. Скрипты, тем более в игрушках, обычно, очень высокоуровневые т.е. осуществляющие, по большей части, связку нативного кода, а не реализацию непосредственной функциональности. Потому такие приложения считаться даже смешанными, не то что управляемыми, не могут.
Здравствуйте, DarkGray, Вы писали:
DG> H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:
DG> кто при этом следит за освобождением памяти? DG> используются ли массивы в таком скрипте? проверяется ли при этом выход за границы массива?
DG> H>
G>>См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.
V>Где ты видел выставление за правило? Это был лишь контраргумент насчет того "а у вас программы падают!". Дык, плюсист всегда рад, когда нерабочая программа падает, а не продолжает делать вид, будто честно работает, как это принято в джаве и дотнете.
V>К тому же, наблюдал случай у коллег, что программа работала с ошибкой при какой-то там смене ситуации и клиент потерял энное кол-во тыщ нерусских денег за несколько минут... Лучше бы она просто упала нафик тогда. Но, к сожалению, ошибкой был не "проход по памяти и прочее из ада С++", а сугубо логическая ошибка.
Еще раз: это случайно что она падает, а managed продолжает работать. В большинстве случаев неправильная concurrency не приводит к падению ни managed, ни unmanaged программ.
Именно поэтому часто встраивают защиту от обращения из разных потоков, как в UI.
G>>Нет, баги еще бывают когда неправильно поняли что нужно сделать на каком либо этапе передачи данных от заказчика программисту. Но их тут мы не рассматриваем.
V>Не льсти себе. Баги просто "бывают", даже при идеальной спецификации и идеальном процессе. Даже у самых что ни на есть мегакрутейших сферических программистов. А у нас с тобой и подавно. Поэтому-то интерес предоставляют не сами баги или причины их появления (кроме систематических причин), а гораздо интереснее пути попадания багов в продакшн. Прочувствуй разницу.
Есть тестирование чтобы предотвратить случайные ошибки, есть управляемые среды, которые просто не допускают некоторые классы ошибок. Процент багов, связанных с неправильным кодированием, попадающими в production очень низок.
V>И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию.
Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна).
G>>Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.
V>Да не расшаришь ты никакое состояние с требованием отклика в единицы микросекунд. Между процессорами и то сложно, разве что м/у ядрами получается. И да, узел, обрабатывающий информацию и принимающий решения, работает не так, как узел, выдающий информацию по запросу — поток информации тут противоположный.
Вот я тебе об этом и говорю. В вебе время отклика важно всегда, далеко не всегда это микросекунды, но объем обрабатываемых данных огромный и одна машина не всегда справляется с нагрузкой.
Так что о недостатке воображения ты зря.
А разницы между потоком и запросом почти нету на самом деле. Можно одно свести к другому и наоборот.
Здравствуйте, DarkGray, Вы писали:
DG> H>Это все частности. Смысл их обсуждать?
DG> именно эти частности — и дают отличие native от managed. DG> если в скрипте есть проверка на выход за границы — это уже managed, если есть gc — то тем более.
Здравствуйте, c-smile, Вы писали:
CS>Проблема не в самом GC как процессе сборки мусора. А скорее в самой архитекуре managed объектов обусловленных нуждами этого GC. Там где в native code я могу например выделить память под контейнер одним куском CS>
CS>struct items {
CS> ...
CS> int _n_items;
CS> T _items[0];
CS>}
CS>
CS>и получу оптимальную структуру с точки зрения data caching в процессоре и пр.
CS>В managed средах ты просто вынужден писать нечто типа CS>
CS>Короче — за все приходится платить — manageabilty не дешевое удовольствие.
Ты не путай managed и safe. Не все что managed является safe, а вот наоборот скорее всего является.
CS>В native code я например могу спроецировать DB на память — т.е. получение access к данным это тривиальный pointer на память. Быстро и дешево (по памяти).
Особенно когда БД находится на другом сервере
Вообще-то БД оптимизируют считывание с диска, это гораздо более дорогая операция, чем копирование памяти. А если получать указатель на замапленные файлы данных, то придется читывать все.
А мапить обычные файлы в managed можно.
CS>В случае с managed — пляски с бубном и GC cycles как результат. В native code свободы для оптимальных решений на порядки больше. Вот и результат.
И ты сходу привел решение, далекое от оптимальности
Здравствуйте, hattab, Вы писали:
H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:
Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.
H>Приложение использующее такой скрипт не будет являться смешанным.
Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .
I>> Вот раз "и его скрипты", то следовательно приложение смешаное.
H>Его — уровня. Скрипты, тем более в игрушках, обычно, очень высокоуровневые т.е. осуществляющие, по большей части, связку нативного кода, а не реализацию непосредственной функциональности. Потому такие приложения считаться даже смешанными, не то что управляемыми, не могут.
Во первых, про связку, см. выше.
Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.
Здравствуйте, Ikemefula, Вы писали:
I>>>>>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%. ГВ>>>>Для кого он не является узким местом? I>>>Для приложений.
ГВ>>Для каких? Ты сейчас говорил только о настольных, притом нативных.
I>десктоп, веб, серверные приложения всяких сортов.
ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.
I>Процессор критичен для HPC и всякая всячина связаная с обработкой изображений, видео, звука и тд.
akuznetsov12 октября 2010, 11:49
А на сколько в java по сравнению с C производительность теряется?
ahriman12 октября 2010, 12:12
Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.
Этому вопросу отдельный пост будет посвящён с более оптимизированными программами (что очень важно, так как в этой программе на Java не использованы потоки, а они способны резко увеличить производительность), графиками и диаграммами.
Так что да, не всё так просто.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
H>>Это все частности. Смысл их обсуждать?
DG>именно эти частности — и дают отличие native от managed. DG>если в скрипте есть проверка на выход за границы — это уже managed, если есть gc — то тем более. DG>дальше этот managed быть тотальным (все операции проверяются), или не тотальным (проверяется только часть операций, и есть операции которые позволяют выйти за пределы массива и выделить память в обход gc)
Здравствуйте, Геннадий Васильев, Вы писали:
I>>десктоп, веб, серверные приложения всяких сортов.
ГВ>ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.
"принято не оглядываться " — это миф. Принято учитывать реальные приоритеты. И вот здесь экономия процессора не всегда имеет приоритет. Экономия IO как правило имеет куда более высокий приоритет.
ГВ>ahriman12 октября 2010, 12:12 ГВ>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.
Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.
Здравствуйте, Ikemefula, Вы писали:
I>>>десктоп, веб, серверные приложения всяких сортов. ГВ>>ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.
I>"принято не оглядываться " — это миф. Принято учитывать реальные приоритеты. И вот здесь экономия процессора не всегда имеет приоритет. Экономия IO как правило имеет куда более высокий приоритет.
Зачастую — да. Только это никак не противоречит тому, что я написал.
ГВ>>ahriman12 октября 2010, 12:12 ГВ>>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.
I>Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.
Для HPC актуальна performance. Ваш К.О.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I> H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:
I> Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.
Я не про обязанность, я про выполняемую работу.
I> H>Приложение использующее такой скрипт не будет являться смешанным.
I> Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .
Заостряя внимание на связывании кода, я даю тебе понять, что непосредственная функциональность приложения обеспечивается не скриптом, а нативным кодом.
I> H>Его — уровня. Скрипты, тем более в игрушках, обычно, очень высокоуровневые т.е. осуществляющие, по большей части, связку нативного кода, а не реализацию непосредственной функциональности. Потому такие приложения считаться даже смешанными, не то что управляемыми, не могут.
I> Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.
Я же не зря сказал о том, что игрушечные скрипты очень высокоуровневые (подумай над этим). Разумеется, использование скриптов очень удобно т.к. позволяет отстроить игровую логику и законы сильно быстрее, чем непосредственно "вкомпилированные" алгоритмы, но это все равно не более чем клеевой слой. Ты можешь сам глянуть на Lua-скрипты от FarCry и посмотреть, много ли работы они делают.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>ahriman12 октября 2010, 12:12 ГВ>>>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.
I>>Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.
ГВ>Для HPC актуальна performance. Ваш К.О.
Здравствуйте, hattab, Вы писали:
I>> H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:
I>> Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.
H>Я не про обязанность, я про выполняемую работу.
Это одно и то же. Если код выполняет работу связывания компонентов, то это значит, что у этого кода обязанность — связывание компонентов.
I>> Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .
H>Заостряя внимание на связывании кода, я даю тебе понять, что непосредственная функциональность приложения обеспечивается не скриптом, а нативным кодом.
Эдак мы дойдем до того, что всю работу делают ОС, процессор и тд, а стало быть все софтины нативные.
I>> Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.
H>Я же не зря сказал о том, что игрушечные скрипты очень высокоуровневые (подумай над этим).
Ты лушче сам думай. Предполагается, если ты увидел изъян в рассуждениях, то можешь продемонстрировать это некоторым тестом. Если такого нет — сэкономь лучше траффик
>Разумеется, использование скриптов очень удобно т.к. позволяет отстроить игровую логику и законы сильно быстрее, чем непосредственно "вкомпилированные" алгоритмы, но это все равно не более чем клеевой слой. Ты можешь сам глянуть на Lua-скрипты от FarCry и посмотреть, много ли работы они делают.
Неважно, много или мало. Главное что взаимодействие это очень важная часть и её нельзя выбросить.
Здравствуйте, Ikemefula, Вы писали:
I>>>Я про такой ничего не знал. Как бы под Lisp обычно подразумевают Common Lisp DE>>SBCL — это common lisp и есть.
I>Хорошо, все программы — нативные, все программы — менеджед, все программы — интерпретируемые
Ну, поскольку процессор умеет исполнять только нативный код, то, думаю, можно ограничиться первым.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
I> H>Я не про обязанность, я про выполняемую работу.
I> Это одно и то же. Если код выполняет работу связывания компонентов, то это значит, что у этого кода обязанность — связывание компонентов.
Речь не про обязанности. Речь таки о выполняемой работе. Называть приложение управляемым, тогда, как вся работа делается нативным кодом, это нужно очень хотеть быть правым во что бы то нибыло
I> H>Заостряя внимание на связывании кода, я даю тебе понять, что непосредственная функциональность приложения обеспечивается не скриптом, а нативным кодом.
I> Эдак мы дойдем до того, что всю работу делают ОС, процессор и тд, а стало быть все софтины нативные.
Конечно же нет. ОС, CPU, GPU и прочее спокойно выносится за скобки, странно этого не понимать
I> I>> Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.
I> H>Я же не зря сказал о том, что игрушечные скрипты очень высокоуровневые (подумай над этим).
I> Ты лушче сам думай. Предполагается, если ты увидел изъян в рассуждениях, то можешь продемонстрировать это некоторым тестом. Если такого нет — сэкономь лучше траффик
Так я уже давал пример скрипта Ты правда начал говорить о каких-то обязанностях, потому я и предложил тебе подумать Впрочем, я не настаиваю.
I> >Разумеется, использование скриптов очень удобно т.к. позволяет отстроить игровую логику и законы сильно быстрее, чем непосредственно "вкомпилированные" алгоритмы, но это все равно не более чем клеевой слой. Ты можешь сам глянуть на Lua-скрипты от FarCry и посмотреть, много ли работы они делают.
I> Неважно, много или мало. Главное что взаимодействие это очень важная часть и её нельзя выбросить.
Конечно же важно. Не люблю аналогии, но иначе мысли похоже не пробиться... кирпичные дома называются кирпичными, а не цементнорастворными, почему-то...
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Ikemefula, Вы писали:
I>>>>Отлично. Все программы — нативные. А следовательно быть никакого ренесанса и конца нересурсов быть не может. ГВ>>>Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк. I>>Да не вопрос. Но других то определений нет и не предвидится
ГВ>А зачем оно нужно? Есть классические определения: интерпретатор, компилятор, исходный текст, p-код, код целевого процессора. Native — это сокращение для жёлтой прессы: что, мол, native development бла-бла-бла. Обозначают им программы на C и C++. ГВ>А то развели, понимаешь — указатели, работа с ОС... Осталось грамматики и аппаратные прерывания сюда приплести.
А если в программе куча кода не только на C и C++, как быть ?
Здравствуйте, Ikemefula, Вы писали:
I>А если в программе куча кода не только на C и C++, как быть ?
А что ты хочешь доказать/показать/выяснить?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
I>>А если в программе куча кода не только на C и C++, как быть ?
ГВ>А что ты хочешь доказать/показать/выяснить?
Да тоже самое — какая часть кода пишется на нативном С++/C, а какая — на чем то другом (99%)
Здравствуйте, Ikemefula, Вы писали:
I>>>А если в программе куча кода не только на C и C++, как быть ? ГВ>>А что ты хочешь доказать/показать/выяснить?
I>Да тоже самое — какая часть кода пишется на нативном С++/C, а какая — на чем то другом (99%)
Так посчитай и сравни. Зачем для этого какие-то определения выдумывать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>HPC — это high performance computing? Если так, то где там появился managed?
Он там довольно давно присутствовал. По крайней мере ввиде Java. Специфика многих областей HPC в том, что количество прогонов программы может быть очень небольшим, и намного важнее с точки зрения скорости получения результата от постановки задачи — скорость разработки. Вот такой вот парадокс. Если что, это не я придумал, это Кирилл Фаенов рассказывал как то.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, c-smile, Вы писали:
CS>Пора переходить к конкретике.
Справедливости ради, конкретики нет с обеих сторон. Нужно обсуждать конкретные решения по части .Net и WPF, которые принимала команда Evernote.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>HPC — это high performance computing? Если так, то где там появился managed?
AVK>Он там довольно давно присутствовал. По крайней мере ввиде Java. Специфика многих областей HPC в том, что количество прогонов программы может быть очень небольшим, и намного важнее с точки зрения скорости получения результата от постановки задачи — скорость разработки. Вот такой вот парадокс. Если что, это не я придумал, это Кирилл Фаенов рассказывал как то.
На парадокс не похоже. Если у нас есть возможность поставить вычислительный комплекс, допустим, в сотню раз более быстрый, то какая разница — даже если программа потребует десятикратно больше процессорных ресурсов, всё равно мы будем в выигрыше. Вполне логично сделать акцент на производительности труда программиста.
Только тут всё равно присутствует эта составляющая "нересурсности", ведь ключевое слово — "если есть возможность поднять производительность аппаратуры". Саттер не случайно ссылается на вот эту работу — там как раз говорят, что скорость роста производительности сейчас очень сильно упала и не совсем понятно, что со всем этим делать. Апеллировать к тому, что сегодняшних скоростей вполне достаточно, ИМХО, бессмысленно — один очень известный человек уже когда-то уверял, что "640 килобайт хватит любому". Время идёт, желания растут...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>На парадокс не похоже. Если у нас есть возможность поставить вычислительный комплекс, допустим, в сотню раз более быстрый
Такой возможности обычно нет. Дело в другом — программа на С++ пусть будет считать на час меньше. А разработка с его использованием будет на месяц дольше. Такием образом, если нам нужен десяток-другой прогонов, то быстрее получить эти результаты с помощью Java.
ГВ>Только тут всё равно присутствует эта составляющая "нересурсности"
В том что я написал — нет, не присутствует.
ГВ>, ведь ключевое слово — "если есть возможность поднять производительность аппаратуры"
Удобно у самого же себя находить подтверждение своим же теориям?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет.
ГВ>Я бы сказал не так.
Кто бы сомневался. Только вот факта это не изменит.
ГВ>Ergo, не такие они и бессмысленные — эти самые споры о терминах.
Именно такие.
ГВ> Ну и лулзы опять таки, куда ж без них?
Демагогия и троллинг. Неприглядная картинка.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Только тут всё равно присутствует эта составляющая "нересурсности" AVK>В том что я написал — нет, не присутствует.
Присутствует, и ещё как! Если мы можем пренебречь потреблением CPU для расчётов — то вот она, "нересурсность" в чистом виде. Кстати, я не спорю, что есть задачи, для которых приоритетна производительность программиста и их, таких задач, достаточно много. Просто одно другого не отменяет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет. ГВ>>Я бы сказал не так.
AVK>Кто бы сомневался. Только вот факта это не изменит.
Контекст тоже не изменится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Такой возможности обычно нет. Дело в другом — программа на С++ пусть будет считать на час меньше. А разработка с его использованием будет на месяц дольше. Такием образом, если нам нужен десяток-другой прогонов, то быстрее получить эти результаты с помощью Java.
Для таких расчетов гораздо лучшим вариантом чем ява может оказаться что-то из класса MATLAB или R или питон со SciPy.
Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.
Вот питон уже вряд ли. Там разница на числомолочении будет пару порядков.
FR>Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.
А смысел тогда в питоне? Это ж не коробка, там большая часть кода — собственно вычисления, обязочный код минимален.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Для таких расчетов гораздо лучшим вариантом чем ява может оказаться что-то из класса MATLAB
AVK>Возможно. А может и нет.
С большей вероятностью да.
FR>>или питон со SciPy.
AVK>Вот питон уже вряд ли. Там разница на числомолочении будет пару порядков.
А числомолочением питон заниматься и не будет, это сделают хорошо оптимизированные (более быстрые чем на яве)
C/C++ библиотеки. Тот же SciPy как пример.
FR>>Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.
AVK>А смысел тогда в питоне? Это ж не коробка, там большая часть кода — собственно вычисления, обязочный код минимален.
Смысл в том что для большинства задач в том же SciPy есть кусочки из которых можно собрать решение, дописать
же недостающее это не писать все на си.
Здравствуйте, gandjustas, Вы писали:
ГВ>>Ты их по скорости сравнивал? G>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.
Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>При отсутствии виртуальных методов и тайп-теста (либо его заменителей) мы не сможем работать с subtype-полиморфными данными. А именно это мне требовалось.
V>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут.
А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
V>>>Предположим, что с основными структурами данных я знаком, и даже представляю, как они организуются в функциональной парадигме. У нас же был вполне конкретный вопрос по механике С++ и сравнении возможностей генериков из C#, для какого-то совсем конкретного момента реализации, который не был показан. ИМХО, реализаций любого абстрактного алгоритма может быть гораздо больше одной, поэтому почти всегда можно выкрутиться. S>>Естественно можем, но в случае с C++ придется ослабить типизацию, для того что бы работать с такой структурой в рантайме.
V>Во-первых, не вижу, откуда это следует.
Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
V>Во-вторых, там вообще работа по несчастным Cons, т.е. организации очереди на односвязанном списке, чтобы время доступа к обоим концам было O(n). Сорри, но я на коленке накатаю очередь, которая порвет эту многократно, и уж конечно будет тоже O(n).
Theorem 8.3 snoc and tail run in O(1) amortized time.
Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
V>Бо мутабельный двусвязанный список всех описанных в той работе приседаний не требует... И там такой разный K при этом O(n) получается, что мама не горюй. Посмотри что происходит при двусторонней выборке. В общем, пусть у функциональщиков будут свои тараканы...
По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
V>ИМХО, в основу должны идти не алгоритмы, а требования. А уж алгоритмы берутся те, которые подходящие для инструмента, на котором мы решились эти требования удовлетворить.
В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта. G>>Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.
V>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере.
По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
V>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился.
Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json. Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
V>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.
Посмотри сколько данный форум возвращает, и не говори бредятину.
V>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом.
Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
V>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++)
Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
V>Ну и даже брать задачи работы с БД, где ASP.Net якобы является "удачной прослойкой"... Дотнетный парсер потока MS SQL сливает нейтивному в 4-5 раз (а то и более, если идет много числовых полей и мало строковых). Т.е. на сегодня ситуация такова, что нейтивный MS SQL способен выдавать данные быстрее, чем дотнетные приложения способны парсить его ответ... Хохма натуральная. Уже на гигабитных картейках в локалке это видно во всей красе.
И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
V>Поэтому действительно "быстрые" веб-сервера пишутся как нейтивная часть некоторого сервера, например модули Apache или нейтивные модули IIS. Так же полно популярных нейтивных либ, вроде этой, обыгрывающих серверную часть HTTP-протокола.
И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
V>Ты просто очень далек от современной ситуации в web, судя по твоим постам...
Зато ты близок... сколько ты вебовых приложений написал то?
G>>Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп. G>>WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.
V>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать...
Плати бабло — сделаю. Мне не сложно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит. G>>Агащаз.
V>Быстрая сортировка. Нарисуй-ка inplace без foreach.
.Sort
V>>>Например, попарный перебор элементов коллекции. G>>.Zip
V>Опять read-only.
И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание.
V>>>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам. G>>Снова бред. Ты просто не в теме. V>Пока что я вижу, что это ты не в теме даже в базовых вещах.
В каких базовых вещах? Ты банально не знаешь как писать на C# и пытаешься писать на нем как на C++, а потом жалуешься. Это и называется "не в теме".
G>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
V>На сегодня Linq сливает даже традиционным функциональным языкам по эффективности времени выполнения... а те, в свою очередь, во все времена были руганы за тормознутость и требования к памяти. Да и полно таких технологий, в сравнении с которыми Linq и по выразительности — ничто... Одна засада, тормозит это так же нехило, как и LINQ, а то и похлеще.
Покажи еще хотя бы парочку. Для моих задач быстродействия linq более чем хватает, один раз не хватало, так я просто linq код переписал в C с той же семантикой, прогнал те же тесты и все заработало. Это было около 0.1% кода приложения.
G>>Ты бы лучше выглянул из своей норы, увидел бы что в .NET есть много способов априори избежать тех ошибок, которые постоянно случаются в unmanaged.
V>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов.
Ага, только эта ошибка логики программы проявляется только в unmanaged
G>>Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются. V>На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно.
Практика показывает что: а) нельзя, потому что сборщика мусора нет б)не будет эффективнее
V>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно.
Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
V>Слабоватый ты оппонент с такой позицией...
Зато ты сильный
V> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили).
Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex.
Так вот во всех них обычный for крайне редко встречается.
V>>>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом. G>>Не, в C# такой код просто не будет написан.
V>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить?
Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
G>>Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.
V>А почему я должен понимать твои неуемные фантазии? Я этой ньювасюковщины наелся еще в 2002-м, а потом в 2005-м. Но сужу по реальным проектам, которых насмотрелся достаточно. А ты тут пытаешься говорить "сахар, сахар", и удивляешься, как у нас до сих пор во рту не сладко.
Я же и говорю, ты пишешь на C#, как на C++. Пока не высунешь голову из норы не увидишь что вокруг происходит.
V>Ну так не везде же нужна голая логика без эффективности, правда?
Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности.
V>Иначе бы никто не искал программистов С++ сегодня.
Ищут их в основном для саппорта.
V>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет?
Не пишется, а саппортится, пишется на порядки меньше.
G>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>В каком месте?
например умные указатели с подсчетом ссылок.
G>>Нет, то что не происходт — не проверяется. Нет смысла писать тесты для наборов входных данных, которые не появляются в работе. Лучше такие места заткнуть ассертами (или code contracts), любое срабатывание которых очевидно говорит о баге, который надо править.
V>Вот ты и попался. Я неделю ждал, когда же ты, наконец, проговоришься и назовешь вещи своими именами, без твоих обычных обтекаемых "тут всё ИНАЧЕ!!!". V>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших.
А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
G>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>Детсад.
Правда жизни. Ты много процесс тестирования организовывал?
G>>Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе. V>Детсад.
См выше.
G>>Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская. V>Потому что не требуется точность
Тем не менее точность есть. Каждый просмотр подсчитывается.
V>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр.
Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
Здравствуйте, vdimas, Вы писали:
V>До 2005-го так и было. Но потом компиляторы С++ как-то стали получше соответствовать стандарту.
Если б дело было только в компиляторах. Это отдельная песня С++ — отсутствие ABI, но это только половина дела. Java обеспечивает стабильный рантайм на почти любой платформе.
V> Прямо на сегодня разработка в исходниках под зоопарк платформ уже не является таким кошмаром, как, скажем, в 99-м году.
Но Java все равно на порядок упрощает создание кроссплатформенного софта.
Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
Сдается мне, тебе просто очень хочется найти в нем проблему, но со знанием предмета не очень. Я не хочу сказать, что проблем нет никаких, но как то уж ты мимо все время тыкаешь, не туда где действительно проблемы имеются.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, DarkGray, Вы писали:
V>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>при отрицательной относительной(долевой) первой производной
V>>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>>при отрицательной относительной(долевой) первой производной
V>Разумеется, коль приведены проценты.
я о том, что уменьшение доли может ни о чем не говорить, если при этом увеличивается абсолютное кол-во.
такое поведение может быть обусловлено тем, что технология применяется в какой-то нише, которая хоть и растет, но медленнее чем другие ниши.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
AVK>Сдается мне, тебе просто очень хочется найти в нем проблему, но со знанием предмета не очень.
Ну сдаётся, так сдаётся.
AVK>Я не хочу сказать, что проблем нет никаких, но как то уж ты мимо все время тыкаешь, не туда где действительно проблемы имеются.
Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
Тебе? Не буду. Упражнения в демагогии, уж извини, в мои ближайшие планы не входит. А интереса к реальному положению дел, судя по этому топику, у тебя нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, samius, Вы писали:
V>>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут. S>А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
Нарисуй плиз, какой из 2-х.
V>>Во-первых, не вижу, откуда это следует. S>Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
А зачем порождать? Такие определения расчитаны на языки с зависимыми типами, а они не пользуют информацию о типах в рантайм, т.е. ничего не порождается. Зависимости м/у типами проверяются в compile-time, атем код считается доказанным.
К тому же, берем дотнет, если a и Tuple будут value-type, то будет сгенерированы заново генерик-методы.. а это хана. Я на этой технике когда-то пытался ускорить математические вычисления, где AST, которое можно непосредственно вычислять, строится как похожий динамический тип через вложенные шаблонные определения value-типов... Считает действительно быстро, но уже для вложенности 16 неимоверно долго создает сам тип. А уникальные, т.е. лишь однажды использованные выражения не подбираются затем GC, это же типы, и это дотнет, а не джава...
Я бы предложил для этого алгоритма эмулировать АлгТД, и не порождать ничего в рантайм.
V>>Во-вторых, там вообще работа по несчастным Cons, т.е. организации очереди на односвязанном списке, чтобы время доступа к обоим концам было O(n). Сорри, но я на коленке накатаю очередь, которая порвет эту многократно, и уж конечно будет тоже O(n). S>
S>Theorem 8.3 snoc and tail run in O(1) amortized time.
Да, конечно же O(1), время фиксированное, это я не то написал. Двусвязные списки как раз и нужны для операций на обоих концах за O(1).
S>Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
Ну так когда говорят "порвать многократно", то речь об коэф. при O(x).
V>>Бо мутабельный двусвязанный список всех описанных в той работе приседаний не требует... И там такой разный K при этом O(n) получается, что мама не горюй. Посмотри что происходит при двусторонней выборке. В общем, пусть у функциональщиков будут свои тараканы... S>По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
Справедливости ради, сразу стало ясно, что структуры на immutable-элементах, а их без GC реализовать нереально. Именно поэтому я чуть отошел от конкретного алгоритма и высказался в том плане, что алгоритмы так или иначе надо брать, подходящие для инструмента. Если задача стоит в обычной двухсторонней очереди, то она давно решена для императивных языков.
Насчет навигации в центр за время логарифм — приоритетные очереди в C++ как раз делают через std::map. Берется составной ключ, где одна составляющая приоритет, другая — монотонный номер (напр. тики процессора). В движке для конференций на C# тоже похоже делали, но на упорядоченном массиве (бо средняя длина очереди сообщений была около десятка). Т.е. задача-то известная, как и способы решения.
V>>ИМХО, в основу должны идти не алгоритмы, а требования. А уж алгоритмы берутся те, которые подходящие для инструмента, на котором мы решились эти требования удовлетворить. S>В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
Является, к сожалению. Пока что очень неудобно разрабатывать проекты так, чтобы был сразу десяток инструментов доступен из-за плясок с сопряжением технологий. Берется один, максимум два инструмента, и приходится затем плясать в выбранных рамках в любой микро-задаче. Удачность выбора — второй вопрос, бо идеальных технологий и серебрянной пули не бывает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но Java все равно на порядок упрощает создание кроссплатформенного софта.
Возможно, но неожиданно решение пришло совсем с другой стороны. Например, мощное железо под юнихами ставят сейчас всё больше для целей виртуализации. Потому что потребность, чтобы работали уже имеющиеся приложения, всяко повыше, потребности обеспечить работоспособность неких будущих.
AVK>Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc (т.е. их соответствующих CRT) примерно вдвое.
Выглядит так, будто дотнет + обновленная джава (предыдущую всерьез не воспринимали) показали кое-какие востребованные фичи от самого понятия "платформы", в итоге компиляторы C++ резко рванули вперед последние лет 5-6.
Смотрю на молодых плюсистов, сходу начинающих пользоваться самыми современными идиомами без проблем (полностью обеспечиваемыми современными компиляторами) и тихо завидую, вспоминая свои убогие в этом плане 90-е... где единственный соответствующий стандартам компилятор генерил самый медленный в истории С++ код. А компилятор MS от 5-ки был притчей во языцах.
Здравствуйте, DarkGray, Вы писали:
V>>>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>>>при отрицательной относительной(долевой) первой производной
V>>Разумеется, коль приведены проценты.
DG>я о том, что уменьшение доли может ни о чем не говорить, если при этом увеличивается абсолютное кол-во. DG>такое поведение может быть обусловлено тем, что технология применяется в какой-то нише, которая хоть и растет, но медленнее чем другие ниши.
Ну... я бы не назвал ASP.Net нишевым. Самый что ни на есть ширпотреб в оригинальном смысле этого слова. Как и конкурирующие JSP или PHP. Дело в низлежащей платформе, конечно. Виртуализация линухов стоит дешевле виртуализазии виндов в плане железа, т.е. тоже самое железо потянет больше виртуальных узлов, если на этих узлах будут крутиться линуха. Ну и плюс гораздо более простое разделения, где можно писать, а где нет, в дереве директорий, позволяет накручивать десятки виртуалок практически на один и тот же экземпляр образа, с отличающейся подмонтированной частью для данных клиента. А это очень вкусно выглядит для хостеров. ИМХО доля линухов для хостинга будет только расти.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>>>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере. G>>По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
V>Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код.
Что значит "первичная бизнес логика", чем она от вторичной отличается? Ты наверное не соображаешь что если дать возможность клиенту проводить вычисления, а потом посылать резльтаты на сервер, то это может быть не согласовано с логикой на сервере. Поэтому сейчас ни одно приложение не имеет логики на клиенте, на клиенте располагается код для обработки UI и не более того.
V>>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
V>Какой именно сервер?
Лобой. Это чтобы ты понял что объе данных не коррелирует с полезностью и заратами.
G>>Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
V>С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами.
Эффективная отдача заключается в том чтобы не забирвать канал, о отдавать ровно столько сколько клиент сможет принять учитывая характеристики канала и возможности клиента.
И одна из самых эффективных реализаций такого сейчас сделана угадай где? Правильно в самом ненативном silvelight. От тупо считывает разные файлы с сервера в разным bitrate в зависимости от загруженности канала.
V>>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G>> G>>Посмотри сколько данный форум возвращает, и не говори бредятину.
V>И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз.
А какая разница? Из них же все равно надо склеить html, или ты думаешь что это бесплатно делается?
V>>>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. G>>Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
V>Мде? Покажи мне, в каком месте он не согласен? Нашел ты, однако, "ресурс", который суть текстовый формум. Ты еще социальную сетку какую-нить приведи в пример. Я тебе быстро покажу, как ее реальное быстродействие замерить.
Ну замерь "реальное быстродействие" stackoverlow, посмотри какие там юзкейсы есть и статистика прям на главной. Ты смешон
V>>>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++) G>>Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
V>Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить?
Я ссылку открыл, там на странице ни одного слова про C++ или native, веб-сервер Apache. Скорее всего там PHP. Для отображения используется flash.
G>>И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
V>Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал?
Не понял о чем ты. Я спрашиваю почему на C++ мы не видим сотен сайтов если все так плохо у ASP.NET? Кстати большинство сайтов на ASP.NET прекрасно работают с достаточным быстродействием.
G>>И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
V>Как тебя почитать, так ты окромя дотнета вообще ничего не видел... А я здесь при чем? V>
V>По данным Netcraft Web Server Survey за июнь 2011 года, доля веб-сервера Microsoft IIS на всех доменах в Сети продолжила падать и с майских 18,37% опустилась до уровня 16,82%. Это самый низкий показатель с конца 1997 года.
Да без разницы, возьми apache\php, с++ в вебе в микроскоп не видно. Хотя я уверен что у php парсер TDS работает не быстрее .NETного
V>>>Ты просто очень далек от современной ситуации в web, судя по твоим постам... G>> G>>Зато ты близок... сколько ты вебовых приложений написал то?
V>О! Можно вынимать и демонстрировать? V>Если за всю карьеру, то около десятка, из них 3 на ASP.Net. Есть с чем сравнить. А если брать не чистый веб, а всякие сервисы, просто многозвенки и распределенные архитекруты по различным протоколам (пару десятков протоколов навскидку), то, скажем так, на конкретно ASP.Net я могу посмотреть со всех сторон. Не только как "чисто-вебной" части, когда принимается решение на чем делать HTTP-часть, но и чуть раньше, как инструмент реализации GUI, когда принимается решение, делать ли веб-морду, или таки классический GUI-клиент. Например, однажды был взят ASP.Net для генерации Silverlight-приложений, которые отображаются во вкладках IE (!!!) локальным сервисом (вовсе не 80-й порт) в плагине к этому IE. Такое решение оказалось намного интересней в плане отзывчивости, чем GUI этого плагина на WPF + локальный WCF сервис. Еще пару раз брал ASP.Net как либу для нетривиального рантайм-редеринга текста (т.е. не как out-of-proc сервер, а именно как либу). Это помимо классического веба. Т.е. эту примочку к IIS раком ставить умеем вдоль и поперек, не переживай... и даже хакать и корректно юзать MS Embedded SQL с ASP.Net, чтобы сравняться по эффективности с MySQL на зачитке (смогешь так?).
Круто.. Я три на asp.net сделал за первый год. Причем особо извращений не было, даже лечил некоторые извращения таких умельцев "раком ставить".
MS SQL рвет как тузик грелку на любых нетривиальных запросах, так что тут и соревноваться не зачем.
V>Сравнить с аргуентами: "для моих задач хватает", "все пишут на ASP.Net"... и это при ~17% реальной живой доле и отрицательной первой производной.
Ты еще посмотри доля каких серверов растет. Ты удивишься, это nginx. Тупо потому что самый дешевый вариант для организации прокси. Для генерации контента он и не используется. Обычно им экранируют апач (который знатный трмоз если что).
V>>>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать... G>>Плати бабло — сделаю. Мне не сложно.
V>Так и думал... V>но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность.
Так у тебя вроде еще прототип или как понимать фразу выше?
Здравствуйте, vdimas, Вы писали:
V>Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc
Вот когда бекенд стандартизуют на 100% у всех компиляторов, а потом большую часть API всех часто используемых ОС тоже, тогда и можно будет сравнивать кроссплатформенность С++ и джавы.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
G>>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>>Так вот во всех них обычный for крайне редко встречается.
V>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
Orchard: 57 for против 706 foreach, и это еще не считая linq.
Так что реально не более 1-2% от всего кода работы с коллекциями.
Здравствуйте, gandjustas, Вы писали:
V>>Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
G>Orchard: 57 for против 706 foreach, и это еще не считая linq.
G>Так что реально не более 1-2% от всего кода работы с коллекциями.
Ну отлично. Отображение крайне редко изменяющегося контента. Супер-пример.
Мне порой свои версии практически всех стандартных контейнеров писать приходится (или таскать из проекта в проект). И вообще делать много глупых приседаний... Например, чтобы ускорить парсинг HTML в пауке "всего лишь" в 25-30 раз, или изворачиваться в персистентном слое вручную полностью, чтобы получить в 45-55 раз (!!!) ускорение раздражающей до этого сериализации развесистых графов объектов... мелочи конечно, а клиентам очень приятно. Просто все эти "мелочи" имеют один побочный эффект: они открывают саму возможность для исполнения еще целого класса задач за счет сэкономленных процессорных тиков.
Поэтому вопрос "достаточности" не однозначен. В первых версиях надо чтобы "просто работало". Потом клиенту надо все больше и больше, а потом вообще львиную долю переписываешь на нейтиве (бывало и такое), бо всё что можно, дотнет честно отдал и самоудалился.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут. S>>А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
V>Нарисуй плиз, какой из 2-х.
Не понял, кто именноо "какой". Обход? Способ обхода не влияет на то, можно ли обойтись без виртуальности. Например, рассмотрим телегу. Если мы знаем, что у телеги должны быть колеса, то организовать обход колес можно как изнутри телеги, так и извне. Никакой виртуальности при этом не надо, если известно как взять колеса и только лишь их на стадии компиляции. Другое дело — кузов телеги (как контейнер, куда можно положить неизвестно что, в том числе и колеса). Но и кузов мы можем обойти как изнутри телеги так и снаружи. Вот когда на этапе компиляции неизвестно, что конкретно в кузове, тогда без полиморфизма не обойтись при выборе метода, независимо от положения способа обхода.
Ты пишешь вроде бы о том же (я выделил выше), но зачем-то в контексте способа обхода.
Моя структура — типичное дерево аки на АлгТД (разве что типов листьев поболее чем один). Обход через внешний итератор.
S>>Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
V>А зачем порождать? Такие определения расчитаны на языки с зависимыми типами, а они не пользуют информацию о типах в рантайм, т.е. ничего не порождается. Зависимости м/у типами проверяются в compile-time, атем код считается доказанным.
Хорошо, пусть мы считаем что все необходимые типы порождены во время компиляции. Но в C++ мы и такого сказать не можем.
V>К тому же, берем дотнет, если a и Tuple будут value-type, то будет сгенерированы заново генерик-методы.. а это хана.
Я привел пример того что не позволяет система типов C++, но ты опять скатился к производительности. V>Я бы предложил для этого алгоритма эмулировать АлгТД, и не порождать ничего в рантайм.
Т.е. вместо Queue<T> и Queue<Tuple<T,T>> использовать что-то вроде Queue<std::vector<T>> или что-то вроде?
V>Да, конечно же O(1), время фиксированное, это я не то написал. Двусвязные списки как раз и нужны для операций на обоих концах за O(1).
Вот если бы они еще были иммутабельными
S>>Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
V>Ну так когда говорят "порвать многократно", то речь об коэф. при O(x).
Ты пропустил то что очередь неизменяемая?
S>>По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
V>Справедливости ради, сразу стало ясно, что структуры на immutable-элементах, а их без GC реализовать нереально.
Слишком сильное утверждение. Вполне себе работаю с иммутабл списком без GC. V>Именно поэтому я чуть отошел от конкретного алгоритма и высказался в том плане, что алгоритмы так или иначе надо брать, подходящие для инструмента. Если задача стоит в обычной двухсторонней очереди, то она давно решена для императивных языков.
А если задача в неизменяемой очереди? Впрочем, ее тоже можно решить без рекурсивного полиморфизма (см предыдущие главы той же книги). Только там вычислительная сложность будет уже не O(1), хотя те решения работают быстрее чем обсуждаемое по словам автора.
V>Насчет навигации в центр за время логарифм — приоритетные очереди в C++ как раз делают через std::map. Берется составной ключ, где одна составляющая приоритет, другая — монотонный номер (напр. тики процессора). В движке для конференций на C# тоже похоже делали, но на упорядоченном массиве (бо средняя длина очереди сообщений была около десятка). Т.е. задача-то известная, как и способы решения.
Жаль, что не подойдет там где нужна неизменяемая очередь.
S>>В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
V>Является, к сожалению. Пока что очень неудобно разрабатывать проекты так, чтобы был сразу десяток инструментов доступен из-за плясок с сопряжением технологий. Берется один, максимум два инструмента, и приходится затем плясать в выбранных рамках в любой микро-задаче. Удачность выбора — второй вопрос, бо идеальных технологий и серебрянной пули не бывает.
Взять мой текущий проект — выбора инструмента практически не было. Несколько платформ, другие факторы (и человеческие), в итоге — C++. Но выбирать алгоритмы и структуры данных я могу. И вполне успешно использую местами совсем не характерные для инструмента неизменяемые структуры данных и алгоритмы.
Здравствуйте, vdimas, Вы писали:
V>В реальной жизни переносимость на уровне исходников достаточна.
Когда как. Если слой взаимодействия с платформой тоненький — можно и пережить. Но так бывает далеко не всегда.
V>У джавы когда-то наблюдал под разные платформы шли разные инсталляхи аппликух.
Потому что бутстраппер, создание ярлыков, регистрация анинсталлеров и тому подобные действия для каждой платформы разные.
V> Да еще каждая с собой тащит свою версию фреймворка
Это скорее плюс, чем минус.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, MxMsk, Вы писали:
CS>>Пора переходить к конкретике. MM>Справедливости ради, конкретики нет с обеих сторон. Нужно обсуждать конкретные решения по части .Net и WPF, которые принимала команда Evernote.
У эвернота проблемы точно не с впф. У них уи как был поделкой, так и остался поделкой. Просто кажется, что на впфом занимались сиплюсники которые не в курсе дотнета. Да и в с++ они так себе. После того как евернот начал валиться с Access Violation, я тупо забил на него.
We know developers are hungry for information about native development. The GoingNative conference aims to provide current technical information to as many people as possible.
Register now!
GoingNative 2012 is a 48 hour technical event for those who push the boundaries of general purpose computing by exploiting the true capabilities of the underlying machine: C++ developers. Distinguished speakers include the creator of C++, Bjarne Stroustrup, C++ Standards Committee Chair, Herb Sutter, C++ template and big compute master, Andrei Alexandrescu, STL master Stephan T. Lavavej, and more! Official agenda will be released over the next month or so. Join us!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я вот, не знаю, будет ренессанс, не будет ренессанса, или [не]будет, но только в рамках MS. Но вот MS говорит о чём-то загадочном:
А что тут загадочного? VCшники решили устроить у себя междусобойчик. Ты участвуешь?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Я вот, не знаю, будет ренессанс, не будет ренессанса, или [не]будет, но только в рамках MS. Но вот MS говорит о чём-то загадочном:
AVK>А что тут загадочного?
Название странное. Я бы сказал — необычное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>в каких задачах необходимо оперировать в каждый момент времени с таким кол-вом item-ов?
Ну.. это были выкладки для миллиарда штук, что есть перебор. Бери на несколько порядков меньше, но и требования идут не секундные, а мили и микросекундные. И еще нужна предсказуемость... А GC непредсказуем.
DG>я не спрашивал "какие инструменты не подходят для этих задач?", я спрашивал "какие это задачи?"
А с чего ты взял что должны быть какие-то особенные задачи?
Банки, сотовые операторы, крупные ретейлеры, система здравоохраниния и любые организации с массовым обслуживанием населения легко накапливают такие объемы. Задачи — обычные, просто пользователей много, данных много, обращений много
DG>>я не спрашивал "какие инструменты не подходят для этих задач?", я спрашивал "какие это задачи?" R>А с чего ты взял что должны быть какие-то особенные задачи?
потому что миллиард — это очень много. и столько информации одномоментно никогда не используется
R>Банки, сотовые операторы, крупные ретейлеры, система здравоохраниния и любые организации с массовым обслуживанием населения легко накапливают такие объемы.
все эти штуки имеют максимум тысячу одновременных пользователей.
и это означает что необходимо держать в памяти миллион item-ов на каждого пользователя, чтобы бы был миллиард.
но в этих системах нет столько одномоментной информации на каждого пользователя.
R> легко накапливают такие объемы.
тогда это архив, и его не надо держать в памяти
R> Задачи — обычные, просто пользователей много, данных много, обращений много
много это сколько? тысяча обращений в секунду? данных много — это сколько? отдача 50кб html-я на каждый запрос?
DG>потому что миллиард — это очень много. и столько информации одномоментно никогда не используется
если взять по 100байт на айтем то млрд это всего лишь 100гб — обычный рядовой сервер
миллиард это даже не много и уж тем более не очень много — это средне , много данных — это имхо когда активная часть в принципе в оперативку влезть не может
DG>все эти штуки имеют максимум тысячу одновременных пользователей.
оч сильно зависит от задач, прямо сейчас у коллег несколько сот одновременных пользователей, и это относительно мелкий банк, у сбера например на 2 порядка больше сотрудников DG>и это означает что необходимо держать в памяти миллион item-ов на каждого пользователя, чтобы бы был миллиард.
опять же зависит от задач. 5 аналитиков легко нагружают сервер до красного свечения
DG>тогда это архив, и его не надо держать в памяти
да, неактивная часть конечно хранится в архиве
да, если задача поддается распхиванию в кубы
а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
R>> Задачи — обычные, просто пользователей много, данных много, обращений много DG>много это сколько? тысяча обращений в секунду? данных много — это сколько? отдача 50кб html-я на каждый запрос?
я работал с разной нагрузкой, была олтп с требованием <50мс отклик и ~10млн данных, была DSS ~1млрд и 10сек отклик. Много в моем понимании — когда на каждый айтем остается ~1000тиков процессора
R>а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
значит необходимо разделить задачу на две: memory db и все остальное.
в первом gc не будет, а во втором будет.
и linkedin, facebook так обычно и делают. под первое пишется какая-то своя memory-базка, а под второе используется скрипт с gc.
для .net и java-ы принцип остается тот же: долговременный массив отделяется от всей остальной программы, может даже выносится в unmanaged-память, а остальные 80% кода живут вместе с gc
R> да, если задача поддается распхиванию в кубы
какая задача не запихивается в куб? или его аналог?
R> я работал с разной нагрузкой, была олтп с требованием <50мс отклик и ~10млн данных
и при этом каждый пользователь на экран получал 10млн данных на каждый запрос?
или все таки каждый пользователь получал свои 1000 данных на каждый запрос?
и на каких это задачах чтобы вернуть 1000 данных требуется каждый раз проанализировать 10млн. данных?
Здравствуйте, DarkGray, Вы писали:
R>>а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
DG>значит необходимо разделить задачу на две: memory db и все остальное. DG>в первом gc не будет, а во втором будет. DG>и linkedin, facebook так обычно и делают. под первое пишется какая-то своя memory-базка, а под второе используется скрипт с gc. DG>для .net и java-ы принцип остается тот же: долговременный массив отделяется от всей остальной программы, может даже выносится в unmanaged-память, а остальные 80% кода живут вместе с gc
гц нам не мешает, разговор был про случаи когда джит мсовский не дает примлемого перфоманса. непонятно зачем ты все это сюда приплел.
R>> да, если задача поддается распхиванию в кубы DG>какая задача не запихивается в куб? или его аналог?
есть 10 фактов и 100 измерений, аналитик может выбрать группировку(пусть не более 5) и ограничения(не более 10) по любой комбинации. Считать что каждое измерение в среднем содержит 50тыс значений
DG>и при этом каждый пользователь на экран получал 10млн данных на каждый запрос?
пользователь получал _результаты обработки_ 10млн айтемов, для его специфических нужд
DG>и на каких это задачах чтобы вернуть 1000 данных требуется каждый раз проанализировать 10млн. данных?
в моем случае — что-то вроде FTS по пачке связанных FK гридов
Я тоже не понимаю зачем их тестировать ВСЕГДА? Ну вот есть модуль А, который в процессе работы сожрал левые данные от модуля Б и скончался. Вы считаете, что виноват модуль А. При моем подходе вся вина на модуле Б, который не выдержал контракт модуля А. Не выдержал вследствие ошибки в модуле Б или же вследствие того, что модуль Б аналогично получил неверные данные от модуля С (и далее — транзитивно). В итоге источником ошибок окажется некий модуль Х, который либо неверно обслуживает свой контракт, и ошибки в данном модуле должны выявляться тестами на "правильные" сценарии, либо же он становится жертвой внешнего мира, и в этом случае помогут тесты на негативный сценарий. Но заметьте, эти тесты нужны требуются только для модуля Х, работающего с дикой природой. В итоге на практике приходим к тому, о чем говорил ганьюстас, — тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
это мягко говоря неточно.
в реальном мире существуют также еще враждебные агенты (вирусы, хакеры, спам и т.д.), и если локальное ПО еще может как-то эти угрозы игнорировать, то распределенное ПО (в том числе сайты) эти угрозы игнорировать не могут.
с учетом этих угроз уточненая формулировка вышеуказанной рекомендации будет следующая:
нет необходимости тестировать неправильные сценарии для выяснения какие именно ошибки там сыпятся; и такое подробное тестирование неправильных сценариев вредно с точки зрения экономии ресурсов, но в тоже время необходимо тестировать (а еще лучше гарантировать) неправильные сценарии на два аспекта: в неправильных сценариях не должен происходить подрыв безопасности, и в неправильных сценариях не должны происходить потери и искажения данных.
С точки зрения разработки еще желательно тестировать, что при неправильных сценариях ошибка проявляется там, где возникла; и не происходит искажение симптоматики.
Все эти аспекты экономичнее гарантировать с помощью архитектуры или используемых инструментов, чем тестировать.
например, использование managed-среды резко уменьшает вероятности наступления в неправильных сценариях всех трех аспектов: подрыв безопасности, потеря или искажение данных, появление разрыва между местом возникновения проблемы и местом ее проявления.
LP>>тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
DG>это мягко говоря неточно. DG>в реальном мире существуют также еще враждебные агенты (вирусы, хакеры, спам и т.д.), и если локальное ПО еще может как-то эти угрозы игнорировать, то распределенное ПО (в том числе сайты) эти угрозы игнорировать не могут.
Я ведь не говорю, что нужно их игнорировать, в моем сообщении написано, что на предмет нарушения контракта нужно проверять только функциональность, которая торчит наружу. Если вернуться к моему сообщению, то нужно тестировать модуль Х на предмет данных угроз. Модуль Х мало того, что должен корректно и безопасно интерпретировать свои входные данные (из дикой природы), он должен работать корректным и безопасным образом с остальными подсистемами, а оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль. Если для каждого микромодуля проверять возможные случаи нарушения его контрактов, есть риск захлебнуться в унитазе, не доведя работу и до половины.
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль.
неверно. такая система имеет малый запас прочности, и быстро дохнет при малейшей реальной угрозе (например, как только найдена хоть какая-то уязвимость в клиентском коде, или каким-то образом удалось закинуть троян внутрь системы).
в идеальной, с точки зрения надежности, системе — каждый модуль обязан обеспечивать устойчивость к ошибкам и нападению, в реальной системе — это будет баланс между производительностью и устойчивостью.
LP>>оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль.
DG>неверно. такая система имеет малый запас прочности, и быстро дохнет при малейшей реальной угрозе (например, как только найдена хоть какая-то уязвимость в клиентском коде, или каким-то образом удалось закинуть троян внутрь системы). DG>в идеальной, с точки зрения надежности, системе — каждый модуль обязан обеспечивать устойчивость к ошибкам и нападению, в реальной системе — это будет баланс между производительностью и устойчивостью.
Клиентский код == потребитель контракта некоего модуля, не обязательно клиент.
Насчет остального — один из отцов ООП Бертран Мейер с тобой не согласен. И тоже ))
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>>Клиентский код == потребитель контракта некоего модуля, не обязательно клиент. DG>вышенаписанное исходило из этого же утверждения. LP>>Насчет остального — один из отцов ООП Бертран Мейер с тобой не согласен. И тоже )) DG>проблема в том, что в быстро меняющемся мире — авторитеты бывают правы очень короткое время (конечно, если не пересматривают свою позицию)
Насколько мне известно, все современные попытки создать безопасную среду выполнения крутятся все вокруг той же идеи — автоматическая гарантия выполнения клиентом контракта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали: ГВ>>>Ты их по скорости сравнивал? G>>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет. V>Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?
Че уж там давай сразу мильярд.
Социализм — это власть трудящихся и централизованная плановая экономика.
Если нам не помогут, то мы тоже никого не пощадим.
Возьми с полки пирожок. Ты, кстати, не у конкурентов, часом работаешь? Надо посоветовать, чтобы тебе зарплату подняли. Скажи, эдипов папа посоветовал.
Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
Где, где ты увидел что высокое качество легкодостижимо?
