dotard

[Ilya L]

В чем разница для "delete []" и "delete" для массива, состоящего из
элементов of a plain old data type?

int *iii = new int[10];
// delete iii;
delete [] iii;

И почему для не-POD type сгенерированный gcc экзешник кидает корку
вместо того, чтобы просто не вызвать деструктор для всех элементов,
кроме первого?

Foo *fff = new Foo[10];
delete fff;
// delete [] fff;

[G]

Ilya L <do...@email.me> Wrote in message:

Чего это ты? Троллей чтоли напрячь выдумал?
--
G


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[Ilya L]

On 9/26/17 5:55 PM, Mike Shirobokov wrote:

> On 9/26/17 7:03 PM, Ilya L wrote:
>
>> В чем разница для "delete []" и "delete" для массива, состоящего из
>> элементов of a plain old data type?
>>
>> int *iii = new int[10];
>> // delete iii;
>> delete [] iii;
>

> Да ни в чем. Но делать так нельзя.

>
>> И почему для не-POD type сгенерированный gcc экзешник кидает корку
>> вместо того, чтобы просто не вызвать деструктор для всех элементов,
>> кроме первого?
>>
>> Foo *fff = new Foo[10];
>> delete fff;
>> // delete [] fff;
>

> Потому что в стандарте так написано. Что типа undefined behavior. Потому
> что никаких "массивов" в C++ нет, как их и не было в C. Потому что это
> твое дело помнить, что ты аллокировал через new[] и, соответственно,
> должен деаллокировать через delete[]. А само оно не знает. fff - это
> просто адрес в памяти, без всяких магических атрибутов.

Какого же хрена оно корку-то кидает?!

>
> Выход очнь простой - забить на всю эту доисторическую херню и никогда ей
> не пользоваться. Если ты хочешь писать на современном C++, то надо
> просто говорить
>
> std::vector<Foo> fff(10);
>
> Если динамически, то
>
> auto foo = new std::vector<Foo>(10);
> delete foo;


Да понятно это все. Оно уже все переписано along the lines
auto foo = std::unique_ptr<Foo[]>(new Foo[10]);

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

>
> Mike
>

[Const]

Mike Shirobokov <mike...@qmg.org> wrote:
> On 9/26/17 7:03 PM, Ilya L wrote:

> > В чем разница для "delete []" и "delete" для массива, состоящего из
> > элементов of a plain old data type?
> >
> > int *iii = new int[10];
> > // delete iii;
> > delete [] iii;

> Да ни в чем. Но делать так нельзя.

> > И почему для не-POD type сгенерированный gcc экзешник кидает корку
> > вместо того, чтобы просто не вызвать деструктор для всех элементов,
> > кроме первого?
> >
> > Foo *fff = new Foo[10];
> > delete fff;
> > // delete [] fff;

> Потому что в стандарте так написано. Что типа undefined behavior. Потому
> что никаких "массивов" в C++ нет, как их и не было в C. Потому что это
> твое дело помнить, что ты аллокировал через new[] и, соответственно,
> должен деаллокировать через delete[]. А само оно не знает. fff - это
> просто адрес в памяти, без всяких магических атрибутов.

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

> Выход очнь простой - забить на всю эту доисторическую херню и никогда ей
> не пользоваться. Если ты хочешь писать на современном C++, то надо
> просто говорить

> std::vector<Foo> fff(10);

> Если динамически, то

> auto foo = new std::vector<Foo>(10);
> delete foo;

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

---
Const

[Ilya L]

On 9/26/17 9:12 PM, Ilya L wrote:
> On 9/26/17 5:55 PM, Mike Shirobokov wrote:
>
>> On 9/26/17 7:03 PM, Ilya L wrote:
>>
>>> В чем разница для "delete []" и "delete" для массива, состоящего из
>>> элементов of a plain old data type?
>>>
>>> int *iii = new int[10];
>>> // delete iii;
>>> delete [] iii;
>>
>> Да ни в чем. Но делать так нельзя.
>>
>>> И почему для не-POD type сгенерированный gcc экзешник кидает корку
>>> вместо того, чтобы просто не вызвать деструктор для всех элементов,
>>> кроме первого?
>>>
>>> Foo *fff = new Foo[10];
>>> delete fff;
>>> // delete [] fff;
>>
>> Потому что в стандарте так написано. Что типа undefined behavior. Потому
>> что никаких "массивов" в C++ нет, как их и не было в C. Потому что это
>> твое дело помнить, что ты аллокировал через new[] и, соответственно,
>> должен деаллокировать через delete[]. А само оно не знает. fff - это
>> просто адрес в памяти, без всяких магических атрибутов.
>
> Какого же хрена оно корку-то кидает?!
>

