Pull to refresh

Comments 64

Опа, меня добрым словом помянули =) Для меня «хардкор» — доброе слово )))
Посещал твой доклад, было очень интересно, но к сожалению в мире .Net такой хардкор, имеет чисто академический интерес.
Почему академический? Разве понимание внутренностей среды исполнения не усиливает разработчика?
Если этим знаниям нет практического применения, то нет не усиливает.
А какие вещи, на ваш взгляд, требуют подробного рассмотрения? Или таких вещей нет?
А что за второй сюрприз был?
Закрытость рантайма. Классический вопрос на интервью Java-разработчика — «расскажите, как работает сборщик мусора». Такие вопросы задаются дотнет-кандидатам?
не знаю — не ходил на собеседования по .Net
Задаются. Хотя конечный алгоритм все же проприетарный.
То есть, спрашиваются общие вещи на понимание? Граф объектов, достижимость, корни обхода, гипотеза о поколениях, фазы, подсчет ссылок.

Еще вопрос — сборщик один? В Java сборщиков — вагон и маленькая тележка. Вот подборка статей Алексея Рагозина, например.
Да, спрашивают общие вещи на понимание. Как объекты переходят из поколение в поколение. Как происходит Dispose, что там и как происходит, сколько объект может висеть в очереди на удаление. Как можно потыкать палочкой GC.
Достижимость, корни, как объекты живут на стеке и когда оттуда уходят.

Сборщик мусора в .net один и везде, насколько я помню, утверждается, что тюнить его и работать с ним надо в последнюю очередь. Так как себе дороже может оказаться со всем этим возиться. Единственное что порой рекомендуется делать, явно указать профиль работы: standalone или server (как-то так кажется. )

Сборщик мусора еще немного меняется от версии к версии самой платформы и изменения особенно не афишируются.
Да все вопросы чисто теоритические. Сборщик один, режимов работы несколько, хотя по факту их можно назвать разными сборщиками.
Записи об управлении зависимостями нет? Очень интересно было бы.
Вы утверждаете, что .NET разработчики не интересуются внутренностями, в то же время на лекции Станислава Сидристого, которая проходила летом, народу было хоть отбавляй. Да и вопросы про сборку мусора, лямбда выражения и прочее уже давно стали стандартом на собеседованиях. Даже в самой базовой книге по .NET (Троелсен) приведены примеры IL кода.
Я немножко другое утвеждаю: закрытость информации не даёт возможности нормально изучать предмет. Про Станислава Сидристого и то, чем он занимается я уже написал в посте. И очень круто, что у нас есть люди, которые серьёзно эти проблемы изучают. К сожалению, таких людей немного.

По поводу Троэлсэна — сейчас у меня в руках русский перевод шестого издания (C# 5.0, .NET 4.5). Да, там есть целая 18 глава про CIL (как положено, синтаксис и семантика), но что-то я не вижу там особо про рантайм. CIL — это не совсем внутренности. Это всё ДО рантайма.
Добавлю также, что заинтересованность людей в вопросе возникает при появлении информационного потока о чем-либо. Чем плотнее поток, чем ярче заинтересованность. Т.е. чем чаще начнут появляться данные исследования, тем плотнее люди начнут интересоваться этим, пусть даже, зачастую, академическим вопросом.
UFO just landed and posted this here
А на мой — подробно про поверхностное )) Подробнее — у RedGate «Under the Hood of .NET Memory Management », например =)
Сразу скажу, что я не спец в дотнете. На мой взгляд, Рихтер — это неплохая вещь. Конкретно в четвертом издании (.NET 4.5) в главе по сборке мусора есть довольно много и про эвристики и про IsServerGC и про GCLatencyMode. Но к сожалению это всё на уровне «если вы сделаете вот так, то GC будет вести себя вот так-то».

Представьте, что вы управляете автомобилем. Рихтер показывает, как включить тот или иной режим двигателя, показывает, какие есть опции и рассказывает общие вещи о двигателях внутреннего сгорания. Но, на мой взгляд, не более того.

