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

V>>Так вот, для дотнета этот фокус не работает.

AVK>Вполне работает.

Теоретически работает? Дык и я на конкретно этом сценарии настаиваю, что при условии локальности зависимостей должно работать... но времени со 2-го дотнета прошло слишком много, а телодвижений не вижу... этих вещей я давно жду (последние годы со скептисом), у меня и на нейтиве почти половина загрузки проца, а на дотнете аналогичное даже не взлетает.

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

C>>Тут один минус — язык Паскаль.
P>Тогда MODULA-2.
В чём отличие конского навоза от свиного?

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

V>Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная.
OMG. OMG!

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

P>>Тогда MODULA-2.
C>В чём отличие конского навоза от свиного?

С вопросами о навозе, скорее к зоотехнику или ветеринару.
Ты просил язык с определенными условиями. Тебе предложили вариант. Ты по ходу дела условия уточнил. Тебе предложили еще вариант. Мы же не обсуждаем языки. То чого ж ти репетуєш? (c) Кстати, мою точку зрения по этому вопросу можно найти в теме про синтаксический оверхед и некоторых других.

А еще навскидку только Ада всплывает с обозначенными тобой свойствами.

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

AVK>>Вполне работает.

V>Теоретически работает?

Теоретически. Но ты ж за фундаментальное ограничение это выдавал.

V> Дык и я на конкретно этом сценарии настаиваю, что при условии локальности зависимостей должно работать... но времени со 2-го дотнета прошло слишком много, а телодвижений не вижу...

А ты смотрел? Навскидку — основные изменения в 4 рантайме?

V> этих вещей я давно жду (последние годы со скептисом), у меня и на нейтиве почти половина загрузки проца, а на дотнете аналогичное даже не взлетает.

Многие оптимизации можно сделать руками. В т.ч. с передвиганием в стек и обратно. Их отсутствие — никак не show stopper.

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

ГВ>>Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал.
S>Но при этом почему-то считаешь их "мифическими".
S>Занятная мифическость получается: в компаниях с высокой культурой разработки и значительными инвестициями в отлов и починку этих мифических зверей их извести никак не могут. Наверное, зато, в наколенных поделках самоучек эти зверьки совсем-совсем не встречаются.

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

ГВ>>Эти факторы как раз и влияют на "дурь" с тестированием.
S>А-а. Ну то есть несмотря на то, что МС уже лет пять как делает "quality-based releases" и отказывается называть заранее даты выхода продуктов, чтобы избежать проблем типа "не успеваем к релизу — давайте скипнем тестирование", и вкладывает чудовищные деньги в тестирование и верификацию своих неуправляемых программ, систематически получает проблемы.
S>Если у них дурь с тестированием, то остальные, скажем так, вообще никаким QA не занимаются.

Я не знаю, как у них там всё на самом деле обстоит. Ну и потом, тестирование — это только часть QA.

S>Каким же тогда образом мы можем полагаться на надёжность программ на C++?

Что значит "полагаться"? Отказать может любое ПО, тем более — плохо проверенное перед выпуском, в т.ч. и на managed-языках. Фактически же, можно полагаться на ПО или нет показывает только продолжительная реальная эксплуатация, а не технология реализации. Не будет ошибок "прохода по памяти", так будут дыры в спецификациях более высокого уровня и будет выпускаться полностью верифицированное дырявое ПО (hole guaranteed!). Короче говоря, не надо ставить лошадь позади телеги.

ГВ>>Скорее — изменение предмета обсуждения.
ГВ>>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе.
S>С чего бы это вдруг? Нет, я буду агитировать за взвешенный подход.
S>Менеджед вовсе не означает гарантированного увеличения ресурсопотребления. Да, сборка мусора требовательнее к памяти, чем обычное выделение. Это не означает, что нельзя сочетать оба подхода. Более того, в высокопроизводительных серверных приложениях так и делают — выделяют часть памяти "статически". И таки память сейчас значительно менее ресурс, чем даже во времена начала дотнета.
S>Для роста затрат остальных ресурсов объективных причин нет.

Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия?

Что-то мне всё это напоминает того же "мифического зверька", только другой породы. Только один лагерь объявляет мифами утечки памяти, а другой — перерасход ресурсов.

ГВ>>Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
S>Угу. Вот только пока что основные результаты в компайл-тайм верификации достигнуты как раз для управляемого мира. А так как я целиком за статическую верификацию, то, естественно, моё мнение склоняется в управляемую сторону.

Ясно.

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

V>>А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ?
S>Действительно. В таких задачах, как хорошо известно, рулит Эрланг — практически интерпретатор, полностью управляемый. Дотнет слишком низкоуровневый для таких задач.

Ну вопрос в том, что подразумевать под "рулит", вон довольно известный эрлангер Валкин в где-то похожей задаче заменяет эрланг на СИ. Всё относительно, как обычно.

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

ГВ>Хорошо, хорошо, признаю, что сравнение выбрано неудачно и аллегория применена не вовремя. Не стоило сравнивать с "мифическими зверьками". Это на самом деле была аллюзия на одну очень давнюю дискуссию, ещё с участием eao197, если не ошибаюсь.
Ок.
S>>Для роста затрат остальных ресурсов объективных причин нет.

ГВ>Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия?
Это откуда такие дровишки? Можно поподробнее рассказать об этих "постоянных проверках"?

