Высокий/низкий уровень, ручное/автоматическое управление

← →
DiamondShark © (2010-11-10 22:09) [120]

> Лично для меня более предпочтительны те системы, где о параллелизме
> думали с самого начала. В отличие от систем, где понадеялись
> на автоматические средства.

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

> Пока что доверия им нету большого, хотя бы потому, что я
> плохо понимаю, как это будет работать.

Argumentum ad ignoratio. Волшебно.

> Скажем так, возможность модифицировать переменные для меня
> важнее автоматического параллелизма.

Расскажи, как возможность модифицировать переменные препятствует параллелизму?

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

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

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

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

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

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

Хочешь верь, хочешь нет, но автоматическое управление памятью этому не мешает нисколько.

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

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

> Да вы просто Cuda с OpenCl не видели.

А вы просто параллельных языков не видели.
Да ещё и SIMD c MIMD путаете.

> Тот же Visual С++ умеет делать код который будет работать
> на разных ядрах.

И как это ему удаётся, если ОС такого не поддерживает?

> Все используют OpneMP вставки.

Это не то. OpenMP использует потоки. В лучшем случае -- пул потоков. Потоки слишком тяжёлые. А других средств в ОС нет.

Отвлекитесь от существующих ОС и реализации многопоточности в них. Я говорю не о многозадачности, а о внутреннем параллелизме алгоритмов.

> А как связана параллельность языка с управляемой кучей?

Очень просто связана. Явное управление кучей вносит паразитные зависимости, которые сильно мешают параллельности.
Примитивнейший пример:

a := new(TA);
DoInvariant1(a); // эти ветки
DoInvariant2(a); // выполняются параллельно
dispose(a); // здесь точка синхронизации, но она тут нафиг не нужна
// дальше код, независимый от а
// но он не может выполняться до завершения обоих
// DoInvariant1(a) и DoInvariant2(a)

← →
_oxffff (2010-11-10 22:15) [121]

> Очень просто связана. Явное управление кучей вносит паразитные
> зависимости, которые сильно мешают параллельности.
> Примитивнейший пример:
>
> a := new(TA);
> DoInvariant1(a); // эти ветки
> DoInvariant2(a); // выполняются параллельно
> dispose(a); // здесь точка синхронизации, но она тут нафиг
> не нужна
> // дальше код, независимый от а
> // но он не может выполняться до завершения обоих
> // DoInvariant1(a) и DoInvariant2(a)

Видимо имелось ввиду не dispose и не finalize.
А просто очистка корня
a:=nil?

По сему
1. А подсчет ссылок религия не позволяет?
2. Пометить объект на удаление(поместить в список на удаление), который например разделяется DoInvariant1 и DoInvariant2 и последний закончивший его обрабатывает.

← →
Mystic © (2010-11-10 22:52) [122]

> Расскажи, как возможность модифицировать переменные препятствует
> параллелизму?

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

Self.Method1(); Self.Method2();

определить, можно ли параллелить вызовы Method1 и Method2 очень тяжело. По крайней мере мне неизвестны системы такого рода.

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

Да, используются динамические структуры данных. Но это тот случай, когда за динамической памятью надо следить, так что от ручного управления никуда. Ветки без взяимных влияний, ну скажем так, такие конфликты можно порешать руками. Самые сильные движки написаны на C/C++ (средней силы иногда встречаются Delphi/Pascal), а все прочие языки нервно курят в сторонке.

← →
DiamondShark © (2010-11-11 10:34) [123]

> Видимо имелось ввиду не dispose и не finalize. А просто
> очистка корняa:=nil?

Нет. Имелось в виду именно явное удаление динамического объекта.

> По сему 1. 2.

Это и есть частные случаи автоматического управления.

← →
oxffff © (2010-11-11 10:36) [124]

← →
oxffff © (2010-11-11 10:48) [125]