Подскажите, например, где можно прочитать про JIT, про алгоритмы сборки, про то, как устроены эвристики в том же GC, про модель памяти. Я люблю такие штуки, мне будет интересно сравнить с Java.
Оно всё понятно, что это интересно. Но 99% разрабов не нуждаются в таких знаниях.
Я участвую в разработке приложения, к которому предъявляются очень жёсткие требования функционирования 24х7. Но мне ни разу не понадобились эти знания. Ни разу, понимаете? Сегодня работодатель требует в 99% случаев знания фрэймворков, а-ля WCF, WPF. Эти фрэймворки просто громадны. Чтобы быстро девелопить, надо достаточно большую часть их держать в голове. Как в голове ещё уложить и те знания, которыми ты либо никогда, либо почти никогда не пользуешься? Я и части фрэймворков постоянно забываю. Из-за всего этого апатия наступает.
Видео по профилированию то же самое, что и первое.
fixed! Спасибо, что заметили!
Сам Явер но поймал себя на мысли что послушал бы с удовольствием. Интересно сделано. Приезжайте в Воронеж :-)
Чтобы по хардору все было — надо было Mono обсуждать. Там и свои закидоны со сборщиком мусора и открытость в наличии.
Mono — супер! Знаете кого-то, кто может о нём рассказать? Желательно, кого-то из разработчиков самой моно или кого-то, у кого моно в продакшене?
Стоит поспрашивать среди тех, кто плотно с Xamarin работает. Думаю, это то, где сейчас водятся профессионалы по Mono (из известных мне контор — TouchInstinct, причем вроде бы они даже партнеры Xamarin в России). Даже я уж на что не считаю себя разработчиком, но с багами GC в mono разбирался лично. Поэтому у них точно должен быть опыт :)
TouchInstinct более не работает на Xamarin, перешли на нативку. Устали бороться с Xamarin+Android частью. Там два GC: Java+mono. И одно это создает проблемы. Плюс ко всему супербажный runtime. iOS+mono работает отлично, багов мало. Но теряется смысл кроссплатформенности без андроида
Вот, значит я прав, что им есть о чем рассказать :)
а есть кто-то у тебя из знакомых, кто может эту или похожую историю рассказать?
Сева может в красках рассказать… Сейчас в личку скину
Есть слабая надежда, что MS поможет Mono переболеть.
UFO just landed and posted this here
Отключайте коданализ, помогает :)
Ложка дегтя:
1. Организация — были дикие очереди за кофе
2. 700р за унылый обед, цена которому оптом максимум 150р
3. Доклады реально вытащили ребята из JB. Общее ощущение осталось, что просто хотели поднять бабла в ущерб качеству.

Организаторы простите меня, если я не прав, но нас пришло 7 человек и мнение у всех одно и тоже.
Все претензии принимаю. Очереди временами были, обед мог вполне Вам не понравиться и доклады ДжетБрейнсовцев действительно были на полголовы, а то и целую голову, выше остальных.

При этом хочу обратить внимание на то, что билет с обедом в самой максимальной своей версии стоил 2500 рублей. То есть, по курсу того времени, порядка 60 евро.

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

т.е. я правильно лайфхак понял?

оплатил, пришёл, словил как и везде очередь за кофе/печеньками, возмутился и получил деньги обратно? :)
Видимо да. Мы работаем в длинную, нам неинтересно терять клиентов.
Отвечу как организатор семинара CLRium и организатор другой конференции, которая, надеюсь, случится. Обозначенные цены находятся на балансе риска с легким смещением в сторону прибыли. Во-первых в Москве достаточно высокие цены на большие площади арендуемые. Особенно, если чтобы всем было удобно. Второе: помещения не разрешают организовывать питание самостоятельно: только их кафе. Только их ценники. В работе конференции участвуют фотографы и операторы, которые берут если вы посмотрите на те же группы в контакте ну оччень не дурственно. Отсюда, если все суммировать, при этом учтя риски недонабора зала, учесть налоги и отчисления в страховой, учесть процент, который берет площадка для покупки билетов. Учесть возвраты, которые идут по форс-маржорным обстоятельствам до конференции… То 2500 — это балансовая сумма, прибыль с которой равна месячному доходу каждого кто принимал участие в ее организации, причем организация такого события требует 100% отдачи каждый день. Когда я делал CLRium, у меня не хватало времени на общение с женой, поскольку после основной работы я постоянно отвечал на десятки писем, искал помещения, договаривался и проч. Это только кажется, что деньги большие.
PS Еще я не учел случаи, когда выступающие приезжают с других городов за счет организаторов. А это туда-обратно плюс зачастую — отель — от 3 — 6 тысяч с человека до 20,000 — если тот — в Сибири.
Станислав, я был на Вашем семинаре в Питере. Все было честно. Была предложена услуга и ее стоимость — была получения услуга сопоставимая по стоимости.
Теперь про .NEXT. Была предложена услуга и ее расширенный вариант. Расширенный вариант стоил на 700р дороже и отличался только обедом. Был куплен расширенный вариант. Итог за ту разницу в 700р был получен бизнес ужасного за свои деньги качества (на входе в бар стояла табличка, предлагавшая отведать их бизнес по 150р — есть подозрения, что это тот же бизнес, который мы если по 700). Во многом именно бизнес ланч, стоимостью 150, проданный за 700 (стоимость бизнеса накрытого а ля карт в ресторане), а кому-то и за 1000 оставил ощущение желания тупо заработать.
Это всё очень классные рассуждения, безусловно. Дьявол в деталях: билеты без обеда стоили запредельно дёшево. Вы почему-то об этом не пишете.
Это дьявол не должен касаться посетителей. Я понимаю, что дорогим обедом вы могли сделать билеты без обеда дешевыми. Фактически же получилось, что люди купившие дорогие билеты просто заплатили часть за тех, кто купил дешевые, не получив ничего взамен. Я, как потребитель услуги, считаю такую практику недопустимой. Я доплатил 700р за дополнительную услугу и получил ее ненадлежащего качества. Вот и весь результат, и я не хочу думать о том, что благодаря моему дорогому билеты другие получились дешевыми.
Нехило — билет в онлайн стоит столько же сколько и оффлайн лайт — 2500 руб.
Ух ты, а обед оценивается в 2000 руб — это разница между фулл и лайт.
Мы с коллегой тоже не поняли, почему онлайн и личное посещение стоят одинаково. Обед — 2000р. Это зачем такой обед-то?
Обед в гостинице стоит дофига денег — порядка 1500 рублей. Кроме того, с каждого билета мы платим комиссии платежной системе. И налоги, разумеется. Вот 2000 и набегает.