Кароче, язык Тургенева, Толстого, Добролюбова, Чернышевского — велик и
могуч.

"delete fff" вызывает стантартный free. Который ожидает перед адресом,
на который указывает fff, структуру из двух size_t:

https://code.woboq.org/userspace/glibc/malloc/malloc.c.html#3107

3107 p = mem2chunk (mem);
3108
3109 if (chunk_is_mmapped (p)) /* release
mmapped memory. */

...

3123 munmap_chunk (p);
3124 return;
3125 }


"delete [] fff" же ожидает перед fff совсем другую структуру. В которой
лежит количество элементов в fff, чтобы по ним пройти циклом и позвать
Foo::~Foo.

[Const]

Ilya L <do...@email.me> wrote:
> On 9/26/17 9:12 PM, Ilya L wrote:
> > On 9/26/17 5:55 PM, Mike Shirobokov wrote:
> >
> >> On 9/26/17 7:03 PM, Ilya L wrote:
> >>
> >>> В чем разница для "delete []" и "delete" для массива, состоящего из
> >>> элементов of a plain old data type?
> >>>
> >>> int *iii = new int[10];
> >>> // delete iii;
> >>> delete [] iii;
> >>
> >> Да ни в чем. Но делать так нельзя.
> >>
> >>> И почему для не-POD type сгенерированный gcc экзешник кидает корку
> >>> вместо того, чтобы просто не вызвать деструктор для всех элементов,
> >>> кроме первого?
> >>>
> >>> Foo *fff = new Foo[10];
> >>> delete fff;
> >>> // delete [] fff;
> >>
> >> Потому что в стандарте так написано. Что типа undefined behavior. Потому
> >> что никаких "массивов" в C++ нет, как их и не было в C. Потому что это
> >> твое дело помнить, что ты аллокировал через new[] и, соответственно,
> >> должен деаллокировать через delete[]. А само оно не знает. fff - это
> >> просто адрес в памяти, без всяких магических атрибутов.
> >
> > Какого же хрена оно корку-то кидает?!
> >

> Кароче, язык Тургенева, Толстого, Добролюбова, Чернышевского ? велик и

> могуч.

> "delete fff" вызывает стантартный free. Который ожидает перед адресом,
> на который указывает fff, структуру из двух size_t:

> https://code.woboq.org/userspace/glibc/malloc/malloc.c.html#3107

> 3107 p = mem2chunk (mem);
> 3108
> 3109 if (chunk_is_mmapped (p)) /* release
> mmapped memory. */

> ...

> 3123 munmap_chunk (p);
> 3124 return;
> 3125 }


> "delete [] fff" же ожидает перед fff совсем другую структуру. В которой
> лежит количество элементов в fff, чтобы по ним пройти циклом и позвать
> Foo::~Foo.

И знать это - ну прямо никак, ну совершенно не входит в обязанности
компилятора.
Особенно учитывая то невероятное количество говна, которое
знает (вынужден знать) C++-компилятор.

---
Const

[Ilya L]

Что же он может знать, если и то и другое это Foo *?

void deleteFoo(Foo *p)
{
delete p;
}

Foo * pfoo = new Foo();
Foo * pfoos = new Foo[10];

deleteFoo(pfoo);
deleteFoo(pfoos);

ilya

[ALich]

Хех..
Вдруг осознал, что ЦПП использую только понемногу для домашне-личного дроча, уже лет 10 как.
А по работе уже давно старинный Ц, и голова не болит.

А

[Const]

Я бы согласился.

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

---
Const

[Const]

Ilya L <do...@email.me> wrote:
> >> на который указывает fff, структуру из двух size_t:
> >
> >> https://code.woboq.org/userspace/glibc/malloc/malloc.c.html#3107
> >
> >> 3107 p = mem2chunk (mem);
> >> 3108
> >> 3109 if (chunk_is_mmapped (p)) /* release
> >> mmapped memory. */
> >
> >> ...
> >
> >> 3123 munmap_chunk (p);
> >> 3124 return;
> >> 3125 }
> >
> >
> >> "delete [] fff" же ожидает перед fff совсем другую структуру. В которой
> >> лежит количество элементов в fff, чтобы по ним пройти циклом и позвать
> >> Foo::~Foo.
> >
> > И знать это - ну прямо никак, ну совершенно не входит в обязанности
> > компилятора.
> > Особенно учитывая то невероятное количество говна, которое
> > знает (вынужден знать) C++-компилятор.

> Что же он может знать, если и то и другое это Foo *?

Я, конечно, извиняюсь, но если и то, и другое - это Foo *,
то у них там по этому адресу должно сидеть одно и то же.
Что должен обеспечивать кто ?
Ну неужели компилятор ?

