Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Поскольку я не знаю, что означает термин "профессионализм"

Почему-то я даже не удивлен

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>>>Дык в Техасе хорошие пастухи, а не программисты. Вот если бы они написали как настоящий стейк готовить, тогда да.
ГВ>>>С другой стороны, уж кто-кто, а пастухи-то понимают в ресурсах.
IT>>И ещё в навозе.

ГВ>Это не порок.

Да уж.. порой мне кажется, что для программиста это — насущная необходимость

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
Осталось понять, что ж ни Adobe, ни MS, ни Apple не выловили и не вылечили это всё на раз. А продолжают мне дважды в месяц присылать очередные апдейты, где "fixed the vulnerability allowing a remote attacker to gain a control over compromised system".
Наверное, менеджмент во всех трёх сговорился и систематически дурит с тестированием.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.

Когда то я это уже слышал. Лет 8 назад. Сюрприз — из IL кода с почти 100% точностью можно восстановить исходник.

ГВ> Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).

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

Здравствуйте, AndrewVK, Вы писали:

ГВ>>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.

AVK>Когда то я это уже слышал. Лет 8 назад.

Я думаю, где-то уж лет 10 должен слышать.

AVK>Сюрприз — из IL кода с почти 100% точностью можно восстановить исходник.

Ах, ну да. Рефлектор же... Ай-яй-яй мне.

ГВ>> Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).

AVK>Как человек, который перформансом дотнет приложений регулярно занимается, смею тебя заверить — на практике проблемы далеко не в оптимизациях компайлера или GC.

А в чём? Интересно было бы узнать твоё мнение.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А в чём? Интересно было бы узнать твоё мнение.

Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.

Здравствуйте, Sinclair, Вы писали:

ГВ>>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе. Фольклор — штука такая, что её забыть невозможно. Короче говоря, и лечится, и ловится это всё на раз, если менеджмент не дурит с тестированием (а оно необходимо для любой программы).
S>Осталось понять, что ж ни Adobe, ни MS, ни Apple не выловили и не вылечили это всё на раз. А продолжают мне дважды в месяц присылать очередные апдейты, где "fixed the vulnerability allowing a remote attacker to gain a control over compromised system".

Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто. ИМХО, разумеется. И трудно предположить, что эти считанные дыры могут заставить переписать всё на новом языке.

S>Наверное, менеджмент во всех трёх сговорился и систематически дурит с тестированием.

Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится.

Влияющих факторов может быть очень много: использование стороннего кода, какие-нибудь флуктуации в "давлении сроков" или, скажем, "внезапное" изменение таймингов аппаратуры. Да до хрена всего.

ГВ>Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто.

Я здесь подменил количество ошибок количеством бюллетеней — это неправильно. Но тем не менее, у той же MS, к примеру, дырок не много (в штуках не скажу).

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Проблема в том, что получив MSIL или байт-код Java зачастую уже нельзя провести тех же оптимизаций, которые возможны, если иметь доступ ко всему массиву исходных текстов.

Можно, MSIL типизированный, аннотированный и верифицируемый на предмет типобезоасности, поэтому всякие сценарии иммутабельности, распространения констант, локальности времени жизни объектов с виртуальными вызовами и т.д. выявляются уже относительно локально. А если брать технологии глобальной суперкомпиляции, то там вообще способ представления исходной информации не принципиален. Другое дело, что для дотнета к оптимизациям еще и не приступали...

ГВ>Ну и плюс к тому — разнообразные runtime-вычисления тоже вносят некоторую лепту. GC — ну, с этим понятно: постоянно работающий анализ состояния вычислительной системы на производительность может повлиять ровно одним способом (если что, то я понимаю, что здесь дело в нюансах и подчас GC может оказаться эффективнее new/delete, но именно, что подчас).

GC это да, ограничение для многих оптимизаций, т.к. стек должен быть детерминированно размечен для целей GC, хотя бы "иногда". ИМХО, это и есть камень предкновения для оптимизаций GC. Сдается мне, что еще не готов теоретический аппарат, насчет того, где оптимально расставлять ловушки для GC и обеспечивать детерминированность стека, а где можно все соптимизировать нафик в безымянных SSE регистрах даже для целочисленных операций, как это делает компилятор C++.

Здравствуйте, AndrewVK, Вы писали:

ГВ>>А в чём? Интересно было бы узнать твоё мнение.
AVK>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.

Дык, такие вещи ни от платформы, ни от языков не зависят.

ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования, где любые решения по-месту эффективности ради считаются чуть ли не хакерством. Как в том большом обсуждении задачки для собеседования про "бесконечную" очередь. В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже), но это порой требует лишнего ручного приседания в алгоритмах. И аргумент "надо, значит надо" для многих банально не подходит, т.к. большинство дотнет разработчиков не связаны с задачами, критичными к перформансу. Для них плохой перформанс — это, например, многократно открывать один и тот же файл, для последовательного чтения строк. Или организация доступа по порядковому номеру в связанных списках (встречал и такое).... Только дотнет тут не при чем, повторюсь. Это лень и безалаберность.

