Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Общие вопросы > array, vector или new...[]


Автор: boriska 20.4.2007, 23:45
задание в Lippman'e

Цитата

Что лучше применить в каждой из следующих ситуаций: массив, динамический массив или вектор? Объясните свой выбор.

а)  Внутри функции Lut() нужен набор из 256 элементов для хранения объектов класса Color. Значения являются константами.
б)  Необходимо хранить набор из неизвестного числа объектов класса Account. Данные счетов читаются из файла.
в)  Функция gen_words(elem_size) должна сгенерировать и передать обработчику текста набор из elem_size строк.


Путаюсь в догадках smile . Четких критериев по которым можно было бы отдать предпочтение одному из вариантов не вижу.
Помогити, аргументируя please.

Автор: Daevaorn 20.4.2007, 23:50
Цитата(boriska @  21.4.2007,  00:45 Найти цитируемый пост)
Путаюсь в догадках  . Четких критериев по которым можно было бы отдать предпочтение одному из вариантов не вижу.Помогити, аргументируя please.

По мне, так когда ответ находишь сам, то всё же приятнее и пользы больше. Лучше прочти главу ещё раз, а если и тогда не догадаешься, то приходи - расскажем;)

Автор: boriska 21.4.2007, 00:20
предположения конечно имеются :

а) массив
    1. потому что знаем размер
    2. с набором будем работать локально

б) vector
     не известно кол-во счетов и можно использовать vector::push_back()

в) динамический массив
    1. знаем размер
    2. удобно передать указатель

но не уверен ...

Автор: Daevaorn 21.4.2007, 00:32
boriska, ты получаешь приз за правильный ответsmile возьми его на верхней полкеsmile

Автор: archimed7592 21.4.2007, 16:10
Цитата(boriska @  21.4.2007,  00:20 Найти цитируемый пост)
в) динамический массив
    1. знаем размер
    2. удобно передать указатель
а я бы вектор использовал... его не нужно уничтожать вызывающей ф-ции (в отличие от дин. массива)...

Автор: vinter 21.4.2007, 17:18
Цитата(archimed7592 @  21.4.2007,  16:10 Найти цитируемый пост)
а я бы вектор использовал... его не нужно уничтожать вызывающей ф-ции (в отличие от дин. массива)...

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

Автор: archimed7592 21.4.2007, 17:22
Цитата(vinter @  21.4.2007,  17:18 Найти цитируемый пост)
зато работает медленнее, и возможно неэффективно использует память. 
 smile слишком голословно...

Цитата(vinter @  21.4.2007,  17:18 Найти цитируемый пост)
зато работает медленнее
почему?

Цитата(vinter @  21.4.2007,  17:18 Найти цитируемый пост)
неэффективно использует память.
std::vector<myType> v (elem_size)... да и vector::reserve никто не отменял

Автор: vinter 21.4.2007, 17:30
помещение в вектор ф-ия значит уже медленнее, а также вся манипуляция идет через высокоуровненвые механизмы это опять же временные затраты.
да и если бы вектор был действительно лучшим по всем параметром, он бы давно стал заменой new\delete а этого не происходит..
Цитата

std::vector<myType> v (elem_size)... да и vector::reserve никто не отменял

дополнительные усилияsmile

Автор: apook 21.4.2007, 17:38
vector классный массив он лучше чем array В языке высокого уровня
Python массивы имеют примерно такую же природу что vector

Вернее строка там есть список,
и типов нет или есть,  smile 
скорость конечно это аргуметнт , но что уж при нынешних скоростях
этот параноидальный скоростной погоня за скорост

Автор: archimed7592 21.4.2007, 17:54
Цитата(vinter @  21.4.2007,  17:30 Найти цитируемый пост)
вся манипуляция идет через высокоуровненвые механизмы это опять же временные затраты.
конкретно, в чём затраты?
скажем так: чем по (трудо-, время-)затратам отличаются записи v[i] и a[i], если v - vector, a - массив, созданный при помощи new.

Цитата(vinter @  21.4.2007,  17:30 Найти цитируемый пост)
да и если бы вектор был действительно лучшим по всем параметром, он бы давно стал заменой new\delete а этого не происходит..
это просто удобная обёртка... тож самое, что сказать, что, "если бы streams были бла-бла-бла, то *printf/*scanf давно бы заменили"...


Цитата(vinter @  21.4.2007,  17:30 Найти цитируемый пост)
дополнительные усилияsmile 
конечно... когда используют new, размер массива не указывают - он сам догадывается...

ну и в итоге... vector и ещё раз vector!

Автор: vinter 21.4.2007, 18:07
Цитата(archimed7592 @  21.4.2007,  17:54 Найти цитируемый пост)
конечно... когда используют new, размер массива не указывают - он сам догадывается...

неа, но мы получаем что vминус new только в операции удаления, а это уже не смертельно
Цитата(archimed7592 @  21.4.2007,  17:54 Найти цитируемый пост)
скажем так: чем по (трудо-, время-)затратам отличаются записи v[i] и a[i], если v - vector, a - массив, созданный при помощи new.

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

Автор: archimed7592 21.4.2007, 18:13
Цитата(vinter @  21.4.2007,  18:07 Найти цитируемый пост)
я не знаю как реализован этот оператор, поэтому про него ниче не скажу
стандарт принуждает его работать так же... (inline ф-ций, определённых в классе + отсутствие нужды на проверки границ при использовании оператора - этим он и отличается от vector::at)...

Цитата(vinter @  21.4.2007,  18:07 Найти цитируемый пост)
а вот push будет раьотать полюбому медленнее. 
а кто заставляет использовать push, если в нём нет нужды (объём массива заранее известен)?


Цитата(vinter @  21.4.2007,  18:07 Найти цитируемый пост)
неа, но мы получаем что vминус new только в операции удаления, а это уже не смертельно
не совсем понял как это относится к дополнительным усилиям...
точнее, ты сейчас сказал, что для вектора усилий нужно меньше (не нужно напрягаться об удалении)

Автор: vinter 21.4.2007, 18:37
Код

#include <iostream>
#include <cstdlib>
#include <ctime>
#include <vector>
using std::cout;
using std::cin;
using std::endl;
using std::string;
                  