> void deleteFoo(Foo *p)
> {
> delete p;
> }

> Foo * pfoo = new Foo();
> Foo * pfoos = new Foo[10];

Шо, вот прямо никакой разницы в синтаксисе нет ?
Вот прямо невозможно никак заметить, что это разные вещи ?

Если семантически они одинаковы, то какого хера оно имплементируется
внутри по-разному ?

Если же тупая скотина не видит разницы, то как именно
она решает, что второе надо аллоцировать по-другому ?

> deleteFoo(pfoo);
> deleteFoo(pfoos);

И ты вот серьезно тут говоришь, что это не проблема языка/компилятора ?
Причем на самом деле скорее компилятора.

Как это выразился Вулах, факинг дотардс.

---
Const

[Const]

Mike Shirobokov <mike...@qmg.org> wrote:
> >> auto foo = new std::vector<Foo>(10);
> >> delete foo;
> >
> > Ни одна из этих конструкций не являтся ни лучшей, ни понятной, ни удобной.
> > Приблизительно точно такое же говно.

> Для тех, кто в сабже, есть shell.

Для массивов-то ?
Спасибо, я уж лучше тогда с std.

---
Const

[Yury Mukharsky]

А вот так - из общего интересу - насколько все это стд оптимизировано. Ну
там векторизация хоть используется? Можно ли его в сомнительных сутуациях
заставить векторизировать?

Юра

[ALich]

Const пишет:

Coding rules при программировании мелких девайсов в автомобильных safety-relevant системах это просто пиздец, да. Пакет правил MISRA это вообще ночной кошмар, доходящий до паранойи.

Один из факторов - динамическое распределение памяти запрещено, и как следстсвие, никаких ЦПП фокусов.

Насчёт размеров проектов - конечно, с сегодняшними писюковыми не сравнить. Но сегодняшние размеры и сложность embedded систем уже поражают. Я бы сказал, что на порядок превышают тот софт который существовал для ДОС на излёте его существования.

А

[Ilya L]

Честно говоря, меня не торкают дискуссии о языках и компиляторах. Или о
std::vector vs. C-array. Я временно в саппорте работаю, мне горящий
аккаунт надо спасать.

ilya

[Const]

Ilya L <do...@email.me> wrote:
> >> deleteFoo(pfoos);
> >
> > И ты вот серьезно тут говоришь, что это не проблема языка/компилятора ?
> > Причем на самом деле скорее компилятора.
> >
> > Как это выразился Вулах, факинг дотардс.

> Честно говоря, меня не торкают дискуссии о языках и компиляторах. Или о
> std::vector vs. C-array. Я временно в саппорте работаю, мне горящий
> аккаунт надо спасать.

Ух ты.
Может вообще в sales скоро запромоутишься.

---
Const

[somnambulic]

разумный вопрос. вектор это массив плоских массивов. каждый кусок
вектора соответственно легко векторизуется.

[Yury Mukharsky]

В смысле - матрица - это массив плоских массивов? Но вопрос не в
возможности, а в наличии.

Юра

[somnambulic]

vector<> сделан унутре как список плоских массивов. умеет ли g++
конвертировать цикл через итератор => вложенный цикл и векторизовать
внутренний? может если верить гуглу. я сам не пробовал, тупо использовал
плоский массив если надо СИМД.

[Unknown]

somnambulic <somna...@yahoo.com> Wrote in message:

> On 9/29/17 1:45 PM, Yury Mukharsky wrote:
>> On Fri, 29 Sep 2017 12:23:30 -0700, somnambulic wrote:
>>
>>> On 9/28/17, 1:50 AM, Yury Mukharsky wrote:
>>>> On Thu, 28 Sep 2017 06:08:25 +0000 (UTC), Const wrote:
>>>>
>>>>> Mike Shirobokov <mike...@qmg.org> wrote:
>>>>>>>> auto foo = new std::vector<Foo>(10);
>>>>>>>> delete foo;
>>>>>>>
>>>>>>> Ни одна из этих конструкций не являтся ни лучшей, ни понятной, ни удобной.
>>>>>>> Приблизительно точно такое же говно.
>>>>>
>>>>>> Для тех, кто в сабже, есть shell.
>>>>>
>>>>> Для массивов-то ?
>>>>> Спасибо, я уж лучше тогда с std.
>>>>
>>>> А вот так - из общего интересу - насколько все это стд оптимизировано. Ну
>>>> там векторизация хоть используется? Можно ли его в сомнительных сутуациях
>>>> заставить векторизировать?
>>>>
>>>
>>> разумный вопрос. вектор это массив плоских массивов. каждый кусок
>>> вектора соответственно легко векторизуется.
>>
>> В смысле - матрица - это массив плоских массивов? Но вопрос не в
>> возможности, а в наличии.