> DiamondShark © (11.11.10 10:34) [123]
>
> > Видимо имелось ввиду не dispose и не finalize. А просто
>
> > очистка корняa:=nil?
>
> Нет. Имелось в виду именно явное удаление динамического
> объекта.

А как ты собрался удалить или финализировать(также синхронизируя доступ к членам объекта ) объект в управляемой куче, если на него есть ссылки в DoInvariant1 и в DoInvariant2?

← →
DiamondShark © (2010-11-11 11:29) [126]

> В случае наличия контеста, типа Self.Method1(); Self.Method2();
> определить, можно ли параллелить вызовы Method1 и Method2
> очень тяжело.

Но не невозможно.

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

Во-вторых, можно ввести декларирование инвариантов, что-то вроде:
class A
int i;
procedure Method1; const; // метод задекларирован как не изменяющий состояние класса
end

procedure A.Method1;
begin
i = 123; // compiller error;
end;

В-третьих, таки да, можно (и нужно) разрабатывать специальные языки.

> Но это тот случай, когда за динамической памятью надо следить,
> так что от ручного управления никуда.

У вас тут причина со следствием попутана.
За динамической памятью надо следить, потому что доступно только ручное управление.

> Ветки без взяимных влияний, ну скажем так, такие конфликты
> можно порешать руками.

Можно, конечно.
Можно, например, и без водопровода жить.

> Самые сильные движки написаны на C/C++ (средней силы иногда
> встречаются Delphi/Pascal), а все прочие языки нервно курят
> в сторонке.

К свойствам языков эта кухонная статистика вообще не имеет никакого отношения.
Почему кухонная? Ну, потому что это рассуждение вроде такого:
"Моя соседка тётя Маша родом из Пскова, и она готовит самые вкусные щи, которые я ел. Значит во Пскове готовят лучшие щи."

Вы не замечаете, как вы передёргиваете?
Есть множество движков.
Есть подмножества: А=самые сильные, Б=средние. Мощность Б много больше мощности А.
Дельфи встречается в Б но не встречается в А.
Какой из этого может следовать вывод? Строго говоря -- никакого. Правдопоподобной гипотезой может быть то, что в общем множестве программ на Дельфи вообще мало.
Больше ничего из такой статистики не следует.

Кстати, C и C++ -- это совершенно разные языки. C семантически изоморфен подмножеству Дельфи, значит программу на C можно абсолютно формально перевести на подмножество Дельфи.
Значит ли это, что сильный движок на C после этого станет средней руки, а то и вообще пойдёт курить?

← →
DiamondShark © (2010-11-11 11:34) [127]

> Дык и не ставь ее туда и будет счастье. В чем сложность?

И что с ним делать, если управление памятью только ручное?

> А как ты собрался удалить или финализировать(также синхронизируя
> доступ к членам объекта ) объект в управляемой куче, если
> на него есть ссылки в DoInvariant1 и в DoInvariant2?

Я -- никак.
А автоматический сборщик -- либо по счётчику ссылок, либо по графу доступности.

← →
oxffff © (2010-11-11 11:45) [128]

> DiamondShark © (11.11.10 11:34) [127]
>
> > Дык и не ставь ее туда и будет счастье. В чем сложность?
>
>
> И что с ним делать, если управление памятью только ручное?
>
>
>
> > А как ты собрался удалить или финализировать(также синхронизируя
>
> > доступ к членам объекта ) объект в управляемой куче,
> если
> > на него есть ссылки в DoInvariant1 и в DoInvariant2?
>
> Я -- никак.
> А автоматический сборщик -- либо по счётчику ссылок, либо
> по графу доступности.

Ну так и нужно предоставлять нормальный код, а не код [120], выдавая его за неуправляемый
Поэтому я правильно и написал,что видимо имелось ввиду не dispose и не finalize, а просто обнуление ссылки или работа дальше сразу.

Поэтому проблема надуманна. Ее здесь нет.

← →
DiamondShark © (2010-11-11 12:02) [129]