int main()
{
    clock_t start = clock();
    std::vector <int> aArray(50000000);//26432
    //int *pArray = new int[50000000];//1572
    for(int i = 0; i < 50000000; ++i)
        //*(pArray + i) = 5;
        aArray[i] = 5;
    //delete []pArray;
    cout << (clock() - start) << endl;
    cin.sync();
    cin.get();
    return EXIT_SUCCESS;
}


результат new\delete - 1572
результат вектора - 26432, думая дальнейший спор не уместен, а преимущество более чем в 10 раз, само за себя говорит. 
компилилось в VS2003, дебаг 

Автор: nickless 21.4.2007, 18:59
Хм, а у меня (gcc 4.1.2) результаты:
вектор: 3750 без оптимизации, 630 с -O2
new/delete: 1000 без оптимизации, 450 с -О2
Получается верктор только в 1,4 раза медленее, имхо если не нужно выжимать последние миллисекунды - самое то.

Автор: vinter 21.4.2007, 19:03
если release то 1400 и 700, но все равно разница ощутима. и это хороший аргумент в пользу new

Автор: boriska 21.4.2007, 19:09
разница получается из-за того что при
Цитата

std::vector <int> aArray(50000000);

время тратиться на создание временного объекта, инициализацию этим объектом, а потом удаление его.

Даже при
 
Код

aArray.reserve(50000000);
for(int i = 0; i < 50000000; ++i)
        aArray[i] = 5;

у меня натикало 11968, а вариант с динамическим выделением - всего 890  smile 

Автор: archimed7592 21.4.2007, 19:20
Код
#include <iostream>
#include <cstdlib>
#include <ctime>
#include <vector>

using std::cout;
using std::cin;
using std::endl;
using std::string;

int main()
{
    const std::size_t count = 100000000;
    {
#if defined (TEST_VECTOR)
        std::vector <int> Array(count);//26432
#elif defined (TEST_NEW)
        int *Array = new int[count];//1572
#else
#error please define TEST_VECTOR or TEST_NEW
#endif
    clock_t start = clock();
        for(std::size_t i = 0; i < count; ++i)
            Array[i] = 5;
    cout << (clock() - start) << endl;
#if defined (TEST_NEW)
        delete [] Array;
#endif
    }

    return EXIT_SUCCESS;
}

g++-3.4.2+stlport-5.1.3 в релизе(про дебаг отдельно) даёт 234 против 343 (vector и new соответственно)... smile 
насчёт дебага: прелесть контейнеров в том, что, в дебаг-режиме они проверяют всё на логические ошибки... к примеру, если после изменения контейнера использовать итератор, полученный до этого изменения, то он(итератор) кинет исключение(smart-iterator), в релизе же даже не пикнет(fast-iterator)...

насчёт менеджера памяти: изначальный вариант я не поленился запустить 25 раз (только new, vector даже пробовать не стал)... каждый раз результат был всё меньше и меньше, причём, разрыв между первым запуском и последним был чуть ли не в 10 раз... короче говоря результат сильно зависит и от менеджера памяти и от операционной системы и от объёма оперативной памяти...

Автор: nickless 21.4.2007, 19:26
Цитата(boriska @  21.4.2007,  18:09 Найти цитируемый пост)
тратиться на создание временного объекта, инициализацию этим объектом, а потом удаление его

Ничего там не тратится, это же не конструктор копирования.
Цитата(boriska @  21.4.2007,  18:09 Найти цитируемый пост)
у меня натикало 11968, а вариант с динамическим выделением - всего 890

Оптимизацию включи smile 
Скорость нужно проверять на релизной сборке, потому что именно она будет потом использоваться.

Автор: Mayk 21.4.2007, 19:30
Цитата(nickless @  21.4.2007,  23:26 Найти цитируемый пост)

Ничего там не тратится, это же не конструктор копирования.

НЕ ВЕРНО. 
Запись vector<int> (50000) создает вектор из 50000 ПРОИНИЦИАЛИЗИРОВАННЫХ элементов.

Цитата(stl_vector.h)

      /**
       *  @brief  Create a %vector with default elements.
       *  @param  n  The number of elements to initially create.
       *
       *  This constructor fills the %vector with @a n copies of a
       *  default-constructed element.
       */
      explicit
      vector(size_type __n)

Автор: archimed7592 21.4.2007, 19:33
кстати, ещё одна "мелочь": вектор имеет инициализированные значения (0)... отсюда и разница такая... а вот как объяснить, что в цикле записи вектор работает быстрее чем дин-массив я затрудняюсь... но говорит это только в его пользу smile

Добавлено через 40 секунд
Mayk, опередил smile

Автор: boriska 21.4.2007, 19:36
nickless - за второе замечание спасибо
а по поводу 
Цитата

Ничего там не тратится, это же не конструктор копирования.

готов спорить....
to Mayk -  smile 


Автор: nickless 21.4.2007, 19:54
Цитата(Mayk @  21.4.2007,  18:30 Найти цитируемый пост)
НЕ ВЕРНО

Я вообще имел ввиду 
Цитата(boriska @  21.4.2007,  18:09 Найти цитируемый пост)
создание временного объекта
и
Цитата(boriska @  21.4.2007,  18:09 Найти цитируемый пост)
а потом удаление его

Какой именно временный объект там создаётся? int?

То что вектор инициализирует память, с этим я не спорю.

Автор: vinter 21.4.2007, 22:36
Цитата(archimed7592 @  21.4.2007,  19:33 Найти цитируемый пост)
кстати, ещё одна "мелочь": вектор имеет инициализированные значения (0)... отсюда и разница такая... а вот как объяснить, что в цикле записи вектор работает быстрее чем дин-массив я затрудняюсь... но говорит это только в его пользу 

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

Автор: JackYF 21.4.2007, 23:35
Цитата(apook @  21.4.2007,  17:38 Найти цитируемый пост)
vector классный массив он лучше чем array

Vector нужен, когда количество элементов заранее не известно. Точка.

Цитата(apook @  21.4.2007,  17:38 Найти цитируемый пост)
этот параноидальный скоростной погоня за скорост

Увеличение скорости даже на 10% иногда очень важно. А уж в данному случае, когда прирост 50-100%...

Цитата(archimed7592 @  21.4.2007,  17:54 Найти цитируемый пост)
это просто удобная обёртка...

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

Цитата(archimed7592 @  21.4.2007,  19:33 Найти цитируемый пост)
вектор имеет инициализированные значения (0)... отсюда и разница такая..