> vector<> сделан унутре как список плоских массивов.

Разве? Ведь он гарантирует непрерывность памяти.


--
Андрей Зубань

[somnambulic]

откуда такое умозаключение? может ты не понимаешь что делает iter++?

[Ilya L]

http://en.cppreference.com/w/cpp/container/vector/data

Returns pointer to the underlying array serving as element storage. The
pointer is such that range [data(); data() + size()) is always a valid
range, even if the container is empty (data() is not dereferenceable in
that case).


Ты с std::string, наверное, спутал.

[Ilya L]

On 9/29/17 6:47 PM, Mike Shirobokov wrote:

> On 9/29/17 6:01 PM, somnambulic wrote:
>
>> vector<> сделан унутре как список плоских массивов.
>

> Бред сивой кобылы. std::vector - это один сплошной кусок памяти.


vector<vector<int> > ;-)

Same a
> C-array. Сгерененный код для C-style pointers/indexes и std::vector
> iterators/operator[] не отличается ничем. Вообще. Именно поэтому
> C-arrays и не надо пользоваться. Никогда.
>
> Отвечая на оригинальный повпрос: в std никакой векторизации нет, потому
> что она есть уровнем ниже - в компиляторе. Какая - зависит от
> компиляторя. В intel получше, в gcc похуже, но есть везде.
>
> Вот тут можно поиграться (пример не мой, подобрал чей-то первый
> попавшийся): https://godbolt.org/g/6bA283
>
> Mike
>

[somnambulic]

Holy smokes:

"Indeed, although the C++ Standard does not explicitly require that the
elements of a vector occupy contiguous memory, the standards committee
decided in its October, 2000 meeting that this requirement was missing
due to an oversight, and voted to include the requirement as part of its
Technical Corrigendum."

So if your underlying array has 1000000 elements, all used, and you do
one push_back, it needs to allocate larger chunk then copy all 10000000
elements. Not to mention push to front.

[Ilya L]

Поэтому никто не делает push to front, все пользуют push_back:
Insertion or removal of elements at the end - amortized constant O(1).

Аллокатор, естественно, не по одному элементу добавляет, когда capacity
кончается.

ilya

[somnambulic]

прям никто?

> Insertion or removal of elements at the end - amortized constant O(1).

нахрена все это нужно? оно даже амортизированное в разы хуже. есть
спайки, фрагментация, вектора объектов и куча другого геморроя. почему
не paged array? this is seriously fucked up.

>
> Аллокатор, естественно, не по одному элементу добавляет, когда capacity
> кончается.
>

hello cap.

[Const]

somnambulic <somna...@yahoo.com> wrote:
> > that case).
> > Ты с std::string, наверное, спутал.

> Holy smokes:

> "Indeed, although the C++ Standard does not explicitly require that the
> elements of a vector occupy contiguous memory, the standards committee
> decided in its October, 2000 meeting that this requirement was missing
> due to an oversight, and voted to include the requirement as part of its
> Technical Corrigendum."

То же мне, писатель компайлеров.

> So if your underlying array has 1000000 elements, all used, and you do
> one push_back, it needs to allocate larger chunk then copy all 10000000
> elements. Not to mention push to front.

here is your std:: for you.

Нету, говорите, причин, использовать простые С-массивы.

Впрочем, такова любая вещь, которой заведует комитет.

---
Const

[Konstantin Topanov]

Там для этого вот такое есть:
http://en.cppreference.com/w/cpp/container/deque
"std::deque (double-ended queue) is an indexed sequence container that
allows fast insertion and deletion at both its beginning and its end. In
addition, insertion and deletion at either end of a deque never
invalidates pointers or references to the rest of the elements.
As opposed to std::vector, the elements of a deque are not stored
contiguously: typical implementations use a sequence of individually
allocated fixed-size arrays, with additional bookkeeping, which means
indexed access to deque must perform two pointer dereferences, compared
to vector's indexed access which performs only one.
The storage of a deque is automatically expanded and contracted as
needed. Expansion of a deque is cheaper than the expansion of a
std::vector because it does not involve copying of the existing elements
to a new memory location. On the other hand, deques typically have large
minimal memory cost; a deque holding just one element has to allocate
its full internal array (e.g. 8 times the object size on 64-bit
libstdc++; 16 times the object size or 4096 bytes, whichever is larger,
on 64-bit libc++).
The complexity (efficiency) of common operations on deques is as follows:
Random access - constant O(1)
Insertion or removal of elements at the end or beginning - constant O(1)
Insertion or removal of elements - linear O(n)" ~

>> Аллокатор, естественно, не по одному элементу добавляет, когда
>> capacity кончается.
>>
>
> hello cap.