Я не вижу смысла дальше обсуждать цену. Если Вы думаете, что можно сделать лучше и дешевле — расскажите потом, как Вам это удалось ;)

Хотелось бы поменьше бла-бла докладов от MS евангелистов. Хватает и на MS конференциях. Даешь нормальные технические доклады.
Это кстати мысль. Учтём!

Тренировкам и прогонам докладов майкрософтовцев уделим повышенное внимание!
По-моему, это бесполезно. За последние лет пять, что слежу — те же люди, тот же стиль, та же глубина. Только темы разные. Задача их понятна — рассказать о новых технологиях, ярко и привлекательно. Но для этого есть другие конференции.
Вообще, ориентируйтесь на ADD, которая, к сожалению, похоже почила в бозе. Очень качественное содержимое было.
Вторая и третья — да, неплохо, но не более. И видимо Вы последнюю ADD в Минске не видели :)
Иными словами, закрытость CLR приводит к тому, что народ в дотнет-мире не очень привык лезть в дебри, а больше ориентирован на практические вещи

А вы не думали, что причина в том, что все работает более-менее адекватно? Я слышал жалобы дотнетчиков на GC в Java, что он не адекватный и постоянно течет память по сравнению с .NET.

В Java нету структур, поэтому напедалить вещи которые не будут испытывать потребности в сборщике мусора нереально.

В Java нету нормальных genericов, поэтому даже коллекция примитивных типов — это коллекция Integer, а не int (т.е. reference type, а не value type), поэтому даже тут GC работает как угорелый, нет? В Java вообще нету нормальных genericов, обеспечивающих type safety. К примеру: http://ideone.com/HAPYjw

В .NET сборки загруженные в память шарятся (благодаря GAC), в Java вроде бы нет. Поэтому если запустить одновременно две программы на .NET они будут кушать памяти меньше, чем суммарно они едят при запуске по отдельности. В Java при запуске двух программ одновременно они жрут столько памяти, сколько можно. Кроме того, GAC позволяет избавляться от кучи проблем с версионированием (типа NoSuchMethodError)

Нет, я понимаю жалобы на недокументированность рантайма. К примеру, нельзя напедалить фичу самостоятельного удаления объектов).

Я считаю, что хардкорные вещи прокатывают на Java конференциях потому что в Java все изначально криво. Отсутствие структур, кривой GC, кривое версионирование, неработающая проблемная политика non-breaking changes, отсутствие generics, отсутствие нормальной асинхронности, отсутствие автовывода типов, неудобный синтаксис языка. В стандартных либах Java вместо удобной работы с датами и временем какая-то фигня.
Плюсую! Вы, на самом деле, очень по делу написали. Некоторые вещи типа коллекций примитивных типов или аналогов структур сделаны как API в сторонних библиотеках. На уровне языка и виртуальной машины — да, нету. Сейчас обсуждается.