вот... иногда инициализация такая не нужна.

Цитата(vinter @  21.4.2007,  18:37 Найти цитируемый пост)
компилилось в VS2003, дебаг  

Ну а тут и ты не прав... Кто же в дебаге скорость проверяет? Инлайнинг функций-то в дебаге не производится... как минимум. А, уже сказали до меня по этому поводу...
А вообще по ходу поддерживаю. Если размер заранее известен, то даже 50% прирост скорости весьма существенен. Векторное - векторному.
В данном случае использовать вектор ради всего лишь автоматического удаления... имхо, не то.


Автор: Lomir 21.4.2007, 23:35
50000000 Это слишком большое число для масивов, т.к. время работы зависит от свободной памяти, распределение страниц, виртуальной памяти и т.д.
У меня на VS 2005 1 раз вектор работал 2сек, 2 раз около 1,5 все последущие 0,7 сек.
Масив 0,5 сек.
Привиду свой тест:
Код

int main()
{
    const int size = 1000000;            
    {
        clock_t start = clock();
        for (int j = 0; j < 100; ++j)
        {
            std::vector<int> v;
            v.reserve(size);
            int i = 0;
            for (int i = 0; i < size; ++i)
                v.push_back(i);
        }
        cout << "Vector Time: " << (clock() - start) << "\n";
    }
    {
        clock_t start = clock();
        for (int j = 0; j < 100; ++j)
        {
            int* arr = new int[size];
            for (int i = 0; i < size; ++i)
                arr[i] = i;
            delete[] arr;
        }
        cout << "Array Time: " << (clock() - start) << endl;    
    }
    return 0;
}

Вектор: 1,7сек
Масив: 1,5сек

Вектор немного отстает, но если им правильно пользоваться то отставание не большое - максимум процентов 20-35.
ИМХО во всех программах особо не чуствительных к скорости лучши пользоваться вектором. Кроме того вектор непожирает лишнюю память, и не инициализирует обьекты пока они не нужны.
Например зачем нам иметь масив из 100000 обьектов (причем все будут инициализированы), если мы пользуем в 80% тока 100.

Автор: JackYF 21.4.2007, 23:44
Цитата(Lomir @  21.4.2007,  23:35 Найти цитируемый пост)
Кроме того вертор непожирает лишнюю память, и не инициализирует обьекты пока они не нужны.


Офигеть... ты посты выше читал? Цитату об определение вектора и инициализации?
Вектор память лишнюю не пожирает? Да чтобы сделать операцию добавления элемента квазиконстантной по времени, он всегда резервирует какой-то процент от текущей запрошенной памяти...

Намного быстрее объявить 1000000 элементов сразу без инициализация, чем потом 20 раз перераспределять и/или выделять поблоково эти данные.

Массив динамический вообще не инициализирует память...

Цитата(Lomir @  21.4.2007,  23:35 Найти цитируемый пост)
но если им правильно пользоваться то отставание не большое - максимум процентов 25-35.

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

Автор: archimed7592 21.4.2007, 23:53
Lomir, ты не понял... push_back мы не используем... мы ставим и вектор и new в равные условия - заранее сообщаем длину массива и используем оператор [] для доступа к эдементам...

Цитата(vinter @  21.4.2007,  22:36 Найти цитируемый пост)
у меня new дало двойной прирост памяти.
ммм... про прирост памяти ты умолчал...

насчёт "его проблемы" - если я не ошибаюсь, то эта "проблема" решается путём смены аллокатора (второй шаблонный параметр вектора...)

Цитата(vinter @  21.4.2007,  22:36 Найти цитируемый пост)
так что я остаюсь при своем мнениии. 
угу, а то, что при доступе к объектам скорость +30% (хотя, я это объяснить не могу) тебя не смущает...


Цитата(JackYF @  21.4.2007,  23:35 Найти цитируемый пост)
Vector нужен, когда количество элементов заранее не известно. Точка.
кому точка... кому нет... лично я везде, где это возможно юзаю стандартные контейнеры и ничуточку не сожалею...


Цитата(JackYF @  21.4.2007,  23:35 Найти цитируемый пост)
В обертках, кроме того, могут использоваться дополнительные переменные для удобства реализации остальных функций.

из-за 4-40 байт ты готов пожертвовать всеми этими прелестями?

Цитата(JackYF @  21.4.2007,  23:35 Найти цитируемый пост)
вот... иногда инициализация такая не нужна.
а, что, если от неё можно избавится? ;)


ну и в заключении: кто-нибудь может объяснить то, что доступ к элементам для вектора быстрее, чем для массива созданного с помощью new?

Автор: Anikmar 22.4.2007, 00:49
Достаточно прикольный спор получился.
Мне кажется что-то не так - ведь вектор изнутри организован стандартными функциями.

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

Мне кажется, что в векторе очень хорошо используются регистровые переменные для настройки оптимизатора. Так как тест проводился в голом виде - просто индексация, то вектор и показал с оптимизатором себя быстрее. На самом деле время доступа у массива и вектора не должно отличаться - так как они используют одинаковые механизмы. В живой задаче, где между изменениями индекса будут находиться другие команды, которые не позволят оптимизатору сохранить регистры вектор должен быть медленнее априоре - так как у него обязательно будут дополнительные механизмы обслуживания сервиса.

ИМХО:
Для большинства задач вектор подходит идеально, но как любая универсальная штуковина она просто ОБЯЗАНА съедать больше ресурсов - за удобство надо платить. 
В задачах, где рессурсы критичны, собственное хранилище данных несомненно будет более экономичное. Любой мастер своего дела (в любой специальности) имеет как наборы стандартных инструментов, так и собственные приспособления, с помощью которых он достигает лучшего результата. Так и в программировании. Так что правы все стороны.  smile 

Автор: JackYF 22.4.2007, 01:10
Цитата(archimed7592 @  21.4.2007,  23:53 Найти цитируемый пост)
угу, а то, что при доступе к объектам скорость +30%

да как в принципе такое может быть? что может быть быстрее доступа (прямого) по памяти? (на user-уровне).
Не верю. Разве что кэширование какое-нибудь, блин... причем хитро, очень хитро работающее...


Цитата(archimed7592 @  21.4.2007,  23:53 Найти цитируемый пост)
Цитата(JackYF @  21.4.2007,  23:35 Найти цитируемый пост)
вот... иногда инициализация такая не нужна.
а, что, если от неё можно избавится? ;)


