Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Губанов Сергей Юрьевич

Страницы: 1 ... 36 37 [38] 39 40
556
Ну вот я как раз сейчас занимаюсь оптимизацией (по скорости)
Кстати, ни из одного стандартного контейнера нельзя удалить произвольный элемент за О(1) просто потому, что сначала его нужно в нём найти. Контейнеры из которых удаление элементов невозможно в принципе могут быть реализованы эффективнее контейноров из которых удаление элементов в принципе возможно. Ну и так далее. Так что, в моём понимании, оптимизация, если конечно это не просто чистка от говнокода, подразумевает неизбежный отказ от универсальных стандартных шаблонных кубиков.

557
for_each/find/map std::vector set и stack и queue и deque.
Осталось не понятным пишешь ли ты сам новые шаблонные алгоритмы или же всегда всё только из готовых-стандартных шаблонных кубиков собираешь?

558
Борьюсь с паузами уменьшая количество объектов видимых сборщику мусора.

Прячу объекты на массивах структур.

Миллионы строк загруженных из БД спрятал на больших массивах char[сегмент][смещение]. Вместо System.String для них использую 4-х байтовую структурку в которой закодировано сегмент-смещение начала "строки". Там первая буква -- длина строки, затем собственно содержимое. Когда кончается текущий сегмент создаю новый. Эти строки "вечные" -- их нельзя удалить. Поэтому они пригодны только для "вечных" данных -- как раз для содержимого БД.

Наблюдаемый прогресс в производительности программы радует  :) :) :)

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

559
а как часто и в каких задачах они вообще используют такие "типовые" алгоритмы, как сортировка, двоичный поиск и им подобные?
Пишу на C#. Обощённые алгоритмы почти не использую. Несколько раз понадобилась сортировка (для встроенного в программу профилировщика), тогда я быстренько написал её сам. Двоичный поиск никогда не был нужен. Иногда использую generic типы в контейнерах (хэштаблицах), но только для значений, не для ключей, ключи конкретные ибо обобщённо делать поиск по generic ключу неэффективно получается (для каждого конкретного типа ключа поиск можно реализовать более эффективно чем обобщённо для всех сразу).

560
Общий раздел / Re: FFI for Oberon
« : Февраль 21, 2012, 11:24:48 am »
С js аналогично - на js пишем код-переходник который с точки зрения Оберона будет обычным обероновским модулем.
Как-то я слабо представляю себе такую операцию.
Это для случая когда Оберон-программа интерпретируется браузером, js для которого более нативный.

561
Общий раздел / Re: автомобили-роботы
« : Февраль 20, 2012, 08:57:01 pm »
Сначала хотелось бы узнать про железо. Например, Бураном управляли четыре железяки:
Система управления орбитального корабля Буран Если одна железяка выдавала команду отличную от команд выданных тремя другими железяками, то она считалась изломавшейся и отключалась. И так далее. Когда оставались всего две железяки, если они выдавали разные команды, то отключалась одна из них наугад.

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

Правда и стоить такое авто будет... как Буран  :)

562
Общий раздел / Re: FFI for Oberon
« : Февраль 20, 2012, 12:20:39 pm »
Кстати в Питоне реализован второй вариант. Модули Питона можно писать как на самом Питоне, так и на Си в том смысле что модуль написанный на Си (с использованием соответствующего API) будет виден из Питона так как будто он написан на Питоне.

563
Общий раздел / Re: FFI for Oberon
« : Февраль 20, 2012, 12:13:54 pm »
Тут, как я понимаю, есть два пути:...Как думаете, что лучше?
Видимо, зависит от того что внутрь чего будет в конце-концов встроено (embedded):
1) Процесс написанный на Обероне будет загружать библиотеку написанную на чужом языке (embedded Js), или
2) Процесс написанный на чужом языке будет загружать библиотеку написанную на Обероне (embedded Oberon).

Вон у нас на работе есть программа написанная на C#, которая загружает библиотеку *.so написанную на С++. Но плюсовики жаждут реванша, хотят наоборот, чтобы программа написанная на С++ ембедила Mono и запускала в ней модуль написанный на C#. Я заниматься ембедингом моны отказываюсь, а у них самих руки (пока) не доходят, так и живём  :)

