Разве параметр конструктора initialCapacity в джавовских коллекциях не для этого предназначен?


На бейсике как бы не учат программировать. Хотя в некоторых (пост-)совковых школах его показывают.


Учитывая, что российский рынок IT — это в лучшем случае 5% мирового, то таки да, мертв. Но некрофилам это невдомек.


Только вот у FPC дела с производительностью еще хуже: Go, Haskell, CL, Ocaml, Java, C# (Mono), Scala.
Скажешь бенчмарки заточены под GC? А ты сравни FP с G++. Сильно сомневаюсь, что делфийский компилятор лучше фрипаскалевского. Впрочем все равно показательно.

@Beltar



И что, наличие компиляторов делает фортран популярным? Каковы у меня шансы найти работу, если я знаю фортран? Сколько я буду зарабатывать? Насколько интересные и разнообразные вещи я смогу реализовать на фортране? Каковы шансы найти активное сообщество? Где я могу обсудить проблемы и найти решения?



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

Дельфи есть, да. Только даже тогда как что-то второсортное.


GC -- 5-10%. В отдельном потоке. На современных компах с четырьмя ядрами потерю производительности можно округлить до нуля (четыре ядра на 100% ты не нагрузишь). Ты ну совсем не в ту сторону смотришь. Прочитай моё сообщение про плюсы. Внимательно, вдумчиво.


Прочитай моё сообщение ещё раз. Не пропуская слов и не придумывая своих.


Мы всё ещё про ААА говорим?

@LSD


И потратить неделю на его написание?


Ладно. Что GC дотнета будет рвать GC джавы в равных условиях (при одном количестве выделений) -- не уверен. Когда я говорил про то, что в дотнете он передовой, я имел в виду, что в дотнете, если возникли проблемы производительности с GC, их легче преодолеть, чем в джаве. Если есть какой-то мелкий объект, который создаётся и уничтожается миллионами, то банальной заменой class на struct можно увеличить производительность. Кроме того, сам .NET упрофилирован МСом по самое немогу, то же касается многих популярных библиотек. В джаве это недоступно. Что касается дженериков, то в джаве список целых завалит кучу, в то время как в дотнете будет один блок.

Итого: в дотнете из коробки очень много оптимизаций, которые просто работают. Если возникнет проблема -- есть пути решения. В джаве -- всё печальнее. Это даже не столько проблемы GC, сколько всего, что вокруг.

Добавлено через 4 минуты и 11 секунд
@k0rvin


Это заполнит список указателями null. Но сами объекты надо будет создавать отдельно (или боксить примитивные типы). В дотнете же при создании списка структур они все сразу создадутся одним блоком.

А, понял. А если у объекта нет конструктора-по-умолчанию? Или в C# все объекты всегда имеют такой конструктор?

Вот смотри, допустим мы делаем RTS в которой рождаются, храбро бросаются в бой и помирают Юниты.

Разделим все объекты в игре на
1) Юниты (все, что может использовать игрок).
2) Снаряды (имеют привычку попадать в юниты, в общем требуют просчета коллизий).
3) Разрушаемые объекты (танк давит деревья и т. п.)
4) Все прочие (обломки зданий, поваленные деревья с которыми нет взаимодействия и они через несколько секунд исчезают).

Для юнитов опишем структуру.

TUnit=record
  Id:Int32;
  Player:Byte;
  ...Прочие полезные свойства.
  UnitType:TUnitType;//Ссылка на класс, где описано, что за юнит, зерлинг, или "апокалипсис", какие модели юзать, в общем инфа, которую грузим из конфига при начале игры и не переопределяем.
  Status:Byte; //Юнит может быть: живым, уничтоженным (он еще не исчез, проигрывается анимация смерти, но из взаимодействия исключен), исчезнувшим (Все, моделька исчезла).
end;

Units:array of TUnit;