> Ну так и нужно предоставлять нормальный код, а не код [120],
> выдавая его за неуправляемый

В [120] пример именно неуправляемого кода.

← →
oxffff © (2010-11-11 12:13) [130]

> DiamondShark © (11.11.10 12:02) [129]
>
> > Ну так и нужно предоставлять нормальный код, а не код
> [120],
> > выдавая его за неуправляемый
>
> В [120] пример именно неуправляемого кода.

Хочешь сказать, что он правильный?
В одном стиле задачи решаются одним способом. А в другом другим.
Но они решаются. А кто не решает, тот идет лесом. :)

← →
oxffff © (2010-11-11 12:16) [131]

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

← →
DiamondShark © (2010-11-11 12:21) [132]

> Хочешь сказать, что он правильный?

Слово "псевдокод" слышал?

Это пример гипотетического языка, в котором внутренний параллелизм есть, а автоматического управления памятью нет.

Предусловия простые: обе процедуры заведомо не имеют взаимозависимостей.

Результат: требование явного освобождения памяти формирует паразитную зависимость.

Непонятно, что в примере может быть непонятно.

← →
oxffff © (2010-11-11 12:28) [133]

> DiamondShark © (11.11.10 12:21) [132]
>
> > Хочешь сказать, что он правильный?
>
> Слово "псевдокод" слышал?
>
> Это пример гипотетического языка, в котором внутренний параллелизм
> есть, а автоматического управления памятью нет.
>
> Предусловия простые: обе процедуры заведомо не имеют взаимозависимостей.
>
>
> Результат: требование явного освобождения памяти формирует
> паразитную зависимость.
>
> Непонятно, что в примере может быть непонятно.

Что подразумевается под вызовом dispose(a) в этом языке?

← →
euru © (2010-11-11 12:28) [134]

> oxffff © (11.11.10 12:13) [130]
> Хочешь сказать, что он правильный?

Как мне показалось, он как раз-таки наоборот хочет сказать, что такой код или несколько некорректен или избыточен.

← →
DiamondShark © (2010-11-11 12:28) [135]

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

Неуправляемых ресурсов быть не должно.
Сама ОС должна быть средой исполнения управляемого кода.
Специально же писал, ссылки на Вирта давал. Как об стену горох.

← →
DiamondShark © (2010-11-11 12:30) [136]

> Что подразумевается под вызовом dispose(a) в этом языке?

то же, что и в Дельфи.

← →
oxffff © (2010-11-11 12:30) [137]

> euru © (11.11.10 12:28) [134]
>
> > oxffff © (11.11.10 12:13) [130]
> > Хочешь сказать, что он правильный?
>
> Как мне показалось, он как раз-таки наоборот хочет сказать,
> что такой код или несколько некорректен или избыточен.

Если человек не может написать этот код правильно, это чьи проблемы? :)

← →
oxffff © (2010-11-11 12:34) [138]

> DiamondShark © (11.11.10 12:30) [136]
>
> > Что подразумевается под вызовом dispose(a) в этом языке?
>
>
> то же, что и в Дельфи.

Тогда [137].

Подзадача финализации+деаллокации этого примера решаема несколькими способами. Если кто-то хочет переложить решение на установление достижимости объекта автоматически, то он просто обленился решать задачи.

А

Результат: требование явного освобождения памяти формирует паразитную зависимость.

Абсурдно в неуправляемом окружении.

← →
euru © (2010-11-11 12:35) [139]

> oxffff © (11.11.10 12:30) [137]

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

← →
oxffff © (2010-11-11 12:41) [140]

> euru © (11.11.10 12:35) [139]
>
> > oxffff © (11.11.10 12:30) [137]
>
> Ну так вы же выступаете в защиту явного управления временем
> жизни объекта. А этот пример показывает, что при использовании
> параллельного программирования такое управление может привести,
> например, к неоправданной потере производительности.