--
Konstantin

[somnambulic]

прекрасный выбор - либо очень плохо с добавлением в конец или очень
плохо с простым доступом. это согласно cppreference typical
implementation, который говорит что deque сделан двойным списком. нет
требования непрерывности значит можно организовывать как угодно, уже
легче. определено deque тоже убого. что это за push_front которое все
нахрен сдвигает по индексу. должно после 0-го добавлять минус 1-й, минус
2-й и т.д. либо вж push_pop_front, just use insert like everybody else.

[Ilya L]

Это ж блин все общеизвестные вещи, с молоком матери впитанные. В C11
есть еще fixed-size std::array.

Paged array это ArrayList из C#.

[somnambulic]

On 9/30/17 12:51 AM, Ilya L wrote:
> Это ж блин все общеизвестные вещи, с молоком матери впитанные. В C11
> есть еще fixed-size std::array.
>

молодые вы с матерью. в 89м не только std в помине не было, степанов
только начинал stl писать. если у тебя в молоке этого не было, stl это
из чего сделали std.

народ начал отключать bounds checking в критических местах взятием
пойнтера на первый элемент и потом пойнтер++. а потом народу захотелось
чтобы стандарт не говорил "behavior of such programs is undefined".

> Paged array это ArrayList из C#.

разницу между реализацией и интерфейсом знаешь?

[Unknown]

С Новым годом!


--
Андрей Зубань

[999Vulcan]

On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
> С Новым годом!

спасибо, вам тоже хорошей записи

[Unknown]

999Vulcan <z...@vulakh.us> Wrote in message:

> On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
>> С Новым годом!

> спасибо, вам тоже хорошей записи

А гарантируется, что она будет непрерывной?


--
Андрей Зубань

[999Vulcan]

абсолютно никаких гарантий

Tell me, if you understand who marked off its dimensions (Job 38:4-5)

[Unknown]

999Vulcan <z...@vulakh.us> Wrote in message:
> On Saturday, September 30, 2017 at 4:02:44 PM UTC-4, nor...@googlegroups.com wrote:
>> 999Vulcan <z...@vulakh.us> Wrote in message:
>> > On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
>> >> С Новым годом!
>>
>> > спасибо, вам тоже хорошей записи
>>
>> А гарантируется, что она будет непрерывной?

> абсолютно никаких гарантий
>
> Tell me, if you understand who marked off its dimensions (Job 38:4-5)

Лем об этом пишет.


--
Андрей Зубань

[999Vulcan]

On Saturday, September 30, 2017 at 7:08:21 PM UTC-4, nor...@googlegroups.com wrote:
> 999Vulcan <z...@vulakh.us> Wrote in message:
> > On Saturday, September 30, 2017 at 4:02:44 PM UTC-4, nor...@googlegroups.com wrote:
> >> 999Vulcan <z...@vulakh.us> Wrote in message:
> >> > On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
> >> >> С Новым годом!
> >>
> >> > спасибо, вам тоже хорошей записи
> >>
> >> А гарантируется, что она будет непрерывной?
>
> > абсолютно никаких гарантий
> >
> > Tell me, if you understand who marked off its dimensions (Job 38:4-5)
>
> Лем об этом пишет.

об отсутствии гарантий?
об этом ещё Екклезиаст писал

[Unknown]

999Vulcan <z...@vulakh.us> Wrote in message:
> On Saturday, September 30, 2017 at 7:08:21 PM UTC-4, nor...@googlegroups.com wrote:
>> 999Vulcan <z...@vulakh.us> Wrote in message:
>> > On Saturday, September 30, 2017 at 4:02:44 PM UTC-4, nor...@googlegroups.com wrote:
>> >> 999Vulcan <z...@vulakh.us> Wrote in message:
>> >> > On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
>> >> >> С Новым годом!
>> >>
>> >> > спасибо, вам тоже хорошей записи
>> >>
>> >> А гарантируется, что она будет непрерывной?
>>
>> > абсолютно никаких гарантий
>> >
>> > Tell me, if you understand who marked off its dimensions (Job 38:4-5)
>>
>> Лем об этом пишет.

> об отсутствии гарантий?
> об этом ещё Екклезиаст писал

Нет, он пишет о том, что утверждать, что Бог есть - это навязывать
модель,
т.е. ограничивать.


--
Андрей Зубань

[999Vulcan]

