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

Все так, кроме как с потоками и ЖЦ. ЖЦ разные бывают. И так чтобы совсем без синхронизации невозможно в принципе. По хипу на поток так точно небывает. Бывает по хипу на процессор и по хипу на процесс. Но и там, и там будут блокировки. Не на мьютексах скорее всего. Но все же.

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

IT>>Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.

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

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

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

A>Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду.

Ошибашся. Ворд и Эксель живут обычно скромнее. 100 шрифтов на экране за раз — это уже зоопарк каой-то.

A>Мне c-smale просто симпатичен Только сильно огорчайся, у тебя ещё не всё потеряно.



A>Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще.

А может их тогда просто не уничтожать? Не, ну, процесс загроется и все грохнется само.

VD>>То есть речь шла по существу о "С-стиле vs. ОО-стиле".

A>Не факт. Можно иметь объекты Brush в которых будет хранится описание кисти, но не систменый ресурс.

Ты внимательно читал предоложение c-smile-а? Он как раз с объектами и борится объясняя что тормоза в них.

A> А ресурс будет создаватся на лету объектом Graphics. Вот о чём говорим мы, а c-smile говорил вообще не об этом, а о накладности создания большого количества мелких объектов. Рисование было просто примером такого случая.

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

A>И дело не в большой любви к Си стилю, а в оптимизации. По сути время создания и удаления системного ресурса HBRUSH может быть сравнимо со временем выделения и освобождения памяти объекта Brush.

Еще одна ошибка. Попробуй ради хохмы создать тестовое приложение в котором посоздавать эти самые объекты без HBRUSH-ей. Опять удивишся. Это очень быстро. За время пока ты создавал 100 башей ты создашь 100 тысяч объектов того же объема.

A> Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо.

Я и говорю, что исходит из ложных предпосылок.

VD>>>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.

A>Зависит от реализации.

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

A>Подожди ещё 37 секунд, а потом засчитай ему нокаут.

ОК

A>Так ты на минус обиделся? Бедный мальчик. Ну ладно, я больше не буду.

Еще раз. Плевать мне на минус. Меня инересует обоснование.

A>Нда. Ну и аргументы пошли. Ещё посуду побей и расскажи что ты потратил на меня лучшие 10 лет своей жизни с 29 до 32 лет

Интересный подход. Надо будет запомнить.

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

IT>>Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления

VD>Вообще-то можно вроде. Через битмап.



Ну да. Ты смайлик что-ли забыл поставить?

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

WH>Сжиманием кучи ГЦ в .NET занимается тотлько при сборке 2ого поколения. При сборке 0ого и 1ого поколений происходит копирование выжевших объектов в болие старшие поколение.

Кстати, все еще интереснее. Если в эфимерном сегменте (первое и нулевое поколение) остается мало места, то прямо весь сегмент может быть переведен во второе поколение (со всеми объектами), а для эфимерного может быть выделена новая память. Так что иногда даже копирования не бывает.

WH>Те скорость работы зависит только от того сколько объектов выжило.
WH>А сборка 2ого поколения производится очень редко.

+1

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

PD>Из Рихтера (картинки опускаю)

PD>When the CLR initializes, it selects a threshold size for generation 0, say, 256 KB. (The
PD>exact size is subject to change.) So if allocating a new object causes generation 0 to surpass
PD>its threshold, a garbage collection must start. Let’s say that objects A through E occupy 256
PD>KB. When object F is allocated, a garbage collection must start. The garbage collector will
PD>determine that objects C and E are garbage and will compact object D so that it is adjacent
PD>to object B. The objects that survive the garbage collection (objects A, B, and D) are said to
PD>be in generation 1. Objects in generation 1 have been examined by the garbage collector
PD>once. The heap now looks like Figure 19-8.

PD>Итак, произошла сборка мусора в 0 поколении. Все выжившие объекты были сдвинуты в памяти, дабы заткнуть дыры.

Чушь кстати, у него какая-то. Размер задется не для поколения, а для сегмента. Нулевое и первое поколение живут в одном сегменте. Во втором фрэймворке размер сегмента минимум 16 метров. Размер нулевого поколения стораются подбирать под размер кэша процессора. Тапа все что в нем делается, все быстро. Ну, и у меня реальный размер нулегвого поколения доходит до 1.5 метров.

PD>И далее там же


PD>Так что твое "копирование выжевших объектов в болие старшие поколение" и есть их перемещение в памяти.

Копирование несомненно означает перемещение в памяти. Только без перекрытия. Чистыйе ассемблерные команды. Но иногда весь сегмент переводится во второе поколение. При этом никакого копировани нет.

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

PD>Ну тогда я не знаю, кому верить — тебе или Рихтеру. Он там картинки рисует и ясно показывает, что куда перемещается. Ни о каких совсем других областях памяти там и речи нет. Или это относится к 1.x, а в 2.0 иначе ?

Павел, поколения 0 и 1 находятся в одном сегменте виртуальной памяти. Второе поколение может находиться в любом количестве сегментов, но только не в том где находятся нулевое и первое. Вернее это так для 1.1. Во втором фрэймворке сегменты которые не заполнены могут переиспользоваться. Но все равно второе поколение всегда не пересекается с нулевым и первым. Сборка нулевого поколения всегда сдвигает объекты из нулевого поколения. Так что они точно уезжают из этого сегмента. А вот при сборке второго поколения все сложнее. Тут возможно перемещение внутри одного сегмента.

Ну, а так ли понял это Рихтер и правильно ли его понял ты это уже отдельный вопрос.