Не согласен я с тем, что value type — это панацея. Если у джависта где-то «GC работает как угорелый», то он в этом месте убирает аллокацию избыточную, например, имитируя value type массивами.

Что касается GC — всё окей у джавы. Я не очень понимаю, почему Вы так агрессивно на джавовые сборщики наезжаете. Посмотрите доклад Кирилла Скрыгана в посте — там memory traffic в полный рост. Сколько у дотнетовского рантайма ручек, управляющих сборкой мусора? Количество GC-потоков можно регулировать?
так, кажется можно уже начинать затариваться попкорном.
Не согласен я с тем, что value type — это панацея

Все перечисления (enums) в .NET — это value types, DateTime — struct, Timespan — struct Point — struct, Color — struct, KeyValuePair<,> — struct, Enumeratorы во многих случаях структуры. В .NETовской библиотеке очень много value types, это снижает оверхед на GC. Хотите чтобы переменным типа какой-то структуры можно было присвоить null? Есть Nullable<> (к примеру Nullable<int> или алиас — int?) — который тоже структура

Если у джависта где-то «GC работает как угорелый», то он в этом месте убирает аллокацию избыточную, например, имитируя value type массивами.

И получаем ерунду потому что мы не можем вызывать add() на массиве, нет? А если мы описываем сложную структуру из трех полей? Три массива держать? Ну блин, это же не вариант, это говнокод в полный рост. LINQ и ленивые коллекции есть? Они тоже снижают оверхед на тот же GC на обработке коллекций при грамотном использовании (и да, при грамотном использовании обычные коллекции лучше и быстрее, но говнокодистее, а потому неюзабельнее). Нет, фичи делающие возможностью адекватную реализацию LINQ появились только в Java 8. В результате адекватно обрабатывать коллекции можно только заводя промежуточные коллекции или пользуясь новомодными трансьюдерами.

Что касается GC — всё окей у джавы. Я не очень понимаю, почему Вы так агрессивно на джавовые сборщики наезжаете.

Извините, не могу подкрепить другими фактами, просто знаю, что на сам Java GC очень сильно ругаются. Мои основные аргументы — что GC в Java сильнее нагружается, чем в .NET (ну собственно говоря песнь про value types и разделение сборок между процессами).

Сколько у дотнетовского рантайма ручек, управляющих сборкой мусора? Количество GC-потоков можно регулировать?

У дотнетовского рантайма очень мало ручек по поводу сборщика мусора, да, всего лишь один класс GC и парочка елементов в xml-конфигурации (ну и класс GCSettings). Есть общая информация по поводу того как это все работает, парочка приколов по типу того, что сборщик мусора в Release режиме может собрать объект до завершения его конструктора. Ну и слабые ссылки для избавления от утечек памяти. Но мне реально увидеть проблемы с памятью довелось всего лишь пару раз когда в коде реально держались ссылки на ненужные объекты в root-объектах.

Посмотрите доклад Кирилла Скрыгана в посте — там memory traffic в полный рост

Я не спорю что есть случаи когда проблема с памятью и сборщиком мусора реально есть. Просто мне с такими вещами повезло практически не сталкиваться благодаря грамотно написаному коду, что своему, что стороннему.

По .NETовскому рантайму действительно очень мало документации — тут я согласен. Поэтому когда хочешь залезть в дебри реально сталкиваешься с вакуумом и нету понятия откуда начинать гуглить. По C# и IL документации более-менее достаточно, да и всегда можно посмотреть во что конкретно компилируется код. Ну так уж получилось, что большинству .NET-разработчиков достаточно тех ручек, которые есть. Я спихиваю это на то, что Java не очень-то хорошо продумана, но может быть дело и в разных задачах которые решаются на разных платформах.

Btw, я немного злюсь на фразы которые восхваляют программистов Java по сравнению с .NET. Началось все с книги Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#», в которой он обосрал .NET-чиков, а потом написал кучу ерунды в книге. Так что я немного предвзят по отношению к Java.

Мне бы лично были бы более интересны доклады по пост-обработке скомпилированного кода (те же PostSharp и Fody), по автогенерации кода. Кстати, у тех же JetBrains есть очень клевый продукт — Metaprogramming System Language, который мне очень интересен.
Супер! Много интересных мыслей — мне будет, что почитать в длинные выходные!

У меня внезапное предложение: а сами не хотите у нас выступить? И заодно в программный комитет?
Боюсь в этом году точно не получится, но в следующем был бы рад выступить.
Sign up to leave a comment.