Можно ли для стд::вектор'а взять адрес и-го элемента?

Допустим, есть код на Си:

Что тут происходит? __builtin_prefetch в данном случае - это встроенная конструкция языка GNU C. Но её можно написать и самому, это непринципиально. __builtin_prefetch специальными командами процессора обращается к данным в памяти, реально не читая никаких значений. Делается это для того, чтобы данные из памяти попали в кэш. В тот момент, пока идёт обработка первых 1000 элементов массива, подсистема памяти (параллельно) перекачивает данные из памяти в кэш. И когда мы начнём обработку вторых 1000 элементов, мы уже не будем терять время на чтение данных из памяти. Параллельно вызываем подкачку следующего блока и т.п. Тут всё хорошо

Теперь берём код на Си::

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

0

Сообщение от Evg Есть какая-то возможность получить адрес (но не ссылку, как это делает метод at) нужного нам элемента массива?

Оператор &. Только смысл брать этот адрес? Он ведь всё равно будет меняться.

0

Сообщение от Evg Там показано следствие работы оптимизаций, а не принципы построения ссылки.

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

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

0

Сообщение от DrOffset Это как спор физика и математика об одних и тех же процессах

Да вот что-то и мне кажется, что спор идёт на тему "жёлтый круг" vs "круг жёлтого цвета"

0

Сообщение от Evg Да вот что-то и мне кажется, что спор идёт на тему "жёлтый круг" vs "круг жёлтого цвета"

Так часто бывает. К сожалению. Я понимаю о чём Вы говорите, Evg, когда говорите, что ссылка ведёт себя так как "указатель, который всегда разименовывается". И я понимаю hoggy, когда он говорит о том, что это разные типывещи. Но я не понимаю, как это противопоставить для спора.
Можно бы подлить масла заявлением вроде: "Ссылка в С++ это хорошо обрезанныйограниченный указатель". Но смысл? Указатель полноценный тип, образующий переменную и имеющий развитый функционал. Есть 100500 вариантов использования указателей в пределах области. Ссылка (до С++11) не образует переменной, не может быть объявлена без переменной и практически нигде не может быть разумно использована в пределах области. Вся её прелесть в объявлении параметров и там она по действию похожа на указатель, но проще синтаксически. По сути, речь идёт о изменении правил при передаче и возврате значения. Это легко понять тем кто начал с таких вещей как PHP, Java или C#. Вы скажете, - найди того кто так начинает?
Я для примера, просто. Есть языки, где практически всё на ссылках и ссылки значительно развитее и там передача по ссылке это основной путь. Для того, чтобы иметь проблемы с пониманием ссылок, нужно сначала проникнуться передачей по значению, как основным способом, а потом столкнуться с передачей по ссылке. Передача по указателю, кстати, во многих источниках называется передачей по ссылке и это даёт ещё больше уверенности говорить о том, что ссылки и указатели имеют сходную семантику при передаче.
А указывать в вектор достаточно острая процедура. Нужно же быть уверенным, что не произойдёт реалок для него. По идее можно выделить память сразу и запретить реалок применяя функцию-член reserve. Evg, Вам ( и мне тоже ) по душе этот автор и ресурс:
http://alenacpp.blogspot.com/2... or_30.html

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

0

Сообщение от IGPIGP Я понимаю о чём Вы говорите, Evg, когда говорите, что ссылка ведёт себя так как "указатель, который всегда разименовывается".

Именно так она себя и ведёт. А что должна иначе? Но поищите ка в стандарте хоть одно упоминание того, что также она и реализована?

0

Сообщение от IGPIGP Нужно же быть уверенным, что не произойдёт реалок для него

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

0

Сообщение от taras atavin Именно так она себя и ведёт. А что должна иначе?

Откуда вопрос?

Сообщение от taras atavin Но поищите ка в стандарте хоть одно упоминание того, что также она и реализована

Никто не говорил о реализации.
Вообще, чтобы нормально поспорить нужно сказать, что Вы не согласны с:

Сообщение от IGPIGP Я понимаю о чём Вы говорите, Evg, когда говорите, что ссылка ведёт себя так как "указатель, который всегда разименовывается".

Потому-де, что она себя ведёт совершенно (или немного) иначе.
Вопрос возник там где оператор [] возвращает сущность - ссылку и появилось желание разобраться, а что это.
Я бы сказал (если бы у меня были мозги)), что имя переменной возвращает ссылку. Объявления нового имени ссылкой, даёт возможность получить эту ссылку по этому новому имени. Это и есть решающий довод в пользу того, что ссылка уже должна существовать до объявления. Хотя могло быть и по другому. Указатель например, можно объявить и инициализировать в 2 этапа, а у ссылки такой возможности нет и это определило многие "фичи".
У индексного выражения a[] доступа к элементу массива/vector'а вызывающего оператор [] нет имени, но есть все его свойства и в левой и в правой части и следовательно оно возвращает ссылку.

0

Сообщение от IGPIGP Это и есть решающий довод в пользу того, что ссылка уже должна существовать до объявления.

Кобыла нервно курит.

0

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

Точно! Разница в том, что когда Вам понадобится realoc то Вы его и сделаете. Это ручная операция и ей хватает остроты и без того, что можно забыть про указатели направленные внутрь. Тут хорошая память нужна по определению иначе Бум! В случае с вектором немного иначе. Это умная зверюга и назначив ему кусок reserve, трогать уже нельзя, - цапнуть может.
Ну то есть на интервале, где пользуемся прямыми адресами не допускаем операций которые поднимут его на реалок. Правильно я понимаю? А поскольку вектор делает это сам, то память нужна, особенно, хорошая.
Не серчайте за дикие речи, но пишу как сочиняется. На ходу.

Добавлено через 2 минуты

Сообщение от taras atavin Кобыла нервно курит.

Завидую, - бросил уже полтора месяца как. 15 числа позапрошлого началось. Первые дни было желание всех поубивать. Со временем стало полегче. Но желание не прошло.

0

Сообщение от IGPIGP Завидую, - бросил уже полтора месяца как.

Завидовать сивой лошади?! Ну и ну.

0

Сообщение от IGPIGP В случае с вектором немного иначе

Опять-таки, практики у меня нет, но вроде бы если ты сделаешь "vector<int> a(1000)" и больше размер трогать не будешь (и, соответственно, не пользоваться всякими динамическими операциями типа "вставить"), то сия конструкция будет эквивалентна статическому массиву. Либо просто выделаешь фрагмент программы, в котором не используешь никакие динамические конструкции, а потому в этом участке можно нормально работать с адресами

0

Сообщение от IGPIGP Объявления нового имени ссылкой, даёт возможность получить эту ссылку по этому новому имени. Это и есть решающий довод в пользу того, что ссылка уже должна существовать до объявления.

Что тут вызвало проблему? Опасаясь неинициализированных ссылок, автор языка решил вопрос так.

Добавлено через 4 минуты

Сообщение от Evg Опять-таки, практики у меня нет

У меня её и просто нет. И это не скромность, в отличие от Вас, а чистая правда.

Сообщение от Evg если ты сделаешь "vector<int> a(1000)" и больше размер трогать не будешь (и, соответственно, не пользоваться всякими динамическими операциями типа "вставить"), то сия конструкция будет эквивалентна статическому массиву.

По идее да. То есть если с памятью и самодисциплиной нормально и всё за пределами досягаемости пользователя, то должно быть так.

0

Сообщение от Evg Опять-таки, практики у меня нет, но вроде бы если ты сделаешь "vector<int> a(1000)" и больше размер трогать не будешь (и, соответственно, не пользоваться всякими динамическими операциями типа "вставить"), то сия конструкция будет эквивалентна статическому массиву. Либо просто выделаешь фрагмент программы, в котором не используешь никакие динамические конструкции, а потому в этом участке можно нормально работать с адресами

А зачем тогда использовать std::vector? Есть ведь тот же std::array.

0

Сообщение от IGPIGP taras atavin, Вы же не сразу сказали что сивой.

Ну другим то кобылам бредить не положено.

0

Evg, вопрос не по теме, префетчинг реально дает что-нибудь? Я года 3 назад эксперементировал с ним и результат был такой - толку от него на интелах особо нет. Но в linux'е можно отключать хардварный префетчинг через командную строку и вот если его отключить, то программным префетчингом можно ускорить код до 100% (смотрел perf'ом, кол-во кэшмиссов реально в разы уменьшается). Но с включенным хардварным префетчингом (который всегда включен) уменьшения кэшмиссов я так и не добился.

0

Сообщение от Toshkarik А зачем тогда использовать std::vector?

Есть существующая программа с использованием std::vector, её надо ускорить

Сообщение от Kastaneda Evg, вопрос не по теме, префетчинг реально дает что-нибудь?

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

0

Сообщение от Evg Т.е. чтобы эффект появился на интеле нужна очень интенсивная обработка больших данных, чтобы на коротком интервале времени из памяти вынимался объём данных, больший, чем размер кэша.

Ага, так и делал, перемножал гигобоайтовые матрицы, понятно что в кэш они не влезут.

Хотя сейчас задумался, может префетчинг не правильно организовал.

0

Я решал системы тысяч по семнадцать уравнений. Много медленнее рассчётного времени.

0

0

А я на чём? На самолёте?

0