Этот пример показывает, как можно потерять в производительности решая задачу неверно.

Тем не менее с таким же успехом можно потерять в производительности при "проходе по графу сборщиком мусора " в момент остановки исполнителей DoInvariant1 и DoInvariant2.

← →
euru © (2010-11-11 12:42) [141]

> oxffff © (11.11.10 12:34) [138]
> Если кто-то хочет переложить решение на установление достижимости
> объекта автоматически, то он просто обленился решать задачи.

В принципе механизмы ООП можно сэмулировать и в обычных языках. А если кто-то для использования этих механизмов хочет предложит ООП-языки, то он тоже просто обленился решать задачи?

← →
oxffff © (2010-11-11 12:43) [142]

> euru © (11.11.10 12:42) [141]
>
> > oxffff © (11.11.10 12:34) [138]
> > Если кто-то хочет переложить решение на установление достижимости
>
> > объекта автоматически, то он просто обленился решать задачи.
>
>
> В принципе механизмы ООП можно сэмулировать и в обычных
> языках. А если кто-то для использования этих механизмов
> хочет предложит ООП-языки, то он тоже просто обленился решать
> задачи?

Может и обленился.
Но этому разве дается термин паразитивность?

← →
DiamondShark © (2010-11-11 12:46) [143]

> euru © (11.11.10 12:35) [139]

Я уж думал, что действительно настолько непонятно выражаюсь. ;)

> oxffff © (11.11.10 12:34) [138]
> Подзадача финализации+деаллокации этого примера решаема
> несколькими способами.

Без автоматического управления памятью эффект будет ровно такой же: появление зависимости.

> то он просто обленился решать задачи.

Анекдот про "в гамаке и на лыжах" знаете?

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

> Абсурдно в неуправляемом окружении.

Именно. Неуправляемое окружение состоит из абсурда чуть менее, чем полность. Именно эту мысль я стараюсь донести.

← →
oxffff © (2010-11-11 12:48) [144]

> euru © (11.11.10 12:42) [141]
>
> > oxffff © (11.11.10 12:34) [138]
> > Если кто-то хочет переложить решение на установление достижимости
>
> > объекта автоматически, то он просто обленился решать задачи.
>
>
> В принципе механизмы ООП можно сэмулировать и в обычных
> языках.

Более того я читал об этой реализации на параметризованном лямбда исчислении год назад. Это мягко говоря запутанно и не всегда выразительно. И то пришлось им вводить дополнительную абстракцию как экзистенциальный тип. Видел объектное исчисление Карделли. Но не читал.
Хотя они эквивалентны по выразительности.

← →
euru © (2010-11-11 12:48) [145]

> oxffff © (11.11.10 12:41) [140]
> Этот пример показывает, как можно потерять в производительности
> решая задачу неверно.

А как эту задачу решить верно?

> Тем не менее с таким же успехом можно потерять в производительности
> при "проходе по графу сборщиком мусора " в момент остановки
> исполнителей DoInvariant1 и DoInvariant2.

Сборщик это сделает в либо в свободное время либо по необходимости (например, отсутствие свободной памяти в куче).

← →
DiamondShark © (2010-11-11 12:49) [146]

> Но этому разве дается термин паразитивность?

Русский -- не родной?

Паразитность. Без "-ив-". Технический термин. Общепринятый.

← →
oxffff © (2010-11-11 12:51) [147]

> DiamondShark © (11.11.10 12:46) [143]
>
> > euru © (11.11.10 12:35) [139]
>
> Я уж думал, что действительно настолько непонятно выражаюсь.
> ;)
>
>
> > oxffff © (11.11.10 12:34) [138]
> > Подзадача финализации+деаллокации этого примера решаема
>
> > несколькими способами.
>
> Без автоматического управления памятью эффект будет ровно
> такой же: появление зависимости.

Больше похоже на "зависимость" программиста от сборщика мусора. Но это как говорится каждому свое.
Привел бы циклические ссылки я бы согласился.