Теперь я объявляю при старте игры SetLength(Units,PlayersCount*256) (Для C&C-подобной игры, или крафта этого по яйца хватит, 99% добавлять не придется). Все создан пул, я инициализирую все его элементы, как исчезнувшие и выставляю номер последнего свободного элемента в 0. Далее я просто добавляю возникающие юниты на вершину, а если юнит убит и похоронен, то, он получает статус исчезнувшего. Т. е. никаких запросов на выделение памяти нет вообще, пока наш пул не заполнится. Все лежит именно там, где я хочу и никаких расходов на создание экземпляра класса нет. Ес-но от того, что юниты умирают, получаются в пуле дырки. Ну так при каждом цикле перебора кто мешает, запомнить номер первой встреченной дырки и скопировать туда первый встреченный после этого юнит? Номер дырки увеличить на 1. К концу цикла номер свободной ячейки станет равен номеру дырки. Тонкость только в том, что если один юнит содержит другой, то их надо взаимно оповещать о перемещениях. Минус, копирование структуры размерон в несколько десятков, может сотню байт, но и размер реально ипользуемой части пула под контролем и цикл перебора юнитов гоняем ровно настолько, насколько нужно. Да и доступ к полям чуть быстрее, чем если бы были классы.

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

Нет, я, конечно, понимаю, что такое писать, обычно, западло, но это проблемы с перерапределением памяти решает и будет быстрее, чем просто создать объект по ОС знает какому адресу, убить, и пусть GC там с ними возится.

Добавлено через 6 минут и 25 секунд


А для Абрыкадабры он тоже процентов 6-7, с учетом всего СНГ около 10. Delphi живет за счет России, да... Впрочем мне, как здесь живущему сферический мировой рынок абсолютно до фени, если вся Индий, например, сядет писать на Хаскеле и его доля на мировом рынке подскочит до нескольких процентов, то я этого даже не почувствую.

Нет, не быстрее. Время выделения памяти с GC зависит только от размера памяти под объект и от количества дырок не зависит никак, в отличие от твоих циклов с переборами.

Нет выделения памяти. Вообще. Ни одного конструктора. И все в одном месте сложено. Ну собственно в чем и смысл. Вряд ли при разработке RTS я очень много выиграю по сравнению с обычным созданием объектов в куче. Потому что сложность обработки многократно превышает сложность создания и перебора.

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

Добавлено через 1 минуту и 6 секунд

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

Обход пула делается в рамках игрового цикла, юниты ездят, стреляют и т. п. Дырки закрываются попутно. Новый юнит же жестко пишется на вершину пула. Как в Тетрисе, где точки, объединенные в фигуры падают сверху, однако при определенных условиях изымаются из середины.



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



Ты путаешь Паскаль и компилятор. Кстати, было такое вот измерение для Pascal.ABC http://pascalabc.net/stati-po-pascalabc-ne...roizvoditelnost

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

Кстати, делать мне нефиг, и я начал сам это перемножение матриц гонять, благо есть аж 4 Паскаля, да и VS 2008 вроде с шарпом и плюсами есть. Пока сделал на Delphi и Pascal ABC. Или я что-то неправильно конвертнул, или для ABC.NET все печально... На Core Quad 8400-2.66 (это намного слабее i5-3.3) Delphi с неоптимизированным алгоритмом за 10.9 сек управилась, ABC потребовал 37 и лишь с оптимизацией и дикой многопоточностью вышел в 8.7. Интересно, что дальше будет.

@k0rvin


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

В плюсах в этом плане круче -- конструктор по умолчанию, разумеется, можно переопределить. При создании массива вызовутся все конструкторы. Если конструктора по умолчанию нет, то массив создать будет невозможно. Также в коллекциях STL аллокаторы умеют создавать неинициализированные блоки под будущее заполнение структурами, а потом вызывают inplace new по мере добавления элементов.

@Beltar


Это круто. "Но есть нюанс" ©

Во-первых, ты сделал массив записей. Так не выйдет полиморфизма. Предлагаешь делать switch длиной в 200 пунктов по типу юнита? Предлагаешь в запись пихать все поля всех юнитов? Давай переделывай на class и нормальные полиморфные указатели. У нас ООП, а не детсад.

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


Ни черта не понял, что ты здесь расписал и зачем. Но ты вот уплотнение упомянул. Очень интересный и важный вопрос. Вот ссылается один юнит на другой через поле "СледоватьЗаЮнитом". Сможешь упаковать такой массив? Учти, таких полей -- десятки, они идут во все стороны. Также есть ссылки из других объектов, не только из юнитов.

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


Нет, вывод там был такой:


Добавлено через 2 минуты и 4 секунды
P.S. Во многих играх логику как раз пишут на более высокоуровневых, так сказать «скриптовых» языках, типа lua например. На плюсах только графический движок.

Не докажу, получается как раз наоборот. Смысл в том, что определяет больше не язык, а компилятор. Кстати, на тесте который там по ссылке вышло на моей машине у DXE3 10.9 и 6.3 сек, У FPC под Лазарусом 10 и 4.9, Pascal ABC.NET 9.8 и 3.3, Delphi Prism 9 и 3. Т. е. в MS програмеры хлеб зря не едят и компилятор с байт-кода нормально оптимизируют, но чтобы увидеть результаты должен быть подходящий алгоритм. Шарп, VС++, и билдер еще не проверял. Но в принципе ожидаемо, что шарп покажет те же результаты, что и призма, билдер будет на уровне Delphi (вряд ли там оптимизатор лучше), VC++ должен всех порвать. Delphi пора бы переводиться на LLVM-компилятор.



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

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

Для этого надо использовать аж STL? А чем обычная дельфовая SetLength от этого отличается? Зачем тут параметризация я в упор не вижу.



Я тебе позавчера кинул статью http://www.programmersclub.ru/Рабство-программистов/ Ты сказал, что автор нуб и опозорился, хотя он там наглядно показал, что наследование спокойно заменяется агрегацией. А в моем случае достаточно создать при старте игры вечные классы с описанием юнитов и каждому новому юниту выдавать ссылку на его класс. Похоже до неотличимости на соединениеме таблицы в БД со справочниками по 1-n. Соответственно имея в игре хоть 10, хоть 1000 моих любимых Missile Defender'ов (C&C Generals Zero Hour) я буду иметь всего один огроменный экземпляр класса, где этот Missile Defender описывается. Там можешь упражняться с полиморфозмом, который, я тебе сразу говорю, если не сфейлится, то не позволит описать цепочки наследования дальше 2-3 ур. Я и без наследования могу в классе написать, что если у юнита есть параметр ReturnToBaseForReload, то он расстреляв боекомплект будет в состоянии Idle двигаться к зданию приписке, switch тут не больно какой получается.



1) Я кроме серии Total War игр с тысячами юнитов одновременно, что-то ни одной не помню. При этом в TW размер отряда в тех играх серии, что я играл, можно задать, есть нормальное значение и есть максимальное (2х) ну так как оно там на максимальной численности работает, это отдельный разговор. В целом можно считать, что там в 1 vs 1 при полных армиях будет при максимальной численности порядка 60-70 юнитов на отряд, у каждого игрока 20 отрядов и того 2500-3000, которые могу только выбывать из боя.  А рекламу вида "Runs great on Intel i7", когда этот самый i7 стоил 10к+ можно было воспринимать только как издевку. Игры семейства C&C дают темп строительства юнитов от 5-20 с. на юнит с 2-3 производящих построек на игрока и пару зданий в минуту с диким темпом их уничтожения. В других играх темп похожий, иногда сквадами на 5-20 юнитов.
2) Любая система работает с определенными количественными ограничениям, если комп при 500 юнитов впадает в задумчивость, то нафига 1000? Так что выделить несколько больше памяти, чем будет использоваться в 90% случаев вполне логично. Потом можно запросить больше памяти, расширить массив тебе никто не запрещает, но это в любом случае выгоднее, чем запрашивать постоянно память по мелочи, что с куда большей вероятностью приведет к ее фрагментации.

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

Ладно, понятно, что пример, притянутый за уши. В RTS куда больше других вещей, которые надо считать. Да и разного рода объектов весьма переменного размера не учитывает, например, список сидящик в БТР пихотов, или маршрут движения. Но фактически не самыми сложными срествами получается организовать хранение данных, где выделение памяти происходит редко и только крупными блоками. Кто-то будет спорить, что подобный подход в плане производительности куда более эффективен, чем создание раз за разом черт знает где объектов, их уничтожение, а потом шмон программы по каким-то там нетривиальным алгоритмам GC?

Впрочем нет смысла говорить о дизайне "программиста" для которого качество языка определяется исключительно наличием GC.

Это сообщение отредактировал(а) Beltar - 27.4.2013, 18:24

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

Это сообщение отредактировал(а) Bother - 27.4.2013, 19:43

"аж STL" используется на каждый чих, это основная библиотека плюсов. А про аллокатор - он позволяет отдельно определять методы для аллокации и инициализации. Не знаю к чему он вообще был упомянут, для этого не нужно дополнительно переопределять поведение стандартного аллокатора. Достаточно вызвать метод reserve у vector'a, например, чтобы аллокатор выделил место в памяти, и по мере заполнения на этом месте будут создаваться объекты.