On Saturday, September 30, 2017 at 7:16:07 PM UTC-4, nor...@googlegroups.com wrote:
> 999Vulcan <z...@vulakh.us> Wrote in message:
> > On Saturday, September 30, 2017 at 7:08:21 PM UTC-4, nor...@googlegroups.com wrote:
> >> 999Vulcan <z...@vulakh.us> Wrote in message:
> >> > On Saturday, September 30, 2017 at 4:02:44 PM UTC-4, nor...@googlegroups.com wrote:
> >> >> 999Vulcan <z...@vulakh.us> Wrote in message:
> >> >> > On Saturday, September 30, 2017 at 3:58:07 PM UTC-4, nor...@googlegroups.com
> >> >> >> С Новым годом!
> >> >>
> >> >> > спасибо, вам тоже хорошей записи
> >> >>
> >> >> А гарантируется, что она будет непрерывной?
> >>
> >> > абсолютно никаких гарантий
> >> >
> >> > Tell me, if you understand who marked off its dimensions (Job 38:4-5)
> >>
> >> Лем об этом пишет.
>
> > об отсутствии гарантий?
> > об этом ещё Екклезиаст писал
>
> Нет, он пишет о том, что утверждать, что Бог есть - это навязывать
> модель, т.е. ограничивать.

а кто утверждает, что он есть?

[Ilya L]

On 9/30/17 10:49 AM, Mike Shirobokov wrote:

> On 9/29/17 10:02 PM, Ilya L wrote:
>
>>> Бред сивой кобылы. std::vector - это один сплошной кусок памяти.
>>
>> vector<vector<int> > ;-)
>

> Все равно сплошной кусок памяти. То же самое, что vector<int>[].
>
> Mike
>

vector<unique_ptr<vector<int> > >

[Ilya L]

On 9/30/17 10:55 AM, somnambulic wrote:
> On 9/30/17 12:51 AM, Ilya L wrote:
>> Это ж блин все общеизвестные вещи, с молоком матери впитанные. В C11
>> есть еще fixed-size std::array.
>>
>
> молодые вы с матерью. в 89м не только std в помине не было, степанов
> только начинал stl писать. если у тебя в молоке этого не было, stl это
> из чего сделали std.

Я даже tools.h++ помню, не то что STL. BTW, тут у некоторых до сих пор
email-ы на stlport.org

[somnambulic]

On 9/30/17 5:16 PM, Ilya L wrote:
> On 9/30/17 10:55 AM, somnambulic wrote:
>> On 9/30/17 12:51 AM, Ilya L wrote:
>>> Это ж блин все общеизвестные вещи, с молоком матери впитанные. В C11
>>> есть еще fixed-size std::array.
>>>
>>
>> молодые вы с матерью. в 89м не только std в помине не было, степанов
>> только начинал stl писать. если у тебя в молоке этого не было, stl это
>> из чего сделали std.
>
> Я даже tools.h++ помню, не то что STL. BTW, тут у некоторых до сих пор
> email-ы на stlport.org

lol reminds me. в спортзале на работе был 2-х метровый югослав, говорит
чета все болит, возраст сказывается. сколько тебе спрашиваю - 28 лет.
конст может его помнит, мы с ним в волейбол немного поиграли. нам типа
~40 было.

[Ilya L]

On 9/30/17 5:50 PM, Mike Shirobokov wrote:

> On 9/30/17 7:13 PM, Ilya L wrote:
>
>>>> vector<vector<int> > ;-)
>>>
>>> Все равно сплошной кусок памяти. То же самое, что vector<int>[].
>>

>> vector<unique_ptr<vector<int> > >
>
> Да какая разница чего (кроме bool) - все равно кусок. Полный аналог
> C-array, с точностью до сгенеренного кода. unique_ptr<vector<int>>[].
> std::vector<X>::iterator === X*. std::vector - это цивилизованный
> syntactic sugar вокруг указателей и malloc/realloc.

Внешний vector это массив указателей на куски.


>
> Mike
>

[Ilya L]

On 9/30/17 8:31 PM, Mike Shirobokov wrote:

> On 9/30/17 10:07 PM, Ilya L wrote:
>
>>>> vector<unique_ptr<vector<int> > >
>>>
>>> Да какая разница чего (кроме bool) - все равно кусок. Полный аналог
>>> C-array, с точностью до сгенеренного кода. unique_ptr<vector<int>>[].
>>> std::vector<X>::iterator === X*. std::vector - это цивилизованный
>>> syntactic sugar вокруг указателей и malloc/realloc.
>>
>> Внешний vector это массив указателей на куски.
>

> Естественно. Массив указателей. std::vector == C array. Я не совсем
> понимаю, что ты хочешь всем этим сказать, если честно.

Зрители хотели массив, в который можно добавлять элементы без
переаллокации всего.

[somnambulic]

On 10/1/17 1:33 AM, Mike Shirobokov wrote:

> On 9/30/17 11:07 PM, Ilya L wrote:
>
>>> Естественно. Массив указателей. std::vector == C array. Я не совсем
>>> понимаю, что ты хочешь всем этим сказать, если честно.
>>
>> Зрители хотели массив, в который можно добавлять элементы без
>> переаллокации всего >

> Я не заметил таких зрителей. Но если бы они были, то я бы их оставил без
> внимания. Я сюда зашел выступить ровно на одну тему - что при наличии
> std::vector C-style arrays не нужны вообще никогда. И, соответственно,
> new[] и delete[] не нужны никогда. Надо просто забыть про их существование.
>

для небольших heap-allocated массивов в быстром коде присобачивать
vector struct сверху и делать дополнительный heap allocation это две
больших разницы. в коде который можно было и на жаве написать можно забыть.

[Konstantin Topanov]

On 10/1/2017 3:33 AM, Mike Shirobokov wrote:

> On 9/30/17 11:07 PM, Ilya L wrote:
>
>>> Естественно. Массив указателей. std::vector == C array. Я не совсем
>>> понимаю, что ты хочешь всем этим сказать, если честно.
>>
>> Зрители хотели массив, в который можно добавлять элементы без
>> переаллокации всего.
>

> Я не заметил таких зрителей. Но если бы они были, то я бы их оставил без
> внимания. Я сюда зашел выступить ровно на одну тему - что при наличии
> std::vector C-style arrays не нужны вообще никогда. И, соответственно,
> new[] и delete[] не нужны никогда. Надо просто забыть про их существование.

Мне не приходилось, но я допускаю, что может быть полезно для constexpr
or/and embedded.

> Я за давностью лет не поручусь, но мне кажется, что я в первый раз писал
> код на c++ году эдак в 90-м или 91-м. А последние 10 лет - только на
> нем, не считая всяких скриптов на перле, шелле и питоне. И за эти вот
> 25+ лет ни разу не воспользовался new[].


--
Konstantin

[Yury Mukharsky]

On Sun, 1 Oct 2017 22:00:08 -0500, Mike Shirobokov wrote:

> On 10/1/17 1:05 PM, somnambulic wrote:
>
>> для небольших heap-allocated массивов в быстром коде присобачивать
>> vector struct сверху и делать дополнительный heap allocation это две
>> больших разницы. в коде который можно было и на жаве написать можно забыть.
>

> Это если теоретизировать. А если профайлить - то нет разницы. Если уж на
> то дело пошло, то в быстром коде никаких heap allocations обычно вообще
> нет. Все pre-allocated.

А это помогает? Не в смесле времени на, а в смысле скорости работы в
дальнейшем?

Юра

[Yury Mukharsky]

On Mon, 2 Oct 2017 09:45:47 -0500, Mike Shirobokov wrote:

> On 10/2/17 3:46 AM, Yury Mukharsky wrote:
>
>>> Это если теоретизировать. А если профайлить - то нет разницы. Если уж на
>>> то дело пошло, то в быстром коде никаких heap allocations обычно вообще
>>> нет. Все pre-allocated.
>>
>> А это помогает? Не в смесле времени на, а в смысле скорости работы в
>> дальнейшем?
>

> В каком "дальнейшем"? Я говорю про заранее выделенную и используемую
> повторно память (объекты, обычно), вместо того, чтобы ее
> аллокировать/деаллокировать в быстром коде.

В дальнешем - после выделения. Работает ли динамическая память тк же
быстро, как пре-выделенная? Казалось бы да, но вот, скажем, пцие может
качать в locked память в два раза быстрее.

> На самом деле часто помогает еще и потому, что cache friendly. В

О. Но это, наверное,слабый эффект если жручий процесс один, без
конкурентов. Или не слабый?

Юра

[Ilya L]

On 10/2/17 9:20 AM, Mike Shirobokov wrote:

> On 10/2/17 10:52 AM, Yury Mukharsky wrote:
>
>>> В каком "дальнейшем"? Я говорю про заранее выделенную и используемую
>>> повторно память (объекты, обычно), вместо того, чтобы ее
>>> аллокировать/деаллокировать в быстром коде.
>>
>> В дальнешем - после выделения. Работает ли динамическая память тк же
>> быстро, как пре-выделенная? Казалось бы да, но вот, скажем, пцие может
>> качать в locked память в два раза быстрее.
>

> Что такое "динамическая" и "превыделенная"? В смысле heap vs static data
> segment? Память - она и есть память, она вся одинаковая. Если только не
> smp+numa (нынешний интеловский smp, кстати, очень часто numa). pci-e тут
> никаким боком, если только не вовлекать в дело gpu/nic. Но, естественно,
> и gpu/nic обычно общаются напрямую с pinned memory, без участия cpu. Но
> это тут совсем не при чем.