Поэтому мне интересен гибридный способ управления.

← →
euru © (2010-11-11 12:56) [148]

> oxffff © (11.11.10 12:48) [144]

О кучах, стеках и прочем:
"...фундаментальная проблема заключается в ошибочной вере в то, что система типов имеет какое-либо отношение к стратегии выделения памяти. Просто неверно, что выбор использования стека или кучи имеет какое-либо отношение к типу сущности, располагаемой в памяти. Правда заключается в том, что выбор механизма распределения памяти имеет отношение только к требованию времени жизни области памяти."
http://blogs.msdn.com/b/ruericlippert/archive/2010/10/25/the-truth-about-value-types.aspx

> Больше похоже на "зависимость" программиста от сборщика
> мусора.

Вот смотри: была задача написать две процедуры, не обладающие побочным эффектом относительно а.
Написали.
Нафига при этом думать об их ВОЗМОЖНОЙ зависимости? Если, ёлкин клин, задача была НАПИСАТЬ блин НЕЗАВИСИМЫЕ ПРОЦЕДУРЫ.

> Привел бы циклические ссылки я бы согласился.

О! Циклические ссылки -- это круто.
Особенно, при ручном управлении. Гы. :))))))))))

> Поэтому мне интересен гибридный способ управления.

А зачем? Объясни, мне правда интересно.
Только, пожалуйста, не ссылайся на проблемы в гибридных средах, вроде дотНЕТ.
Вот есть ОС, которая вся целиком -- исполняющая среда управляемого кода.
Куда здесь гибридный способ управления?

> euru © (11.11.10 12:56) [148]
>
> > oxffff © (11.11.10 12:48) [144]
>
> О кучах, стеках и прочем:
> "...фундаментальная проблема заключается в ошибочной вере
> в то, что система типов имеет какое-либо отношение к стратегии
> выделения памяти. Просто неверно, что выбор использования
> стека или кучи имеет какое-либо отношение к типу сущности,
> располагаемой в памяти. Правда заключается в том, что выбор
> механизма распределения памяти имеет отношение только к
> требованию времени жизни области памяти."
> http://blogs.msdn.com/b/ruericlippert/archive/2010/10/25/the-
> truth-about-value-types.aspx

А где [144] я указал на эту связь?

> DiamondShark © (11.11.10 13:06) [149]
>
> > Больше похоже на "зависимость" программиста от сборщика
>
> > мусора.
>
> Вот смотри: была задача написать две процедуры, не обладающие
> побочным эффектом относительно а.

Интересно, а как это 2 ссылки на одну сущность лишились побочного эффекта? Эти процедуры не являются чистыми функциями. И обладают побочным эффектом.

> euru © (11.11.10 12:48) [145]
>
> > oxffff © (11.11.10 12:41) [140]
> > Этот пример показывает, как можно потерять в производительности
>
> > решая задачу неверно.
>
> А как эту задачу решить верно?

Я выше написал. :)

> > Тем не менее с таким же успехом можно потерять в производительности
>
> > при "проходе по графу сборщиком мусора " в момент остановки
>
> > исполнителей DoInvariant1 и DoInvariant2.
>
> Сборщик это сделает в либо в свободное время либо по необходимости
> (например, отсутствие свободной памяти в куче).

1. А если нет столько памяти?
2. А если есть ограничения на размер кучи?
3. А если есть требования освобождать в момент последней потери корня.

Управляемая куча спасет Вас? :)

> Сборщик это сделает в либо в свободное время либо по необходимости
> (например, отсутствие свободной памяти в куче).

Или по просьбе трудящихся. По крайней мере в MacOS и iOS таки возможно.

> 1. А если нет столько памяти?

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