Геморрой, имхо. В массиве ничего дополнительно делать не надо.


Цитата(archimed7592 @  21.4.2007,  23:53 Найти цитируемый пост)
из-за 4-40 байт ты готов пожертвовать всеми этими прелестями?

Какими? Автоматическое удаление? В данном случае - выделки не стоит.

Цитата(archimed7592 @  21.4.2007,  23:53 Найти цитируемый пост)
угу, а то, что при доступе к объектам скорость +30% (хотя, я это объяснить не могу) т

выложи полный код еще раз (если он изменился), на котором ты получил +30%. А я у себя проверю... что получится.

Автор: vinter 22.4.2007, 08:58
Цитата(archimed7592 @  21.4.2007,  23:53 Найти цитируемый пост)
ммм... про прирост памяти ты умолчал...

тьфу..описался яsmile не памяти ,а скорости

Автор: likehood 22.4.2007, 11:48
Согласен с Lomir'ом на счет размера массива: он должен быть не слишком большим, чтобы не сказывалось обращение к свопу. Только в его варианте нужно вместо push_back обращаться к элементам по индексам. Тогда скорость работы вектора и массива будут совершенно одинаковыми (с учетом статистических погрешностей) - проверено на VS 2003.

Автор: Vyacheslav 22.4.2007, 17:15
И в конце концов, если мы гонимся за эффективностью и не хотим отказываться от удобств, предоставляемых вектором, кто мешает обращаться с ним, как с массивом? smile
Код

 #if defined (TEST_VECTOR)
        std::vector <int> Array(count);
        int *pArray = &Array[0]; 
#elif defined (TEST_NEW)
        int *pArray = new int[count];
#else
#error please define TEST_VECTOR or TEST_NEW
#endif
    clock_t start = clock();
        for(std::size_t i = 0; i < count; ++i)
            *(pArray + i) = 5;

Автор: archimed7592 22.4.2007, 17:36
Цитата(Anikmar @  22.4.2007,  00:49 Найти цитируемый пост)
так как у него обязательно будут дополнительные механизмы обслуживания сервиса.
господа, ткните пальцем, где дополнительные механизмы!
точнее они есть, но если их не использовать (работать так же как и с массивом)

Цитата(JackYF @  22.4.2007,  01:10 Найти цитируемый пост)
да как в принципе такое может быть? что может быть быстрее доступа (прямого) по памяти? (на user-уровне).
Не верю. Разве что кэширование какое-нибудь, блин... причем хитро, очень хитро работающее...
кеширование? шутишь? это же не жесткий диск...

Цитата(JackYF @  22.4.2007,  01:10 Найти цитируемый пост)
Геморрой, имхо. В массиве ничего дополнительно делать не надо
вектор - тоже геморрой... но он уже готовый... точно также как и готовые в boost пулы... также, как и этот аллокатор, который можно сделать один раз и не парится

Цитата(JackYF @  22.4.2007,  01:10 Найти цитируемый пост)
Какими? Автоматическое удаление?
универсальность хотя бы... ну это каждому по вкусу...

Цитата(JackYF @  22.4.2007,  01:10 Найти цитируемый пост)
выложи полный код еще раз (если он изменился), на котором ты получил +30%. А я у себя проверю... что получится.

http://forum.vingrad.ru/index.php?showtopic=147290&view=findpost&p=1107431

Автор: Anikmar 22.4.2007, 17:51
Цитата(archimed7592 @  22.4.2007,  17:36 Найти цитируемый пост)
господа, ткните пальцем, где дополнительные механизмы!
точнее они есть, но если их не использовать (работать так же как и с массивом)


А что, в векторе нет контроля выхода за пределы индекса?

Автор: Daevaorn 22.4.2007, 17:54
Цитата(Anikmar @  22.4.2007,  18:51 Найти цитируемый пост)
А что, в векторе нет контроля выхода за пределы индекса?

только в методе at(size_t)

Автор: nickless 22.4.2007, 17:56
Цитата(Anikmar @  22.4.2007,  16:51 Найти цитируемый пост)
А что, в векторе нет контроля выхода за пределы индекса?

есть, но не во всех методах, например в operator[] нет, а в at() есть.

Автор: Mayk 22.4.2007, 18:08
Цитата(nickless @  22.4.2007,  21:56 Найти цитируемый пост)

есть, но не во всех методах, например в operator[] нет, а в at() есть.

Она не обязана  быть в []. Но МОЖЕТ присутствовать в отладочных версиях.

Код

// stlport/stl/debug/_vector.h
  reference operator[](size_type __n) {
    _STLP_VERBOSE_ASSERT(__n < _Base::size(), _StlMsg_OUT_OF_BOUNDS)
    return _Base::operator[](__n);
  }

Автор: Anikmar 22.4.2007, 18:24
Вектор является ведь шаблонным классом.
И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис.

И вообще спор этот с моей точки зрения абсолютно бессмысленен.
Вектор ОБЯЗАН быть медленнее - только потому, что это высокоуровневый объект (класс). Со всеми вытекающими отсюда  накладными расходами - код дополнительных методов и т.п. 
Отсюда же следует, что вектор ОБЯЗАН быть удобнее - на то это и есть высокоуровневый объект.

Мне стало интересно - я слегка модернизировал приведенный тест - так, чтобы он всетак ближе был к реальности.
Я избрал такой вариант:
Код

#include <iostream.h>
#include <cstdlib.h>
#include <ctime>
#include <vector>
#include <conio.h>
using std::cout;
using std::cin;
using std::endl;
using std::string;


int main()
{
    std::vector <int> aArray(10000);//26432
    int *pArray = new int[10000];
    int i,j,k,l;
    clock_t start;

    for(l=0;l<5;l++)
    {
        cout << "Pass " << l <<endl;
        cout << "Vector\n";
        start = clock();
        for(int i = 0; i < 200; i++)
            for (j=0;j<300;j++)
                for(k=0;k<10000;k++) aArray[k] = rand();
        cout << (clock() - start) << endl;

        cout<"Massiv\n";
        start = clock();
        for(int i = 0; i < 200; i++)
            for (j=0;j<300;j++)
                for(k=0;k<10000;k++) pArray[k] = rand();
        cout << (clock() - start) << endl;
    }

    getch();
    delete []pArray;

    return EXIT_SUCCESS;
}


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