>
>>> На самом деле часто помогает еще и потому, что cache friendly. В
>>
>> О. Но это, наверное,слабый эффект если жручий процесс один, без
>> конкурентов. Или не слабый?
>

> Может быть не слабый. Если кусок памяти сидит по одному и тому же
> физическому адресу и никуда не скачет, то с большей вероятностью он все
> время будет в кэше. Особенно хорошо, если в L2 (или даже в L1 для мелких
> кусков).
>
> Насколько "хорошо" - вот, с цифрами:
> http://www.7-cpu.com/cpu/Skylake.html

А объясни, как это интерпретировать?

Из моего опыта, легко может быть 3-4x разница во времени выполнения,
когда два разных сокета бьются за одну и ту же 64-byte cache line.

ilya

[Ilya L]

On 10/2/17 5:03 PM, Mike Shirobokov wrote:

> On 10/2/17 1:46 PM, Ilya L wrote:
>
>>> Насколько "хорошо" - вот, с цифрами:
>>> http://www.7-cpu.com/cpu/Skylake.html
>>
>> А объясни, как это интерпретировать?
>

> В смысле - "интерпретировать"? Это чисто ТТХ процессора. Иногда помогает
> быстро на пальцах прикинуть, сколько что должно занимать. Я привел
> ссылку чисто чтобы показать порядок разницы между L1/L2/L3/RAM latency.
>

Я думал, что ты имел ввиду там есть какой-то конкретный бенчмарк.

>> Из моего опыта, легко может быть 3-4x разница во времени выполнения,
>> когда два разных сокета бьются за одну и ту же 64-byte cache line.
>

> Сокета или треда на одном ядре? И почему два - кэши у нас давно 2-way, 2
> entries per index. Да собственно и threads не нужны: a[i]=b[i]+c[i] в
> одном треде может биться за один cache line. И как могут сокеты
> "биться", когда L1/L2 кэши у них каждого свои (per core, even),
> независимые? L3 у них зависимые, но синхронизированные через cache
> coherency protocol (MESIF у интела), не через память. Короче ничего не
> понятно, о какой проблеме идет речь. "Биться" они могут только при
> наличии explicit memory fences, но это к кэшам уже имеет мало отношения.
>

Мое понимание такое:

Cache coherency требует того, чтобы определенная cache line принадлежала
определенному либо core, либо socket, в зависимости от уровня кеша - L1
или L2.

И если thread1 попользовал определенный L1 cache line в core1, то для
того, чтобы thread2 попользовал ту же L1 cache line в core2, этот cache
line должен быть "передан" между core-specific L1 caches.

И, аналогично, если thread1 попользовал L2 cache line в socket1, то для
того, чтобы thread2 попользовал ту же L1 cache line в socket2, надо
"передать" L2 cache line между sockets.

Как именно L1/L2 cache line "передается" между sockets/cores, я не
уверен. Поэтому и спрашивал, как это deduce из 7-cpu. Но подозреваю, что
оно тупо идет в L3, либо в RAM.

2-way associative cache, тут, вроде, ни при чем.

> Короче, универсальный ответ на все проблемы: gcov/gprof, perf, valgrind,
> vtune amplifier. Можно сколько хорошо угодно знать теорию, но все равно
> лучше просто просто профайлить и устранять проблемы.

Ну вот когда профайлили, то и нашли проблему. Вот такую, примерно:
http://cpp-today.blogspot.com/2008/05/false-sharing-hits-again.html

ilya

[Ilya L]

On 10/2/17 9:01 PM, Mike Shirobokov wrote:

> Если thread1 _изменил_ cache line, то остальные cores это замечают
> (through bus snooping) и инвалидируют его у себя.

OK, я так и думал.

>> Как именно L1/L2 cache line "передается" между sockets/cores, я не
>> уверен. Поэтому и спрашивал, как это deduce из 7-cpu. Но подозреваю, что
>> оно тупо идет в L3, либо в RAM.
>

> Оно идет в L3 и пересылается в другие L3. L1/L2 просто инвалидируются.

Т.е. false sharing в моем примере приводит к тому, что socket2 вынужден
сделать round trip в L3 / core2 round-trip в L2? Что занимает ~10x/3x
vs. просто достать из L1, согласно http://www.7-cpu.com/cpu/Skylake.html?

> http://sabercomlogica.com/en/ebook/a-case-study-intel-nehalem-i7-coherence-in-cache/.
>

Многобукв. Спасибо, оставлю на потом.

> Ну, блин, это как бы базовые основы. Все независимое надо выравнивать
> как минимум на 64 байта. Раздел 9.4.5 в intel optimization manual. Или
> просто поискать там "false sharing".

Ну, это было неочевидно. Fucking boost.


ilya