maytonФраза "никаких предположений о типах полей данных этого объекта делать не надо" - требует
пояснений или уточнений. Лучше в качестве примера.
Предположим нам нужно очень часто создавать и уничтожать объекты типов Т1, Т2 и Т3. Как можно производительнее и с памятью у нас чем — больше тем лучше, сожрем и 16Гб оперативки.

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

И так получилось, что все Т1, Т2 и Т3 имеют примерно одинаковый размер. Не больше 512 байт. Необходимо реализовать свой менеджер памяти. Безопасный в работе с типами. С вызовом конструкторов, деструкторов и с полноценным синтаксисом.




Класс Pool у нас универсальный и ничего не должен знать о типах Т1... В следующем проекте будет Т10 например. Так же желательно класс Pool параметризовать алгоритмом поиска свободной памяти и освобождения памяти.

maytonpetravМожно поступить как в Яве: отказаться от полноценного RAII и добавить сборщик мусора. Но тогда придется отказаться от производительности С++.
Ты знаешь. Я устал. Я устал доказывать что производительность зачастую лежит не там
и ее ищут не так. Из моего личного опыта проблемы производительности энтерпрайза
лежали в
1) I/O
2) Network/Http/Rest/Soap
3) Доступ к БД/Оптимизатор запросов
4) Блокировки разделяемых ресурсов среды.
5) Неверный алгоритм или последовательность шагов. Ошибки project-owner или аналитика при описании задачи.
Производительность собственно бинарного кода очень редко оказывает сильное влияние.
Ну или у меня подобных задач было мало. А когда проблема действительно находилась
и после анализа профайлером удалялась - на верх снова поднимались проблемы (1),(2),...e.t.c.
Елки палки!!!

Так мы и НЕ ГОВОРИМ про энтерпайз! У нас ДРУГАЯ тема разговоров! А так с твоими словами согласен.

Прошу прощения не "500 количество памяти под зарезервированные объекты", 500 - количество объектов для которых нужно память резервировать.

White OwlТебя слишком легко поймать.
Ну у тебя, кроме «ты дурак», пока ничего не получилось в плане «поймать». :) Свои посты-то перечитай...

Кроме того, я и бегать ни от кого не хочу. Это твои желания ловить кого-то.

Изопропилpetravпропущено...

Такой:




а кто будет следить за объектами, с временем жизни несколько дольше, чем вызов функции, создавшей объект?
Обычно всё начинается с 1-10 объектов созданных в main() (или глобальные, что хуже), а уж они через указатели (shared_ptr) и контролируют по цепочке всё остальное. Точнее не по цепочке, а в виде дерева размещенных в ОЗУ объектов. Если сеть, то weak_ptr.

maytonpetrav,




(покачиваясь на стуле)

Не знаю.... Не нравится мне эта постановка. Я-бы со старта выделил 3 пустых коллекции для T1, T2, T3
и использовал их по мере роста.
Коллекция? std::set? Ну тут совсем не подходит. В коллекцию мы кладем значения, проверяем что они там есть, удаляем. Ну... не знаю как объяснить. Ведь у коллекции и динамического вектора ведь разное назначение? Я уж не говорю про какое-нибудь бинарное дерево поиска.

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

maytonПетрав несёт свой тезис. Просто он его никак не может озвучить.
С ним всё время мы сворачиваем на какую-то узкую самолётную предметную область где нужно
считать наносекунды на malloc и кодить алгоритмы только на определённых языках.
Я с этим не согласен. И жду конкретики.
Проблема нашего взаимопонимания кроется в том, что ты рассуждаешь исключительно как разработчик энтерпрайз решений. Ты мыслишь в терминах оптимизатора запросов, нормализации БД, денормализации БД, пулов коннкекшинов и потоков, создания API к своим веб-приложениям, вопросов кластеризации и прочего маштабирования. Т.е. ты думаешь исключительно как high level enterprise разработчик.

В доказательство твоя цитата: «Я устал доказывать что производительность зачастую лежит не там и ее ищут не так. Из моего личного опыта проблемы производительности энтерпрайза лежали в». Ну так и я устал.

Причем ты не разработчик базовых решений — не разработчик СУБД (SQL, MongoDB, например), не разрабатываешь ОС или Web-сервера (IIS, Apache). Ты даже отрицаешь алгоритмы сортировки — конечно, обычно это для тебя делает сервер БД — достаточно грамотно спроектировать структуру БД. А ведь подавляющее число этих технологий (ОС, СУБД, Веб-серверы, компиляторы, веб-браузеры и т.д.) написаны на С/С++ и их разработчики сталкиваются с проблемами, которые ты считаешь не нужными (тебе => и всем остальным).

Всё остальное ты отрицаешь как не нужное (или очень узкое). А именно:

- Высокопроизводительные расчеты (наука и техника — моделирование).
- Реальное время (авиация, автомобилестроение, станкостроение, космос).
- Ограниченные вычислительные ресурсы (встраиваемые системы, приборостроение).
- ОС, драйвера, СУБД, веб-сервера, веб-браузеры.

Какую конкретику ты хочешь? Вот я тебе ставлю задачу описать и разработать наш класс Pool<>, но с максимальной производительностью. Ответ: производительность не нужна, напишу на встроенных в Яву коллекциях. Я тебе предлагаю напиши на Яве union. Ты мне: мне API не хватает. Ну так хотя бы опиши на Яве парадигму RAII. Ответ: Денису Ричи было не нужно и мне не нужно.

Ну скачай исходники MySQL, посмотри алгоритмы обслуживания индексов — там 100% прямое манипулирование памятью. Опиши на Яве, Реализуй на Яве, сравни производительность. Реализуй на Яве разряженные матрицы и операции с ними. Сравни с производительностью Boost.uBLAST. И ты поймешь, что не то что реализовывать на Яве было не нужно, а даже и описывать. :)

PS: Сказать подробно чем я занимаюсь на работе — я не могу. В России есть заводы где даже сотовые телефоны на проходной сдают.

ИзопропилpetravСказать подробно чем я занимаюсь на работе — я не могу
был бы на улице 1979 год - поверил бы
А почему 79-й, а не 37-й? Я ж не про шарашки рассказывал.

Или ты родился в 79-м и веришь только про этот год?

ИзопропилpetravА почему 79-й, а не 37-й? Я ж не про шарашки рассказывал.
тогда откуда столько секретности?
В нашей стране куча режимных предприятий. Просто сам факт работы на нём скрывать глупо — все ж через проходную входят и выходят каждый день. От меня требуют конкретики, ну не могу я что-то абстрактное про ракетостроение рассказать, например. Потому что не знаю. И не имею к нему отношение.

ИзопропилpetravСказать подробно чем я занимаюсь на работе — я не могу.
а подробно не надо

веб-серверы пишешь?
Нет. Авиационная промышленность. Ничего исключительного или даже особо секретного.