Я и так был в этом уверен на 99% (чудес на свете не бывает), но тут в обсуждении все по-разному говорили, вот я и решил сам посмотреть.
В среднем массив быстрее вектора примерно на 20% и это абсолютно нормально.

Автор: Mayk 22.4.2007, 18:33

Цитата(Anikmar @  22.4.2007,  22:24 Найти цитируемый пост)

В среднем массив быстрее вектора примерно на 20% и это абсолютно нормально.


Не стоит обобщать свой опыт на все компиляторы и все оптимизаторы.

Цитата

22:27:dvl:~$ g++ -O6 -DNDEBUG a.cpp
22:27:dvl:~$ ./a.out 
Pass 0
Vector
30660000
Massiv
31470000
Pass 1
Vector
32160000
Massiv
32460000
Pass 2
Vector
32120000
Massiv
32380000
Pass 3
Vector
32110000
Massiv
32530000
Pass 4
Vector
32220000
Massiv
32180000

Как мы видим, всё совсем не так однозначно.

Автор: Daevaorn 22.4.2007, 18:37
Цитата(Anikmar @  22.4.2007,  19:24 Найти цитируемый пост)
Вектор ОБЯЗАН быть медленнее - только потому, что это высокоуровневый объект (класс)

Абсолютная неправда.

Добавлено через 1 минуту и 1 секунду
Цитата(Anikmar @  22.4.2007,  19:24 Найти цитируемый пост)
И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис.

а inline?

Автор: archimed7592 22.4.2007, 18:41
Цитата(Anikmar @  22.4.2007,  18:24 Найти цитируемый пост)
ектор является ведь шаблонным классом.
И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис.
я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов...

Автор: Anikmar 22.4.2007, 18:44
А что такие цифры огромные?

На самом деле я не обобщаю на все компиляторы, я взываю к здравому смыслу. 
Вектор написан на Си и использует абсолютно такую же технологию как и голый массив - это же шаблон! И где-то там внутри сидит оператор доступа к массиву - его можно посмотреть под отладчиком:

  const_reference operator[](size_type __n) const { return *(begin() + __n); }

Только чтобы получить значение по этому адресу - как минимум происходит вызов функции ( вонкретном случае оператора [])
И нельзя заставить вектор быть быстрее голого массива - он ведь призван сделать массив удобнее - так как является надстройкой над стандартным массивом.

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

Как у меня:
В режиме отладки вектор медленее массива в 2 раза
В режиме без оптимизации - медленнее примерно на 2%
В режиме с оптимизацией - примерно 20%
Можно для интереса запустить на всю ночь, но совершенно нет никакого интереса этим заниматься.

Просто бессмысленный спор - вот и все. Я на форуме обратил внимание, что многие очень болезнено реагируют на любые попытки критики STL (на себе в свое время изучил)
Я не критикую  STL - а просто объяаляю факт: вектор слегка медленнее, но удобнее. И спорить с этим просто бессмысленно - так как даже в некоторых описаниях STL это прямо говориться.

Автор: Daevaorn 22.4.2007, 18:47
Цитата(archimed7592 @  22.4.2007,  19:41 Найти цитируемый пост)
 что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline.

что такое "IS"? И как оно "принуждает"?smile

Автор: Anikmar 22.4.2007, 18:49
Цитата(archimed7592 @  22.4.2007,  18:41 Найти цитируемый пост)
я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов...


В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует  дополнительную память. Поверьте, даром ничего не бывает - если где-то прибавилось (в данном случае удобства) - значит где-то убавится (в данном случае скорости и памяти). Не понимаю, зачем так болезненно это воспринимать?  smile 

На этом, я пожалуй раскланяюсь - спор ни о чем. Пустое.

Автор: Daevaorn 22.4.2007, 18:52
Цитата(Anikmar @  22.4.2007,  19:49 Найти цитируемый пост)
В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует  дополнительную память.

В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"?
Как раз случай с вектором, это прямое доказательство ложности данного высказывания.

Автор: likehood 22.4.2007, 19:01
Цитата(Anikmar @  22.4.2007,  19:49 Найти цитируемый пост)
Поверьте, даром ничего не бывает

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

Автор: Anikmar 22.4.2007, 19:13
Цитата(Daevaorn @  22.4.2007,  18:52 Найти цитируемый пост)
В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"?

Код программы тоже в памяти находится, если вы забыли.
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ

Автор: likehood 22.4.2007, 19:26
Daevaorn имел в виду, что в данном случае нет дополнительного расхода памяти по-сравнению с обычным массивом. Кстати, это хорошо видно из ассемблерного листинга.

Автор: Void 22.4.2007, 19:40
Цитата(Anikmar @  22.4.2007,  21:13 Найти цитируемый пост)
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ 

Угу. Только оператор [] вектора транслируется в 1-2 машинные команды — куда меньше, чем запихивание параметров в стек, вызов, выполнение операции и возврат.

Все возможные причины, по которым вектор может быть медленнее, уже перечислили. operator [] к ним не относится.

Автор: Daevaorn 22.4.2007, 19:42
Цитата(Anikmar @  22.4.2007,  20:13 Найти цитируемый пост)
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ

Таак, теперь подумай, если тот код который скрывается за vector::operator[] встроить в место вызова(нет ни передачи параметров, нет вызова функции, нет создания фрейма стека, нет передачи результата), то что получится? Правильно, сокращения расхода "памяти" и соответсвенно увеличение скорости. Вот так вот. Посмотри, кстати, asm листинг и прозрейsmile

Автор: Anikmar 22.4.2007, 20:35
Цитата(Daevaorn @  22.4.2007,  19:42 Найти цитируемый пост)
Таак, теперь подумай, если тот код который скрывается за vector::operator[] встроить в место вызова(нет ни передачи параметров, нет вызова функции, нет создания фрейма стека, нет передачи результата), то что получится? Правильно, сокращения расхода "памяти" и соответсвенно увеличение скорости. Вот так вот. Посмотри, кстати, asm листинг и прозрей 

А если вызовов 20?
Мы же сравниваем не просто однострочную iniline функцию с вызовом через стек и вызовом inline?

Мы сравниваем конкретную функцию inline с командой непосредственно взятия данных из массива. Эта inline функция практически это и делает! Посмотрите на ее код - я же ее привел. И сравните с кодом a = b[i].

Добавьте туда код остальных методов вектора (даже если ими не пользоваться (кстати, а зачем тогда вектор, правда?) - они что, в воздухе висят? Теперь добавим, что у нас есть вектор int и вектор float - 2 совершенно разных класса скомпилятся. Со всем своим функционалом (которым можно не пользоваться).

Полноте - чудес на свете не бывает, еще раз повторю. Просто к памяти сейчас отношение такое - типа ее много. И получаем операционки, которые на ядро 512 требуют - зато все удобно. Раз схалявил - два схалявил и получаем экзешники по 10 метров с функционалом, "которым необязательно пользоваться".

likehood,  Daevaorn,

Я немного не понимаю суть спора: неужели вы серьезно считаете, что функционал STL не потребляет дополнительных ресурсов? С чем вы спорите? 
Мое мнение: STL удобна, но расплачиваться приходится некоторым перерасходом ресурсов (памяти, скорости или того и другого).
Ваше мнение: Ни фига - этот функционал ничего не пожирает, он достается даром. Т.е. все килобайты исходного кода STL - это все ерунда и ни памяти ни времени процессора она не отнимает.

Продолжать дискуссию я просто не вижу смысла. 

За удобства надо платить. И это закон жизни, а не только программирования. Отсюда правда вытекает еще один лозунг: надо постараться не платить за неудобства - это уже ближе к программированию.



Автор: Mayk 22.4.2007, 21:01
Код

int fill_vector( std::vector<int>& vec )
{   
    for( int i = 0; i < vec.size(); ++i ){
        vec[i] = i*i;
    }
}   
    
int fill_array( int* array, int size )
{   
    for( int i = 0; i < size; ++i ){
        array[i] = i*i;
    }
}


Цитата(Anikmar @  23.4.2007,  00:35 Найти цитируемый пост)

Ваше мнение: Ни фига - этот функционал ничего не пожирает, он достается даром. Т.е. все килобайты исходного кода STL - это все ерунда и ни памяти ни времени процессора она не отнимает.


прошу показать где происходит перерасход ресурсов на примере.
vimdiff запущенный на исходники даёт такую картину

Цитата


 _Z11fill_vectorRSt6vectorIiSaIiEE:                         |  _Z10fill_arrayPii:                                       
  .LFB500:                                                  |  .LFB501:                                                 
      pushl   %ebp                                          |      pushl   %ebp
  .LCFI3:                                                   |  .LCFI0:                                                  
      xorl    %edx, %edx                                    |  ---------------------------------------------------------
      movl    %esp, %ebp                                    |      movl    %esp, %ebp
  .LCFI4:                                                   |  .LCFI1:                                                  
      pushl   %ebx                                          |      pushl   %ebx
  .LCFI5:                                                   |  .LCFI2:                                                  
      movl    8(%ebp), %eax                                 |      movl    12(%ebp), %ecx                               
      movl    4(%eax), %ecx                                 |      movl    8(%ebp), %ebx                                
      movl    (%eax), %ebx                                  |      testl   %ecx, %ecx                                   
      subl    %ebx, %ecx                                    |      jle .L6                                              
      sarl    $2, %ecx                                      |      xorl    %edx, %edx                                   
      jmp .L10                                              |  ---------------------------------------------------------
      .p2align 4,,7                                         |      .p2align 4,,7
  .L11:                                                     |  .L4:                                                     
      movl    %edx, %eax                                    |      movl    %edx, %eax
      imull   %edx, %eax                                    |      imull   %edx, %eax
      movl    %eax, (%ebx,%edx,4)                           |      movl    %eax, (%ebx,%edx,4)
      incl    %edx                                          |      incl    %edx
  .L10:                                                     |      cmpl    %edx, %ecx                                   
      cmpl    %ecx, %edx                                    |      jne .L4                                              
      jb  .L11                                              |  .L6:                                                     
      popl    %ebx                                          |      popl    %ebx
      popl    %ebp                                          |      popl    %ebp
      ret                                                   |      ret



По мне так эти асмовые исходники примерно эквивалентны. Основной цикл так вообще один к одному.

Автор: Daevaorn 22.4.2007, 21:08
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
А если вызовов 20?

а какая разница сколько, с каждого inline'a экономим.
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
Мы же сравниваем не просто однострочную iniline функцию с вызовом через стек и вызовом inline?

мы сравниваем доступ к элементу
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
Посмотрите на ее код - я же ее привел. И сравните с кодом a = b[i].

ну и где тогда по твоему проигрывает вектор?
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
Добавьте туда код остальных методов вектора (даже если ими не пользоваться (кстати, а зачем тогда вектор, правда?) - они что, в воздухе висят? 

а ты знаешь сколько кода генерирует компилятор, допустим, для создания массива не из элементов POD типа? Для вызова деструкторов и т.д. Так что на этом фоне при POD типе в векторе, теряем минимум. А при не POD типе, ещё больший минимум
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
Теперь добавим, что у нас есть вектор int и вектор float - 2 совершенно разных класса скомпилятся. Со всем своим функционалом (которым можно не пользоваться).

Неа. Компилятор осуществляет merge'инг. Ну например метода vector::size(). И многих других
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
И получаем операционки, которые на ядро 512 требуют - зато все удобно. 

Программы делают люди и для людей, поэтому критерий "удобно" в этом случае приоритетный.
Цитата(Anikmar @  22.4.2007,  21:35 Найти цитируемый пост)
неужели вы серьезно считаете, что функционал STL не потребляет дополнительных ресурсов? С чем вы спорите?

Мы говорим про доступ к элементам. Ты же всячески уходишь от темы в "общую" болтовню

Автор: vinter 22.4.2007, 21:14
Mayk, у вектора на три машинных инструкции больше smile 
Цитата(Anikmar @  22.4.2007,  20:35 Найти цитируемый пост)
За удобства надо платить. И это закон жизни, а не только программирования. Отсюда правда вытекает еще один лозунг: надо постараться не платить за неудобства - это уже ближе к программированию.

 smile 
Vyacheslav(извини если исковеркал), что призван показать твой пример, что для использования вектора в этом контексте надо заюзать еще одну строку кода, так это ему не в плюс..

Автор: Anikmar 22.4.2007, 21:34
Цитата(Daevaorn @  22.4.2007,  21:08 Найти цитируемый пост)
Мы говорим про доступ к элементам. Ты же всячески уходишь от темы в "общую" болтовню 


??? Вот те раз. Посмотрите мои посты. Я как раз и написал в первый раз - общее свое мнение о шабонных классах. 
И то что на моем компиляторе вектор по скорости слегка отстал - это факт, я его просто зафиксировал и написал об этом.

Последние посты - были как раз общие - теоретизировали на тему рессурсов:

Цитата(likehood @  22.4.2007,  19:01 Найти цитируемый пост)
В том-то и фишка, что в С++ многие вещи даются "даром" (ну или почти), чего не скажешь о многих других языках. В этом и заключается его сила. По-сути, целью создания языка С++ было создание высокоуровневого ОО-языка, не уступающего в производительности языку Си. Именно С++ впервые показал, что ООП не обязательно должно быть дорогим удовольствием. 


Цитата(Daevaorn @  22.4.2007,  18:52 Найти цитируемый пост)
В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"?
Как раз случай с вектором, это прямое доказательство ложности данного высказывания.


Цитата(archimed7592 @  22.4.2007,  18:41 Найти цитируемый пост)
я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов... 


Mayk, посмотрите заодно размеры получившихся файлов, если использовать массив и вектор. А по поводу практической идентичности листингов - про это я уже сказал, чем вы хотите меня удивить? вектор ведь тоже на СИ++ написан:

Цитата(Anikmar @  22.4.2007,  20:35 Найти цитируемый пост)
Эта inline функция практически это и делает!


А поповоду незначительноя разницы уже было:

Цитата(vinter @  22.4.2007,  21:14 Найти цитируемый пост)
Mayk, у вектора на три машинных инструкции больше  


Цитата(Anikmar @  22.4.2007,  18:44 Найти цитируемый пост)
Конкретные тесты на скорость на самом деле достаточно условны: разница между командами - несколько десятков тактов процессора, и на таких небольших величинах заемтна особо не будет.


Много пены - мало толку.  smile 

Автор: Mayk 22.4.2007, 21:50
Цитата(Anikmar @  23.4.2007,  01:34 Найти цитируемый пост)

Mayk, посмотрите заодно размеры получившихся файлов, если использовать массив и вектор.


Код

#include <vector>

#ifdef VEC
int fill_cont( std::vector<int>& vec )
{
        for( int i = 0; i < vec.size(); ++i ){
                vec[i] = i*i;
        }
}
#else

int fill_cont( int* array, int size )
{
        for( int i = 0; i < size; ++i ){
                array[i] = i*i;
        }
}
#endif


int main()
{
#ifdef VEC
    std::vector<int> cont(5000);
#else
    int* cont = new int[5000];
#endif

    fill_cont( cont
#ifndef VEC
    , 5000
#endif
    );

#ifndef VEC
    delete[] cont;
#endif
}


Цитата

01:41:dvl:~/src/pol$ g++ -DVEC  -O6 a.cpp -o vec
01:41:dvl:~/src/pol$ g++   -O6 a.cpp -o arr
01:41:dvl:~/src/pol$ ls -l arr vec
-rwxr-xr-x  1 dvl dvl 7368 2007-04-23 01:41 arr
-rwxr-xr-x  1 dvl dvl 7739 2007-04-23 01:41 vec


разница сосавляет 371 байт. После strip'а она уменьшается до 296 байтов.
Цитата

-rwxr-xr-x  1 dvl dvl 3540 2007-04-23 01:46 arr
-rwxr-xr-x  1 dvl dvl 3836 2007-04-23 01:46 vec


371 байт и 3 машинные инструкции (не входящие в основной цикл процедуры) являются величинами на несколько порядков меньшими чем заявленные

Цитата(Anikmar @  23.4.2007,  00:35 Найти цитируемый пост)
 экзешники по 10 метров

Цитата(Anikmar @  23.4.2007,  00:35 Найти цитируемый пост)
 килобайты исходного кода STL 

что свидетельствует о преувеличении тормознутости и гигантности stl. 

Автор: Anikmar 22.4.2007, 22:59
Цитата(Mayk @  22.4.2007,  21:50 Найти цитируемый пост)
371 байт и 3 машинные инструкции (не входящие в основной цикл процедуры) являются величинами на несколько порядков меньшими чем заявленные


Про какие величины я, простите, упоминал? Про "незначительные"? Или про "несколько десятков тактов (не команд)" процессора? А как я их должен еще охарактеризовать? А про 20% выигрыш в скорости на моем тесте - что имею, то и имею. Можно говорить, что Билдер плохо оптимизирует работу STL, столько же на сколько другой компилятор плохо оптимизирует работу массивов. Это все вода. Поймите главное: STL написана на том же языке! используя те же команды. Это не другой компилятор, не некая сторонняя библиотека - это шаблоны! И компилируются они одновременно с вашим кодом. И если утверждать на 100% - что STL работает быстрее, это то же самое, что говорить - никто не напишет лучше, чем разработчики STL. А ее писали такие же программисты (и может быть пользовались теми же форумами). Именно поэтому STL может быть медленнее стандартных средств, такая же по скорости, но никак не быстрее (если брать уровень программиста одинаковый). Потому, что одни и те же механизмы языка используются. 

А на счет экзешников по 10 метров - это мое обобщенное отношение к современным подходам. Почем линуксоиды не любят форточников? Одна из причин именно - за это. Линукс при том же функционале работает на полном барахле. Там код вылизывают и лишнего не вешают.

На счет килобайтов исходного кода STL.
Да, тут я погорячился. Посмотрел исходники. Их не килобайты. Их Мегабайты. Ну тут уж извиняйте.

Цитата(Mayk @  22.4.2007,  21:50 Найти цитируемый пост)
что свидетельствует о преувеличении тормознутости и гигантности stl. 

Покажите хоть один мой пост, где я назвал STL тормознутой и гигантской? Максимум, что я говорил - это о некоторой потери рессурсов. И это чистая правда, хоть что тут сделай. За исключением разве что результатов теста - там я оговорил четкие цифры, которые выдала конкретно моя машина с конкретно моим компилятором.

Можно, конечно еще поспорить на эту тему - например, посчитать такты процессора для каждой команды и т.п.
Использовать не тепличный бессмысленный тест, а более рабочую программу. все равно результат будет такой-же. Программист всегда будет выбирать: написать быстрее, но готовыми средствами, или изобрести свой велосипед. В некоторых случаях последнее дает ощутимые результаты, а в некоторых нет. Все зависит от задачи и от головы. Можно использовать вектор как в приведенном последнем тесте или "не используя его функционал" - непонятно зачем тогда. А если пользоваться всей мощью вектора - тогда платить придется точно. А так спор близок к теме: кто больше бензина жрет мопед или мерседес. Если их отправить накатом с горки - поверьте одинаково. Но в реальной жизни речь идет не о бензине. Если надо ехать из Питера в Москву - то уж естественно на мерседесе. А если через пробки смотаться в магазин за два квартала - то мопед. ИМХО.

БАЯН. Давайте его заканчивать!  smile 

Автор: console 23.4.2007, 00:36
Темка, однако, полезная... закрепить бы ее на будущее

Всем отписавшимся респект!  smile 

Автор: JackYF 23.4.2007, 16:50
Цитата(archimed7592 @  22.4.2007,  17:36 Найти цитируемый пост)
кеширование? шутишь? это же не жесткий диск...

Кэширование оперативной памяти в кэш процессора, я имел в виду.

 smile  Тема тут, конечно, успела еще 2 страницы постов нагрести smile

Автор: archimed7592 23.4.2007, 19:09
жесть, сколько настрочили... всё не асилил...

Цитата(Anikmar @  22.4.2007,  18:44 Найти цитируемый пост)
Только чтобы получить значение по этому адресу - как минимум происходит вызов функции ( вонкретном случае оператора [])
ничего не происходит... сколько раз уже это повторить?

Цитата(Daevaorn @  22.4.2007,  18:47 Найти цитируемый пост)
что такое "IS"? И как оно "принуждает"?smile
International Standard (Programming languages - C++, ISO-IEC, IS-14882, Second edition, 2003-10-15)
слово принуждает в Ожегове посмотри, плз ;)

Цитата(Anikmar @  22.4.2007,  18:49 Найти цитируемый пост)
В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует  дополнительную память.

Цитата(Anikmar @  22.4.2007,  19:13 Найти цитируемый пост)
Код программы тоже в памяти находится, если вы забыли.
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ 
"дополнительной" памяти нужно ровным счётом столько же, сколько понадобится, если написать то же самое, только в самом коде... короче говоря, дополнительного там ничего нет!



Цитата(JackYF @  23.4.2007,  16:50 Найти цитируемый пост)
Кэширование оперативной памяти в кэш процессора, я имел в виду.
которое работает только с STL-контейнерами? smile 

Автор: Daevaorn 23.4.2007, 19:24
Цитата(archimed7592 @  23.4.2007,  20:09 Найти цитируемый пост)
International Standard (Programming languages - C++, ISO-IEC, IS-14882, Second edition, 2003-10-15)слово принуждает в Ожегове посмотри, плз ;)