Менеджед — это тот, кто предоставляет о себе достаточно информации. Например, в MSIL у нас есть полная информация о типах и их совместимости. Некоторые ограничения дают нам гарантии сбалансированности managed-стека, и того, что для каждой операции с этим стеком мы заранее точно знаем типы аргументов. Это позволяет верификатору гарантировать типобезопасность. При этом никаких "постоянных проверок" в результирующем коде нет. Потому что эти гарантии верифицируются статически.

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

ГВ>>Хм. Я что-то не понимаю. Менеджед — это, читай, тот, "который постоянно сам себя проверяет". Как такая проверка может быть быть дешевле её полного отсутствия?
S>Это откуда такие дровишки? Можно поподробнее рассказать об этих "постоянных проверках"?

Хм. А GC разве не занимается регулярными проверками состояния памяти?

S>Менеджед — это тот, кто предоставляет о себе достаточно информации. Например, в MSIL у нас есть полная информация о типах и их совместимости. Некоторые ограничения дают нам гарантии сбалансированности managed-стека, и того, что для каждой операции с этим стеком мы заранее точно знаем типы аргументов. Это позволяет верификатору гарантировать типобезопасность. При этом никаких "постоянных проверок" в результирующем коде нет. Потому что эти гарантии верифицируются статически.

Это немного другое.

V>>Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная.
S>OMG. OMG!

Хех. Закинуть, что ли, эту подборку в официальную рассылку?

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

ГВ>Хм. А GC разве не занимается регулярными проверками состояния памяти?
Нет. То, чем занимается GC, трудно назвать "проверками состояния памяти". Если хочется покритиковать "затраты на GC", то давайте называть вещи своими именами, а не "постоянно сам себя проверяет".

Не буду вдаваться в детальный ликбез про поведение GC. Вкратце, поясню:
1. Затраты на GC зависят от количества живых объектов. Поэтому, если вы много работаете с короткоживущими объектами, то затраты на GC могут оказаться не выше, а то и ниже, чем альтернативные затраты на явное выделение/освобождение памяти в традиционных менеджерах памяти.
2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию
3. Для короткоживущих объектов с детерминированным lifetime, которые в неуправляемом мире принято размещать на стеке и экономить обращения к менеджеру памяти, в управляемых средах может применяться escape-анализ. В результате такие объекты не нагружают GC.

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

ГВ>Да нет, что ты. Переполнение буфера и утечки памяти — это как два мифических зверька, которые обязательно живут в любой C++-программе.

Скорее, как глисты, а не мифические зверьки
Все предпочитают думать, что у них-то уж точно такого нет. А по факту — один раз грязными руками за код взялся, и привет.

ГВ>Хм. А GC разве не занимается регулярными проверками состояния памяти?

в managed есть лишь лишние проверки при доступе к массиву.
Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются

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

S>1. Затраты на GC зависят от количества живых объектов. Поэтому, если вы много работаете с короткоживущими объектами, то затраты на GC могут оказаться не выше, а то и ниже, чем альтернативные затраты на явное выделение/освобождение памяти в традиционных менеджерах памяти.

"Традиционные" менеджеры памяти — это какие? Из MSC RTL? Так с ними сравнивать бессмысленно — там одна только блокировка/разблокировка хипа чего стоит.

S>2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию

"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав?

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


ГВ>>Хм. А 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; // Засечка 1
for (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 и инлайн делает, и лишние проверки выкидывает.

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

S>>2. Для долгоживущих объектов частота сборки специально снижается так, чтобы затраты были приемлемымию

ГВ>"Частота" свидетельствует о некотором периодическом процессе. "Долгоживущие объекты" — об анализе ссылок с сопутствующими холостыми проверками. ИМХО, всё это вместе как раз и есть та самая "регулярная проверка (анализ) состояния памяти". Я не прав?

Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.

1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает.
2) Чтобы не бегать по всей памяти существуют поколения, их 3. Размеры их растут экспоненциально, частота сборок уменьшается экспоненциально.
3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее.
4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.

ЗЫ. И да, ты неправ.

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

G>Вообще-то в интернете информации полно о том как работает сборщик мусора в .NET и какие там оптимизации. Почитал бы уже давно, а не выдавал домыслы, услышанные от непонятно кого за чистую монету.

Я знаю, что полно, но ты сам что именно посоветуешь?

G>1) Никакого периодического процесса нет. Сборка мусора вызывается тогда когда памяти не хватает.

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

G>3) Но для сборки мусора в младших поколениях требуется анализ объектов из старших, но статистика показала что обычно не более 5% долгоживущих объектов ссылаются на короткоживущие и используется механизм защищенных страниц чтобы сборщи мусора узнавал о записи ссылок из младшего поколения в старшее.

OK. Про использование защищённых страниц я не знал (разве что краем уха слышал).

G>4) Чтобы программа не тормозила не надо нарушать статистику, на основе которой построены алгоритмы GC, что с завидным упорством делают программисты C++ когда пишут на C#.

И в чём выражаются такие нарушения?

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

ГВ>Здравствуйте, 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 и инлайн делает, и лишние проверки выкидывает.
а если

i < arr.Length

?

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

ГВ>Здравствуйте, 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# падает примерно в полтора раза.