> DiamondShark © (11.11.10 13:06) [149]
>
>
> > Привел бы циклические ссылки я бы согласился.
>
> О! Циклические ссылки -- это круто.
> Особенно, при ручном управлении. Гы. :))))))))))
>
>
> > Поэтому мне интересен гибридный способ управления.
>
> А зачем? Объясни, мне правда интересно.
> Только, пожалуйста, не ссылайся на проблемы в гибридных
> средах, вроде дотНЕТ.
> Вот есть ОС, которая вся целиком -- исполняющая среда управляемого
> кода.
> Куда здесь гибридный способ управления?

Я бы использовал в качестве решения проблемы циклических ссылок управляемую кучу. Для остального неуправляемую.

У меня это Windows. Я бы с удовольствие в данный момент использовал гибридный способ. Есть у меня такая сейчас задача.

А если у кого исполняющая среда управляемого кода. Тогда пусть он и думает.

> tesseract © (11.11.10 14:27) [154]
>
> > 1. А если нет столько памяти?
>
>
> А что неуправляемая куча решит данный вопрос?

А если нет памяти, придется собирать мусор и дефрагменировать кучу.
А это время.

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

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

> Во-вторых, можно ввести декларирование инвариантов, что-
> то вроде:

Такое дополнительное декларирование это тоже дополнительная работа. Может оказаться, что ручками распараллелить критичный кусок будет быстрее, чем по всему проекту поддерживать инварианты.

Во-вторых, есть случаи, когда такие инварианты доступны только через обращение к чему-то внешнему, вроде базы данных, DLL, ... В этом случае компилятор никак не сможет проверить инвариантность, посему надо будет писать в коде "мамой клянусь!". Что опять может породить интересные баги.

> > Но это тот случай, когда за динамической памятью надо
> следить,
> > так что от ручного управления никуда.
>
> У вас тут причина со следствием попутана.
> За динамической памятью надо следить, потому что доступно
> только ручное управление.

Нет, за динамической памятью надо следить, потому что стоит задача максимально полно и эффективно использовать ограниченный объем памяти. В процессе перебора вариантов мы исчерпали отведенный нам объем памяти. Что делать? И в том и в другом случае надо пройтись по дереву и обнулить ссылки на неактуальные позиции, что равносильно удалению объектов. Только потом надо запускать сборщик мусора, который выполнит еще кучу лишней работы.

> Кстати, C и C++ -- это совершенно разные языки. C семантически
> изоморфен подмножеству Дельфи, значит программу на C можно
> абсолютно формально перевести на подмножество Дельфи.
> Значит ли это, что сильный движок на C после этого станет
> средней руки, а то и вообще пойдёт курить?

Используется C с классами обычно. Все возможности ООП не юзаются, только некий минимум. C/C++ лучший выбор больше из-за того, что есть поддержка x64, что дает 30% производительности. Но в целом это задача, где возможностей C хватает и в чем-то большем большой нужды нет.

А так ситуация такая. Если реализовать базовые техники (генерация ходов с использованием битбордов, альфа-бета, киллеры, Z-Orbice, стандартные элементы оценки позиции, нулевой ход, ...), то получаем движок средней силы. Это можно реализовать на C, можно на Delphi. Уже в случае всяких C# возникает небольшой геморрой: в погоне а производительностью нужно постоянно раскручивать ту или иную конструкцию на предмет того, а что это будет нам стоить.

> А это время.

Сборка мусора навряд ли займёт время больше свалки / загрузки выгружаемой памяти процесса по нужде системы.

> oxffff © (11.11.10 14:10) [150]
> А где [144] я указал на эту связь?

Да это больше к слову "читал" относилось. :)

Основной посыл: "Пусть компилятор и среда времени выполнения заботятся о времени жизни хранилища; это то, для чего они предназначены."

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

> tesseract © (11.11.10 14:36) [158]
>
> > А это время.
>
>
> Сборка мусора навряд ли займёт время больше свалки / загрузки
> выгружаемой памяти процесса по нужде системы.

А это уж совсем быстро. Пару тактов. :)

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки