[ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 08.02.13 17:45
Оценка: 6 (1)
CCore 1.03 is released.

tags
wiki

Этот релиз -- инкрементальный апгрейд.
Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re: [ANN] CCore 1.03
От: UA Украина  
Дата: 08.02.13 20:19
Оценка: +1
Здравствуйте, Шахтер, Вы писали:
Ш>Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.

Традиционные возможно и помедленнее но вникать в чужие велосипеды и ловить баги в итоге дороже выйдет.
Re[2]: [ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 09.02.13 08:15
Оценка:
Здравствуйте, UA, Вы писали:

UA>Здравствуйте, Шахтер, Вы писали:

Ш>>Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.

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


Вникай в традиционную инвалидную каляску.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re: [ANN] CCore 1.03
От: trophim Россия  
Дата: 09.02.13 09:02
Оценка: +2
Бустовские неинтрузивные контейнеры по производительности хуже?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Let it be! — Давайте есть пчелу!
Re[2]: [ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 10.02.13 07:46
Оценка: -1 :))) :)))
Здравствуйте, trophim, Вы писали:

T>Бустовские неинтрузивные контейнеры по производительности хуже?


Понятия не имею.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[3]: [ANN] CCore 1.03
От: Ops Россия  
Дата: 10.02.13 16:13
Оценка: +1
Здравствуйте, Шахтер, Вы писали:

Ш>Вникай в традиционную инвалидную каляску.


Традиционная инвалидная коляска удобнее нетрадиционных костылей.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: [ANN] CCore 1.03
От: trophim Россия  
Дата: 11.02.13 19:55
Оценка: +1
Не сравнивали потому то не знали об их существовании или свой вариант разработали в "добустовскую" эпоху? Или еще какие причины?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Let it be! — Давайте есть пчелу!
Re[4]: [ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 12.02.13 20:09
Оценка: :)))
Здравствуйте, trophim, Вы писали:

T>Не сравнивали потому то не знали об их существовании или свой вариант разработали в "добустовскую" эпоху? Или еще какие причины?


Не имеет смысла.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[4]: [ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 12.02.13 20:42
Оценка:
Здравствуйте, trophim, Вы писали:

T>Не сравнивали потому то не знали об их существовании или свой вариант разработали в "добустовскую" эпоху? Или еще какие причины?


Не надо, пожалуйста, разводить здесь холивар. Про "эпоху буста" и прочее (тем более, что началась эпоха CCore ).

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

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

Вопросы типа: а чем это лучше/хуже буста (или другой библиотеки), я не принимаю -- мне не интересно этим заниматься. Но если вам интересно, можете пожертвовать своё драгоценное время и разобраться.
Только не забывайте, что подобное надо сравнивать с подобным.
В CCore, например, одних массивов 5 штук, а не-интрузивных списков 9 штук, хороших и разных.
Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[5]: [ANN] CCore 1.03
От: Piko  
Дата: 12.02.13 23:10
Оценка: +1
Здравствуйте, Шахтер, Вы писали:

Ш>В CCore, например, одних массивов 5 штук, а не-интрузивных списков 9 штук, хороших и разных.

Ш>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.

навскидку — массивы:
1. CCore::AtomicRefArray/RefArray — boost::shared_array, boost::shared_ptr<...>, boost::intrusive_ptr<...> ?
2. CCore::SimpleArray — boost::scoped_array ?
3. CCore::DynArray — boost::container::vector?
4.

Collector is not an array! The purpose of this container is to be an efficient collector of elements. This container stores a sequence of elements in a list of arrays. So appending and extending operations are the most efficient. At desired moment you can copy or move this sequence into true array. Or you can "flat" the Collector itself.

boost::container::deque?
5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.
6. ??? — boost::container::stable_vector
7. ??? — boost::ptr_vector

А вообще вопрос то был про производительность, которая по заявлению:

значительно более быстрые, чем традиционные.

Если же ты говоришь что

Ш>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.


Зачем говорить что более быстрые?
Re[6]: [ANN] CCore 1.03
От: jazzer Россия Skype: enerjazzer
Дата: 13.02.13 00:05
Оценка: :)
Здравствуйте, Piko, Вы писали:

P>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.

std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: [ANN] CCore 1.03
От: Piko  
Дата: 13.02.13 08:10
Оценка:
Здравствуйте, jazzer, Вы писали:

P>>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.

J>std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.

Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт.
И куда тут string'и лепить?
Re[8]: [ANN] CCore 1.03
От: jazzer Россия Skype: enerjazzer
Дата: 13.02.13 09:21
Оценка:
Здравствуйте, Piko, Вы писали:

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


P>>>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.

J>>std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.

P>Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт.

P>И куда тут string'и лепить?

В смысле? Вот в STLport std::string представляет собой статический массив на 16 элементов плюс динамический на сколько угодно.
Т.е. делаешь std::string< My16ByteType > — и получаешь то, что надо, не? Если я правильно понял, что такое TempArray, конечно.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: [ANN] CCore 1.03
От: Piko  
Дата: 13.02.13 10:14
Оценка:
Здравствуйте, jazzer, Вы писали:

P>>Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт.

P>>И куда тут string'и лепить?
J>В смысле? Вот в STLport std::string представляет собой статический массив на 16 элементов плюс динамический на сколько угодно.

ну пусть будет в среднем не 16, а 8 или 32.

J>Т.е. делаешь std::string< My16ByteType > — и получаешь то, что надо, не? Если я правильно понял, что такое TempArray, конечно.


На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места.
В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом.
Re[10]: [ANN] CCore 1.03
От: jazzer Россия Skype: enerjazzer
Дата: 13.02.13 11:15
Оценка:
Здравствуйте, Piko, Вы писали:

P>На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места.


ХЗ, из доки это непонятно. В STLport размер SSO прибит гвоздями. Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.

P>В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом.


Ну так я ж сразу сказал, что в некоторых реализациях, а не во всех.

PS Мы тоже для этой цели свой лисапед используем.
PPS Он предлагался в буст под именем AutoBuffer
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: [ANN] CCore 1.03
От: Piko  
Дата: 13.02.13 12:16
Оценка:
Здравствуйте, jazzer, Вы писали:

P>>На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места.

J>ХЗ, из доки это непонятно. В STLport размер SSO прибит гвоздями.

тут:
template <class T,ulen StackLen>
class TempArray : NoCopy
...


J>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.


для строк важна совместимость, для TempArray-like — производительность.

P>>В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом.

J>Ну так я ж сразу сказал, что в некоторых реализациях, а не во всех.

ну да — поэтому лучше свой лисапед на несколько сот строк и тесты.

J>PS Мы тоже для этой цели свой лисапед используем.


аналогично

J>PPS Он предлагался в буст под именем AutoBuffer


Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему
Re[12]: [ANN] CCore 1.03
От: jazzer Россия Skype: enerjazzer
Дата: 13.02.13 16:42
Оценка:
Здравствуйте, Piko, Вы писали:

J>>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.


P>для строк важна совместимость, для TempArray-like — производительность.

производительность одинаковая, разница только в гибкости

J>>PPS Он предлагался в буст под именем AutoBuffer


P>Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему


вот прямо сейчас обсуждается, уже под именем varray и hybrid_vector:
http://thread.gmane.org/gmane.comp.lib.boost.devel/238631
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: [ANN] CCore 1.03
От: Piko  
Дата: 13.02.13 16:48
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.

P>>для строк важна совместимость, для TempArray-like — производительность.
J>производительность одинаковая, разница только в гибкости

Это как, одинаковая? если мы размер "local"-size задаём параметром — то в каждом отдельном случае мы можем задавать такое значение, при котором в большинстве случаев это будет local, и при этом не будет большого непроизводственного перерасхода.
Иногда это 8, иногда 24, а иногда и все 64 элемента. Если такого параметра нет, и всё прибито гвоздями, то будет больше косвенности — будет медленней.

J>>>PPS Он предлагался в буст под именем AutoBuffer

P>>Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему
J>вот прямо сейчас обсуждается, уже под именем varray и hybrid_vector:
J>http://thread.gmane.org/gmane.comp.lib.boost.devel/238631

да, я видел этот топик, ещё не читал о чём он.
Re[6]: [ANN] CCore 1.03
От: Шахтер Интернет  
Дата: 13.02.13 17:52
Оценка:
Здравствуйте, Piko, Вы писали:

P>А вообще вопрос то был про производительность, которая по заявлению:

P>

P>значительно более быстрые, чем традиционные.

P>Если же ты говоришь что

Ш>>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.


P>Зачем говорить что более быстрые?


Затем, что более быстрые.

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

Есть традиционные списки. Например, в CCore таким будет LinearDList2. В традиционных списках при добавлении нового элемента аллокируется память из кучи, а при удалении
память возвращается обратно. Это довольно накладно. Для борьбы с этим есть несколько подходов. В "компактных" вариантах (CompactList2), память под ноды аллокируется блоками.
Это позволяет аммортизировать затраты на аллокацию памяти. Чтобы избежать резервирования черезмерного количества памяти, в "компактном" списке при удалении узла,
на его место перемещается другой узел. Это позволяет поддерживать количество дополнительной памяти в фиксированных пределах. Недостаток такого подхода -- перемещение узлов
при удалении. В STL требованиях на список это запрещено, поэтому в STL списках подобная техника использована быть не может.

Что касается традиционных списков -- то их быстродействие во всех разумных реализациях из любых библиотек будет одинаково. Просто потому что эти реализации
отличаются не столько внутренней механикой, сколько оформлением.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.