Пока проблема курицы и яйца не решена интерфейс сделали универсально узким: подмножество-пересечение обоих языков. Типа такого: процедура в которую передаётся массив байтов с сериализованным сообщением и аналогичная процедура обратного вызова. С массивами байтов все языки работать умеют.

564
У меня это реализовано так:
У Вас хотя и с указателями, но тоже без полиморфных объектов (по таким unsafe указателям виртуальную функцию не вызовешь).

Вот ведь засада! То есть если мне нужно миллион полиморфных объектов, то от сборщика мусора их в массивы структур не спрячешь  >:(

565
Общий раздел / Re: Правила другого форума
« : Февраль 13, 2012, 08:59:14 pm »
Вот первый подвернувшийся пруф: http://www.delphikingdom.ru/asp/talktopic.asp?ID=365&ref=msg&msg=340#msg341
Хорошая ссылка. Руслан Богатырёв наверное лопнул от смеха когда (и если) узнал, что Рюмшин забанил меня на оберонкорке за "дать в морду Ткачёву".

566
Много объектов в моей программе может быть размещено в массивах структур. Много, но не все. Как быть с полиморфными объектами? Для вызова виртуальной функции нужен настоящий (трассируемый сборщиком мусора) указатель на объект, а не индекс массива...

567
На работе на этой неделе применил способ размещения объектов в массивах структур. Чтобы при увеличении количества объектов не реаллоцировать массив с целью увеличения сделал его двумерным и адресуюсь по сегменту-смещению. По мере надобности добавляю новый сегмент.

В качестве "указателя" на объект выступает 4-байтовая структура на вроде такой:

public struct PointerToMyObject
{
    private ushort segment, offset;

    public int SomeValue1
    {
      get
      {
        return descriptors[this.segment][this.offset].someValue1;
      }
    }

    public void DoSomething1 (int x, int y)
    {
      descriptors[this.segment][this.offset].DoSomething1(x, y);
    }
}

descriptors -- двумерный массив структур (тушки объектов MyObject).



568
Общий раздел / Transactional Synchronization Extensions (TSX)
« : Февраль 09, 2012, 04:27:29 pm »
Интересно чем это нам "грозит"?

Процессоры Haswell станут большим скачком в развитии CPU

Цитировать
В своём блоге компания Intel сообщила о том, что в процессорах с архитектурой Haswell будет реализован механизм транзакционной памяти, предполагающий одновременное выполнение сложных многопоточных операций, но при этом изолированно друг от друга, что исключает "крах" всей программы из-за ошибки в одном потоке.

В архитектуре Haswell данный механизм назван Transactional Synchronization Extensions (TSX), который, в свою очередь, разделяется на две основные части: Hardware Lock Elision (HLE), транслирующую "обычные" программы в транзакционные с сохранением работоспособности, и Restricted Transactional Memory (RTM), что является, непосредственно, транзакционной памятью.

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

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


569
Общий раздел / Re: Юмор
« : Февраль 08, 2012, 12:52:08 pm »
А у меня показывает "8644,1" и никаких слов "Error" на странице нема.
Сейчас и у меня тоже стал показывать "8 644,1". Кстати, это старая денежная база (на 1 января). Новую (на 1 февраля), которая была Error, убрали.

570
PS. Хотя я не очень понял при чем тут высоконагруженное нечто, ведь именно на производительность сборщик мусора в среднем не влияет (где-то с ним эффективней, где-то без него). Он гадит только в случае если нам нужен реалтайм.
Не только в реалтайме если речь о Блэкбоксе. В Блэкбоксе сборщик мусора не ранжирует объекты по поколениям, поэтому при большом количестве объектов он тормозит постоянно. Когда я сравнивал Блэкбокс с дотнетом, то обнаружил следующее. Допустим есть 5 миллионов фоновых объектов и 1000 объектов то и дело создаваемых и выбрасываемых в мусор. Дотнетная программа переместит 5М фоновых объектов в третье поколение и будет летать со скоростью света. А Блэкбокс вообще встанет колом, так как будет оббегать все 5'001'000 объектов каждый раз.

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

Страницы: 1 ... 36 37 [38] 39 40