Я не про слово спрашивал, а про его суть в том конкретном контексте в котором оно было написано. По этому самому стандарту, который ты привел, "принудить" компилятор не может даже слово inline.
Так что уход от ответа, это не очень хороший стиль разговора;)

Автор: archimed7592 23.4.2007, 19:28
Цитата(Daevaorn @  23.4.2007,  19:24 Найти цитируемый пост)
"принудить" компилятор не может даже слово inline.
ааа... ты об этом smile
ну если компилятор соответствует Стандарту и ф-ция может быть заинлайнена, то это произойдёт... я это имел ввиду...

Автор: JackYF 23.4.2007, 19:35
Цитата(archimed7592 @  23.4.2007,  19:09 Найти цитируемый пост)
которое работает только с STL-контейнерами?

 smile конечно!  smile это хитрые интеловцы/амдэховцы (нужное подчеркнуть) специально в процессор встраивают коды, которые, увидя в бинарнике код, сгенерированный на основе stl-евских кодов, включают супер-пупер оптимизацию...

А если серьезно, то у нынешних процессоров кэши обоих уровней и конвейера настолько не поддаются систематиации, то вполне могло быть и такое.
Да! В твоих тестах - чей тест первым запускался - вектора или массива?

Добавлено через 2 минуты
Цитата(archimed7592 @  23.4.2007,  19:28 Найти цитируемый пост)
ну если компилятор соответствует Стандарту и ф-ция может быть заинлайнена, то это произойдёт

