• Оптимизация производительности .NET (C#) приложений
    +1
    1. Красивого способа нет и не будет. Я считаю, что это методологически неправильно смотреть только на значения Mean/Median без Error/StdDev. По такой табличке очень опасно делать выводы, т.к. невозможно прикинуть есть ли статистически значимая разница между бенчмарками. Можно легко обмануть себя и другие людей, которые будут смотреть на результаты подобных экспериментов.
      Но если очень-очень хочется, то сделать это всё-таки можно. Нужно скопипастить дефолтный конфиг и поменять реализацию GetColumnProviders (вот тут можно посмотреть что подставляется по дефолту).
    2. Такой фичи нет, но она выглядит интересной, можно сделать. Буду рад тикету или пул-реквесту.
  • Оптимизация производительности .NET (C#) приложений
    +3
    Библиотека простая в использовании, но если вдруг её авторы читают сей пост, прошу, дайте более удобную возможность влиять на структуру таблицы результатов.

    А чего не хватает?

  • Производительность .NET: приемы настоящего джедая
    +3

    Работаем в этом направлении, но сомневаюсь, что мы сможем что-то показать раньше середины 2018-го (там очень много сложных технических задач).

  • Как перестать ходить на конференции участником и начать выступать? Советы от Андрея Акиньшина
    +1

    Раздел «Содержание доклада на 20-30 пунктов» появился не от хорошей жизни. Раньше в 95% случаев спикеры присылали очень короткое описание (иногда буквально в одно предложение), из которого не особо понятно о чём пойдёт речь в докладе. И практически всегда общение со спикером начиналось со слов «А можете поподробнее расписать о чём доклад?». Поэтому мы добавили такую формулировку в форму. Если пунктов будет меньше 20, то заявку всё равно можно отправить, это лишь рекомендуемый объём (который в большинстве случаев экономит всем время). Спасибо за фидбек, будем эту страничку улучшать. Но на текущий момент это единственный (и самый правильный) путь к тому, чтобы началось обсуждение заявки. Через нас проходит очень большое количество людей и крайне сложно удержать всех в голове, если заявки раскиданы по разным местам типа почты и скайпа. Наш workflow выработан (и активно дорабатывается) как раз, чтобы свести всю работу в одно место.


    Так что я ожидал, что отпишется кто-то кто в теме. То, что его вопрос адресован был мне, лично для меня совсем не очевидно.

    В таком случае прошу прощения за недопонимание. Нам адресация вопроса показалось очевидной, поэтому мы просто решили подождать ответа.

  • Как перестать ходить на конференции участником и начать выступать? Советы от Андрея Акиньшина
    +2

    Саша Гольдштейн отписался и задал уточняющий вопрос по докладу, но ответа мы так и не получили.
    Для потенциальных спикеров у нас есть форма call for papers: https://dotnext-piter.ru/callforpapers/ (Ссылка имеется в шапке сайта). После отправки заявки для каждого спикера заводится канал в слеке (где с ним могут пообщаться все члены программного комитета) + тикеты в джире. Программный комитет мониторит тикеты + раз в неделю мы целенаправленно проходимся по всем задачам, что позволяет ни про кого не забыть. Подобный workflow хорошо работает и позволяет избегать непонятных проблем.
    В вашей ситуации получилось так, что вы послали письмо сразу на почту (основная часть ПК заявку даже не видела), Саша задал вопрос по заявке, я увидел открытый вопрос и решил подождать ответа, ответа не последовало, про заявку забыли. Мы всюду рекламируем нашу CFP-форму и агитируем засылать идеи докладов именно через неё: это позволяет держать работу с докладчиками под контролем.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +1

    Ещё не решили. Сначала нужно дописать продукт, а потом будем думать про лицензирование. =)

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    0

    Зависит. Прежде всего зависит от потребностей конторы и готовности самим фиксить баги в моно. Rider бежит поверх Mono, бежит нормально. Проблемы есть, на них приходится тратить определённое время, но при желании на этом рантайме можно разрабатывать вполне серьёзные приложения.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    0

    Спасибо за дополнение! Рад, что у вас нет проблем со скоростью и интерфейсом, Xamarin действительно очень прокачался за последнее время. Но хотелось бы сказать, что потребности у народа разные: я постоянно общаюсь с Xamarin-разработчиками, отзывы о платформе у всех различные. Очень здорово, что на рынке имеется подобный инструмент, но судя по всему направления для развития всё ещё есть. =)

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +2

    Да, видел. Кстати говоря, Matt Warren (автор статьи) — один из разработчиков BenchmarkDotNet.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +5

    Никакой лжи тут нет. Я каждый день смотрю на снэпшоты R# и Rider и прекрасно понимаю, почему имеются определённые проблемы со скоростью в VS. Тот же самый код отрабатывает мгновенно в Райдере, что наводит на определённые размышления. Вы можете самостоятельно снять профиль работы студии и Райдера и разобраться что там и как. Никого обмануть я не пытался, а просто озвучивал собственное честное мнение. Могу подписаться под каждым словом.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +2

    Спасибо, с каждым новым днём стараемся делать Rider всё лучше и лучше. =)


    От себя — очень очень хочу F#

    Думаем над этим, но это не очень просто.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +1

    Вся логика на фронтэнде (там где мы интегрируемся с IDEA) написана на Kotlin на 100%. Бэкэнд (R#) пишется по понятным причинам на C#.

  • «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)
    +8

    А мы целенаправленно следим за этим и постоянно проверяем самые разные проекты. Если солюшн маленький, то жить ещё можно. А вот когда у вас сотни проектов и миллионы строк кода, а вы что-нибудь активно рефакторите, то ситуация с памятью становится грустной (в том числе в VS 2017 RC).

  • Замеряем производительность с помощью BenchmarkDotNet
    0

    Пока что простого путя для дебага нет: если возникли проблемы, то нужно открыть сгенерированный проект и дебажить его. Ну или вызвать проблемный метод в основной программе руками. Хотим в дальнейшем упростить дебаг, но в общем случае вспомогательные проекты всё равно будут генерироваться, собираться и запускаться: без этого не сделать сравнение разных окружений (и много других проблем появится).

  • Видеозаписи лучших докладов .NET-конференции DotNext 2016 Piter
    +2

    Ок, спасибо за конструктивный фидбек. Будем стараться работать над форматом.

  • Видеозаписи лучших докладов .NET-конференции DotNext 2016 Piter
    +3

    Ну так это даже не моя шутка была.
    А в целом, доклад был изначально задуман как послеобеденный и полуразвлекательный, чтобы народ немного отдохнул в середине конференции. Увы, никогда не получается сделать так, чтобы все шутки всем понравились. Специально для этого у нас делается одновременно несколько треков, а сетку мы пытаемся сделать таким образом, чтобы каждый нашёл наиболее подходящий для себя доклад (не только по тематике, но и по формату).

  • Видеозаписи лучших докладов .NET-конференции DotNext 2016 Piter
    +3

    А что не так?

  • Шаблон диссертации в LaTeX
    0

    Вот пара ссылок на tex.stackexchange, в которых обсуждается ваша проблема:



    Так же рекомендую просмотреть инструкцию по работе с библиографией для шаблона, там много полезной информации:



    Если не сможете справиться с проблемой, то лучше всего написать о ней в наш чат:


  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    0

    Тогда приходите на нашу замечательную конференцию, в своём докладе я буду рассказывать о том, как же решать эту и многие другие проблемы без всякой C++ магии. =)

  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +1

    Увы, законы реальной жизни оказываются сильнее, такой код систематически появляется в совершенно разных проектах.
    Но даже если бы не появлялся, то


    A?.Foo();

    всё равно выглядит лаконичнее, чем какое-нибудь


    if (A != null)
    {
        A.Foo();
    }
  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +1

    Нет, предположения о порядке мы не делаем. Нам просто приходит набор double-чисел, нужно вернуть сумму.
    Сортировка — мысль интересная, но не очень хорошая в плане производительности, сумма будет работать долго.
    Можно ли что-нибудь придумать для произвольных входных данных, чтобы работало за O(N) ?

  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +2

    @PsyHaSTe, направление мысли правильное. А можно что-нибудь сделать без модификации входных данных? Другими словами, нужно написать собственную функцию Sum, которая для любого набора чисел выдаст «хорошую» сумму.

  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +1

    Да не пытаюсь я Груви обидеть, не волнуйся так. =) Чудный язык, в нём очень давно появилось много разного и хорошего, с этим никто не спорит. Я просто хотел сказать, что это абсолютно нормально, когда хорошие фичи переходят из одних языков в другие.

  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +1

    Если фича хорошая, то она часто появляется сразу в нескольких хороших языках программирования. А null propagation operator — хорошая фича, поэтому мы можем её наблюдать не только в C#6 и Kotlin, но ещё и в Groovy. =)

  • DotNext 2016 Moscow: 8 MVP, StackOverflow и немного хардкора
    +2

    Это очень клёвая фича. Представьте, что у вас есть некое свойство A, у которого есть свойство B, у которого есть свойство C, у которого есть свойство D, у которого вы хотите вызвать метод Foo. Но вот проблема: по пути к методу Foo одно из свойств A, B, C, D может оказаться равным null. Раньше приходилось писать:


    if (A != null && A.B != null && A.B.C != null && A.B.C.D != null)
        A.B.C.D.Foo();

    В C#6 вы можете написать просто


    A?.B?.C?.D?.Foo();

    Материал для дополнительного чтения:


  • .NET-разработка: девять вопросов взрослым
    +3
  • .NET-разработка: девять вопросов взрослым
    +5
    Я гонял Райдер на Райдере. Работает шустренько, не жалуемся.
  • Замеряем производительность с помощью BenchmarkDotNet
    0
    Ок, я подумаю, что с этим можно сделать.
  • Замеряем производительность с помощью BenchmarkDotNet
    0
    По поводу Issues. #97 уже сделан в develop ветке, #96 скоро сделаю. Постараюсь выложить новую версию в NuGet на этих выходных. Помимо прочего, у нас там идёт работа над поддержкой DNX и CoreCLR, что занимает много времени.
    По поводу вашего случая: если у вас получится придумать удобный API который бы покрывал ваш случай и не мешал бы работать обычным бенчмарком, то я с удовольствием включу его в библиотеку. Но лично я пока плохо представляю, как такой функционал следовало бы реализовать. Было бы чудно, если бы вы накидали в виде кода то, как вы всё это видите (+ желаемый вид summary-таблички).
  • Замеряем производительность с помощью BenchmarkDotNet
    +1
    Ну, выдирать имя функции из тела — это достаточно частная задача, не думаю, что имеет смысл включать её в ядро библиотеки. В вашем случае я бы предложил использовать TagColumn для формирования дополнительных колонок из названий методов, см. IntroTags. Свой Baseline будет писаться очень просто: если нам дали Custom-класс, то возвращаем в новой чудо-колонке 1, а если Linq, то находим бенчмарк с такой же функцией в Custom-случае и считаем отношение.

    Если по мере подготовки статьи будут возникать какие-то дополнительные вопросы/замечания/предложения, то не стесняйтесь обращаться. В BenchmarkDotNet мне хочется сделать такой API, который можно действительно легко адаптировать под любые кастомные задачи.
  • Замеряем производительность с помощью BenchmarkDotNet
    +1
    А есть возможность сделать так, чтобы все методы были в интерфейсе, который реализуется в каждом из классов? Если да, то проще всего было бы завести параметр, который бы определял имплементацию. Ну, и в каждом бенчмарк-методе использовать этот параметр, чтобы использовался бы инстанс нужного класса. И можно было бы легко написать свой BaselineColumn, который сравнивает первую имплементацию со второй. Если это не нанобенчмарки (на метод уходит хотя бы 50ns), то накладными расходами на выбор имплементации вполне можно пренебречь.

    Очень удобно, когда функция показана в отдельном стобце, а не кодируется в названии метода LinqMax, CustomMax и т.п.

    А можете привести пример того, как вы это себе представляете?
  • Замеряем производительность с помощью BenchmarkDotNet
    +1
    1. На текущий момент экспорт в csv делается всегда, а через ManualConfig можно его выключить.
    2. Сейчас Baseline выбирается на группу параметров. Т.е. если у меня есть [Params(1,2,3)] int X, то на каждое значение X будет собственный Baseline. Если вы хотите сравнивать A1 с A2, а B1 с B2 попарно, то нужно делать два отдельных класса. Группировку методов сделать не так сложно, но сложно сделать так, чтобы для общего случая результаты отображались бы так, чтобы всем было понятно, к чему какой Baseline-относится (если у вас есть хорошие идеи, то я их с радостью послушаю).
      Но если очень хочется, то всегда можно прописать собственный IColumn по аналогии с BaselineDiffColumn и добавить в конфиг (кода нужно совсем немного, зато вы сможете заточить колонку под собственные нужды).
  • Сравнение производительности С++ и C#
    +1
    Я устал с вами спорить, это мой последний комментарий.

    Рассказываю последний раз: вы написали некоторую программу на C++, затем написали похожую программу на C#, попробовали запустить обе программы в весьма ограниченном списке окружений, получили какие-то числа, после чего делаете вывод про языки в целом.

    Общий вывод о том, что .NET-программа в среднем работает дольше нативной за счёт расходов на управляемую среду, был понятен и до вашего исследования. Никто не говорит, что результат не является верным, все говорят, что ваш эксперимент содержит много ошибок и не может рассматриваться как доказательство этого результата в общем случае.

    Детально все свои замечания я уже высказал выше. Почитайте также хорошие советы от других людей: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33.
  • Сравнение производительности С++ и C#
    +2
    Получается мой тест оценивает цену этой проверки с точки зрения производительности, разве это не полезно?

    Ваш тест косвенно показывает, что если перед взятием значения элемента из массива выполнить проверку на индекс, то время работы программы увеличится. Но этот факт видится мне достаточно очевидным, так что я всё ещё не могу понять пользу ваших выводов.

    Кстати, очень интересно, останется ли проверка в .Net Native?

    Вы уже начинаете задавать правильные вопросы.

    Я хотел посмотреть на работу «не последовательного» доступа к элементам.

    Давайте разделять задачи. Если мы измеряем доступ к элементу, то давайте измерять доступ к элементу. Если вы хотите посмотреть, насколько быстро можно последовательно обратиться к каждому из элементов массива, то посчитайте сумму элементов. Если вас интересует рандомизированный доступ к массиву, то тут скорее надо вести речь о промохах кэша, о размерах L1/L2/L3, о работе CPU. Постарайтесь поставить себе задачу максимально чётко и решайте именно её.

    Я постараюсь подвести итог нашей дискуссии. В комментариях к этому посту много людей старалось вам объяснить, что ваш бенчмарк не является корректным, а результаты не несут особой значимости и полезности. Вам дали много хороших советов о том, как следует подходить к рассмотрению подобных тем. Настоятельно рекомендую внимательно всё просмотреть, изучить соответствующий материал и использовать новые знания для своих следующих работ.
  • Сравнение производительности С++ и C#
    +2
    1. Компиляторов много, .NET рантаймов много. Есть же, к примеру, .NET Native: можно писать программу на том же C#, а при компиляции использовать back end от компилятора C++. А ещё я могу написать собственный компилятор С++, который будет выдавать очень медленный код: но это же не будет означать, что С++ плохой, это будет означать, что мой компилятор плохой.
    2. ECMA-334, Раздел 14.5.6.1 «Array access» гласит, что при обращении к элементу массива по индексу должна быть совершена проверка на выход за границе массива. Да, конструкции выглядят одинаково, означают похожие вещи, но разница в том, что items[i] в C# делает проверку, а в C++ нет.
    3. Ну так зачем тогда писать сортировку и добавлять сайд-эффекты? Хотите измерить чтение из массива — измеряйте чтение из массива (хотя это крайне странная задача для сравнения C++ vs C#).
  • Сравнение производительности С++ и C#
    +2
    Сравнение C# и C++ по производительности — очень странная тема.
    1. Я считаю, что некорректно сравнивать производительность языков. У языков нет производительности. Вы можете сравнивать только код, который выдаёт конкретный компилятор C++, с кодом, который выдаёт конкретный компилятор C# (который запускается по конкретной версией .NET-рантайма с конкретным JIT-компилятором). Нельзя взять какую-то одну конфигурацию для запуска, на основе которой делать выводы про язык.
    2. В своём посте вы пытаетесь сравнивать C++ программу и C# программу, которые похожи внешне, не задумываясь о том, что items[i] в C++ и C# означают разные вещи.
    3. Я считаю, что если уж сравнивать разные языки программирования по скорости, то нужно брать задачу и пытаться решить её максимально эффективно на каждом из языков, после чего проанализировать: насколько сложным получились наиболее эффективные решения, насколько быстро они работают.
    4. Если хорошо понимать методику работы конкретного JIT + понимать как работает CPU, то на C# вполне можно добиться высокой эффективности для конкретного небольшого метода, получится не хуже, чем в C++. В споре C++ vs C# самое интересное для обсуждения — накладные расходы от самого рантайма (например, GC), эффективность работы стандартный классов, которыми все пользуются, и т. п.

    Это прекрасно, что вы заинтересовались темой производительности. Я считаю, что подобные эксперименты помогут вам лучше разобраться с тем, что находится под капотом ваших программ. Но если вы решаете опубликовать свои наработки (например, на Хабре), постарайтесь удостовериться, что материал несёт в себе полезную информацию, которая основывается на хороших экспериментах и может принести пользу другим программистам.
  • Сравнение производительности С++ и C#
    +1
    Вы игнорируете мои основные тезисы. Нет смысла делать дополнительные прогоны, т. к. в бенчмарке слишком много других проблем, я писал о них выше.
    Сортировка — очень плохой пример для замеров эффективности чтения/записи. Вы прибавляете к этой операции кучу сайд-эффектов типа промахов кэша, итерации по массиву и т. п.
    Если вы делаете академический эксперимент по измерению эффективности одной конкретной операции, то измеряйте одну конкретную операцию.
    Если вы хотите решить реальную задачу, то решайте реальную задачу, а не делайте выводы о языке на основе n^2-сортировке на managed-коде. В вашем бенчмарке кроется огромное количество слабых мест, о которых вы ни строчке не написали.
  • Сравнение производительности С++ и C#
    0
    Не, unsafe-пузырёк я могу написать. Другой вопрос в том: зачем? Что именно вы хотите измерить? Без ответа на этот вопрос остальной разговор имеет мало смысла. Если вы хотите померить производительность операций чтения/записи над массивам, то сортировка вам не нужна. Если вы хотите померить то, насколько хорошо работает for, то сортировка вам тоже не нужна.
    Если же вы хотите понять, насколько производительную сортировку можно написать на каждом из языков, то вам не подходят примитивные сортировки. Брать сортировку за N^2 и добиваться от неё хорошей производительности — странное академическое упражнение.
    Сложность заключается как раз в выборе типа сортировки + особенностей её реализации под unsafe.
  • Сравнение производительности С++ и C#
    +3
    1. Если постараться, то можно сочинить такой x64-пример, который под LegacyJIT-x64 и RyuJIT-x64 будет давать результаты, которые отличаются в два раза. Что уж говорить про разницу в платформах. Если вы делаете замеры для x86, то делайте выводы для x86. Если вы делаете выводы для всех платформ, то приведите замеры для всех платформ.
    2. А в других комментариях вы писали про 4.0.30319.17929 для C#. В любом случае, C#-компилятор ≠ JIT-компилятор, это совершенно разные вещи, которые между собой не очень связаны.
    3, 4, 6, 7. Вы пытаетесь сравнивать тёплое с мягким. Идентичным должен быть функционал кода, а не то, как он выглядит. Если вы используете на С++ решение, в котором нет проверок на выход за границы массива, то используйте в C# unsafe-решение без проверок. Если вы используете в C# код, который включает в себя проверку на выход за границы, то в С++ используйте решение с проверками. Вы же измеряете решение с проверками на одном языке и решение без проверок на другом. Какие-то результаты из вашего эксперимента получить можно, но я не уверен, что на их основе можно сформулировать содержательные выводы, которые не были очевидны до проведения эксперимента.
    8, 9. У вас есть раздел «Выводы», но подобных фраз там нет.
  • Сравнение производительности С++ и C#
    +2
    1. Ну так эти результаты надо привести. JIT-x86 и JIT-x64 — это два разных JIT-компилятора. Вы приводите результаты для одного, а вывод делаете общий, это абсолютно некорректно. Например, LegacyJIT-x64 умеет разматывать циклы чётной длины: при снижении количество итераций с 10000 до 9999 время работы может увеличиться, т. к. размотка цикла отключится. LegacyJIT-x86 такой размотки нет, там такого эффекта не будет.
    2. Как я понимаю, RyuJIT у вас уже установлен (он идёт вместе с VisualStudio 2015 и .NET Framework 4.6), так что все x64-приложения под .NET 4.0+ запускаются из под RyuJIT. Рецепт отключения можно найти тут. Но на вашем месте я бы разобрался в теме намного подробнее: вы делаете выводы об эффективности JIT-компилятора, но при этом не знаете какого именно.
    3. Сложно. Как написать сортировку «наиболее правильным методом» на неуправляемый код — это действительно не такая простая задача, тут думать надо. Как я уже отмечал выше, если стоит вопрос об эффективном решении задачи, то смысла писать простую неуправляемую сортировку нет — это академическая задачка, котоаря имеет мало отношения к реальной жизни. Если вам не подошла стандартная сортировка из BCL, то скорее всего у вашей задачи есть специфика, которую нужно учитывать при реализации этой самой сортировки.
    4, 6, 7. Микробенчмаркинг — это очень сложная тематика. Я ей занимаюсь уже несколько лет, а у меня всё равно часто бенчмарки с ошибками получаются. Для грамотного замера времени C#-кода могу предложить попробовать BenchmarkDotNet. Для С++ конкретных советов дать не могу, но крайне советую поискать какие-нибудь библиотеки, которые позволят вам построить хороший бенчмарк и получить адекватные результаты.
    5, 10. Ну тогда нужно предельно чётко обозначить границы вашего эксперимента во введении и заключении. Ещё раз: вы измеряете не эффективность C# а эффективность конкретных C#-компиляторов, JIT-компиляторов, конкретных реализаций .NET и т. п. У меня есть много знакомых, которые каждый день пишут на C#, но при этом работают только с Mono. Чтобы не путать людей, нужно написать: «Результаты справедливы для Microsoft .NET Framework, версия такая-то, в качестве JIT используем RyuJIT, измеряем скорость доступа к элементу массива в управляемом коде и т. д.»
    8, 9. Я не вижу особой пользы от выводов, которые приведены «в среднем по больнице». Польза будет от наблюдений вида «если в C# писать вот так, то работать будет столько, а если писать вот так, то вот столько». Непонятно, из чего складываются ваши 10..80%, какие штуки привносят в C# накладные расходы. В статье, на которую вы ссылаетесь, всё нормально написано, в выводах делается анализ: что на что влияет. В вашей статье анализа нет, а оценки накладных расходов не включают в себя правдоподобные доказательства.