S>>Я надеюсь, ты не считаешь, что сложность перемещения в памяти как-то связана с расстоянием?

PD>

А кстати, зря. Все же в кэше память двигается куда быстрее.

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

Оно и так к нему сведется. Только таких объемов в нулевом поколении почти не бывает. А о мертвых объектах ЖЦ вообще не подозревает. Для него это вообще пустая память.

PD> А это цикл над rep movs, и он будет работать ИМХО намного медленнее, чем один rep movs непрерывного блока суммарного размера всех живых. Впрочем, последнее только ИМХО, про rep scasd я не забыл

rep movs сейчас можно увидеть только в доисторическом CRT. В СLR для копирования памяти вроде как SSE2-инструкции используются. Ну, а коприрование по любому ведется пообъектно. Причем скорее всего куда более трудоемкая опрация не копирование объектов, а правка ссылок на объекты. Ведь после перемещения они все должны быть верными.

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

IT>Нужен. Но что-то у меня в голове большинство оптимизацй сводятся к отказу от размещения объекта в стеке. Если можешь приведи мне пример, когда это реально, чтобы сдвинуть мою приторможенную фантазию с места.

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

В итоге большинство маленьких объектов и массиво смогут лечь в стэк. При этом скорость будет даже выше С++-ной, так как у них отсуствуют деструкторы и зачастую кострукторы.

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

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

IT>Ну да. Ты смайлик что-ли забыл поставить?

Ты чё битпамы недолюбливашь?

Фигачешь по битмапу как хочешь, а потом битбильдом... А можно просто отключить битмап от контекста порисовать и подключить обратно.

Просто не эффективно ведь по пиксельно рисовать.

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

A>>Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду.
VD>Ошибашся. Ворд и Эксель живут обычно скромнее. 100 шрифтов на экране за раз — это уже зоопарк каой-то.

Я не сказал шртфтов, я сказал объектов GDI. Cмотрел из Task Manager.

A>>Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще.
VD>А может их тогда просто не уничтожать? Не, ну, процесс загроется и все грохнется само.

Нет, я ещё говорил о reference counting. Суть в том, что в каждый конкретный момент времени

1. У нас есть всё что необходимо для отрисовки
   
2. Все объекты уникальны по параметрам (нету двух одинаковых объектов).

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

A>> Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо.
VD>Я и говорю, что исходит из ложных предпосылок.

У него Java. Компилятора у меня нет, да и язык я не знаю. Всё таки c-smile пишет прикладные программы, это не очередной оберонщик. Хорошо бы чтобы он какие-нибудь сравнение привёл.
С другой стороны, есть ещё непочатый край для тестов в виде Linux...

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

VD>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.

Очень похоже на оптимизацию по Дворкину.

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

VD>Просто не эффективно ведь по пиксельно рисовать.

Попиксельно не эффективно пол экрана замалёвывать. Но даже какую-нибудь кастомную градиентную заливку лучше делать попиксельно чем побитматно.

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

VD>Здравствуйте, c-smile, Вы писали:

VD>А в setBrush что происходит? Куда девается кисть ассоциированная с контекстом в данный момент? Когда уничтожается эта кисть?

DeleteObject. Для brush/pen это дешевая операция. Для font нет.

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

VD>если бы небало using-а пришлось бы записывать вот таким безобразным образом:
Нет еще хуже. Вот таким

using System;
using System.IO;

class Program
{
    static void Main()
    {
        string sourcePath = @"C:\boot.ini";
        string destPath = Path.ChangeExtension(sourcePath, ".test");
        string line;
        StreamReader reader = null;
        StreamWriter writer = null;

        try 
        {            
            try 
            {            
                reader = File.OpenText(sourcePath);
                writer = new StreamWriter(destPath);
        
                while ((line = reader.ReadLine()) != null)
                    if (line.Contains("=\""))
                        writer.WriteLine(line);
            }
            finally
            {
                if (reader != null)
                        reader.Close();
            }
        }
        finally
        {
            if (writer != null)
                    writer.Close();
        }
    }
}

Ибо в твоем варианте если reader.Close(); бросит исключение то writer.Close(); вызван не будет.

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

VD>>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.
IT>Очень похоже на оптимизацию по Дворкину.
Оптимизицией по Дворкину занимается программист, а здесь компьютер. Разницу чувствуешь?

VladD2 wrote:

> N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не
> используются. зачем они нужны?
> Финалайзеры конечно зло. Но без и ни файлик в ОС не отроешь, и
> подключение к БД можно проворонить.
> Так что самостоятельно их конечно и в дотнете никто особо не клепает,
> но использовать переодически приходится. Вот только в дотнете они
> ничего не останавливают. Они вызваются в отдельном потоке.

Останавливают — всю систему. Когда по какой-то причине финализаторы
блокируют поток финализации.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

WH>Нет еще хуже. Вот таким
...
WH>Ибо в твоем варианте если reader.Close(); бросит исключение то writer.Close(); вызван не будет.

Ну, он вроде как исключений не генерирует.

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

C>Останавливают — всю систему. Когда по какой-то причине финализаторы
C>блокируют поток финализации.

Нет. Плевать CLR на этот потох хотел.

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

VD>>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.

IT>Очень похоже на оптимизацию по Дворкину.

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

VladD2 wrote:

> C>Останавливают — всю систему. Когда по какой-то причине финализаторы
> C>блокируют поток финализации.
> Нет. Плевать CLR на этот потох хотел.

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

Вообще, MS надо убить за использование финализаторов для освобождения
критичных ресурсов.

--
С уважением,
Alex Besogonov (alexy@izh.com)