кажись, все-таки нет.
inline - в стандарте, как уже говорили - всего лишь рекомендация. Формально компилятор имеет полное право этого не делать. Кажись, по стандарту.

Автор: archimed7592 23.4.2007, 19:42
Цитата(JackYF @  23.4.2007,  19:35 Найти цитируемый пост)
inline - в стандарте, как уже говорили - всего лишь рекомендация. 
ну дык... рекурсию хоть укакайся не заинлайниш... потому и в рекомендательном виде (хотя, совр. компиляторы оч хорошо рекурсию разворачивают)...

Цитата(JackYF @  23.4.2007,  19:35 Найти цитируемый пост)
Да! В твоих тестах - чей тест первым запускался - вектора или массива?
во всех вариациях smile

Автор: JackYF 23.4.2007, 19:54
Цитата(archimed7592 @  23.4.2007,  19:42 Найти цитируемый пост)
рекурсию хоть укакайся не заинлайниш...

не, это понятно. В плане, компилятор, всего лишь  smile поддерживающий стандарт, может вообще плевать на функции, которые он в принципе может заинлайнить.

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

Автор: Earnest 24.4.2007, 08:03
Да ладно вам. Inline, конечно, рекомендательный характер носит, но это не значит, что компилятор будет на него плевать, если хочет (при соответствующих опциях, конечно). Просто это зависит от контекста. Например, куча вложенных вызовов и все хотят быть inline. Так что у бедного компилятора регистры из ушей вылезают...  Поэтому ему и разрешено самому определять, что тут инлайнить, а что нет. И угадать это сложно. А в тривиальных случаях - можно не сомневаться, сделает. Если мы говорим не наколенном компиляторе от Вася Пупкин и Со.
Поэтому лучшие друзья программиста - профайлер с отладчиком. smile  

Автор: JackYF 24.4.2007, 16:28
Цитата(Earnest @  24.4.2007,  08:03 Найти цитируемый пост)
Так что у бедного компилятора регистры из ушей вылезают... 
  smile  smile 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)