Здравствуйте, Klatu, Вы писали:

K>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?

Это от технологии не зависит.

Здравствуйте, Klatu, Вы писали:

ГВ>>Это не порок.

K>Да уж.. порой мне кажется, что для программиста это — насущная необходимость

Ну кому-то же надо и драйвера разрабатывать, и кодеки... Не всем же т.н. "программистам" сайты рисовать...

Здравствуйте, Геннадий Васильев, Вы писали:

В догонку, для дотнета существует еще одно ограничение, которое я даже не представляю, как обойти. Например, после оптимизации link-time codogeneration в С++ полученная программа в некоторых местах будет очень не похожа на исходную, целые типы и даже иерархии с виртуальными вызовами растворяются в небытие и структуры данных корежатся до неузнаваемости после этого акта зачаточной суперкомпиляции. А в дотнете встанет проблема привязать имеющуюся метаинформацию к такой "другой" оптимизированной программе, что может создать сложности для доступа к объектам через рефлексию. Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.

Т.е. сама необходимость обеспечивать рантайм рефлексию накладывает серьезные ограничения на трансформацию кода и данных в процессе компиляции. Не зря когда-то в рамках Singularity пришли к тому, что в их специализированном компиляторе поддерживается только compile-time рефлексия.

Здравствуйте, vdimas, Вы писали:

ГВ>>>А в чём? Интересно было бы узнать твоё мнение.
AVK>>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.
V>Дык, такие вещи ни от платформы, ни от языков не зависят.

V>ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования, где любые решения по-месту эффективности ради считаются чуть ли не хакерством. Как в том большом обсуждении задачки для собеседования про "бесконечную" очередь. В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже), но это порой требует лишнего ручного приседания в алгоритмах. И аргумент "надо, значит надо" для многих банально не подходит, т.к. большинство дотнет разработчиков не связаны с задачами, критичными к перформансу. Для них плохой перформанс — это, например, многократно открывать один и тот же файл, для последовательного чтения строк. Или организация доступа по порядковому номеру в связанных списках (встречал и такое).... Только дотнет тут не при чем, повторюсь. Это лень и безалаберность.

Я бы не стал, наверное, связывать такую культуру именно с дотнетом, поскольку вокруг "формочек к СУБД" наблюдал такие рассуждения довольно давно. Да, точно. Первый раз я это услышал от спеца, принёсшего весть не то с конференции MS, не то с какой-то UG в 1997-м: что, мол, "сейчас главное — разрабатывать программы быстро, а то, что форма рисуется не за 200 микросекунд, а за 200 миллисекунд — так кому какая разница!" и тут же: "MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась). Вот где-то тогда, видимо, этот "нересурсный" мем и зарождался.

То есть "культурные" корни тут длинные. Ещё и Java подсуетилась.

Здравствуйте, Klatu, Вы писали:

ГВ>>Поскольку я не знаю, что означает термин "профессионализм"
K>Почему-то я даже не удивлен

Ну что поделать. Могу только посоветовать ещё несколько способов перестать удивляться и начать удивлять самому:

— Выдернуть отдельные слова из реплики;
— Переставить их местами;
— Можно ещё и буквы перемешать.

Как видишь, перед тобой просто бескрайние горизонты!

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Klatu, Вы писали:

ГВ>>>Поскольку я не знаю, что означает термин "профессионализм"
K>>Почему-то я даже не удивлен

ГВ>Ну что поделать. Могу только посоветовать ещё несколько способов перестать удивляться и начать удивлять самому:

ГВ>- Выдернуть отдельные слова из реплики;
ГВ>- Переставить их местами;
ГВ>- Можно ещё и буквы перемешать.

ГВ>Как видишь, перед тобой просто бескрайние горизонты!

Спасибо за мастер-класс, но эти методы не для меня

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Klatu, Вы писали:

K>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?

V>Это от технологии не зависит.

Чего-чего?

Здравствуйте, vdimas, Вы писали:

K>>Да уж.. порой мне кажется, что для программиста это — насущная необходимость

V>Ну кому-то же надо и драйвера разрабатывать, и кодеки... Не всем же т.н. "программистам" сайты рисовать...

Больная тема?
А при чем тут драйверы с кодеками вообще?

Здравствуйте, Klatu, Вы писали:

ГВ>>Уел, уел. Про "эксплоитную дырку" разрешаю вычеркнуть.
K>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?

О, чувствуется мастерство: два предположения, и оба — с явным переходом на личности.

Здравствуйте, Klatu, Вы писали:

K>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
V>>Это от технологии не зависит.
K>Чего-чего?

Садись, два.