Сообщение Re[31]: this_thread::sleep_for(1s); от 10.01.2017 7:28
Изменено 10.01.2017 7:32 lpd
Re[31]: this_thread::sleep_for(1s);
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Qbit86, Вы писали:
Q>>И, раз уж массив указателей это плохо для кэша, то почему это не плохо для массива moveable-объектов, которые (для реализации move-семантики) реализованы через тот же указатель, только внутри?
_>У тебя не верное сравнение. Структура объекта очевидно определяется не тем, как его будут хранить в массивах, а его прикладными свойствами. Так что в итоге в варианте использования массива указателей у нас получится массив указателей на объекты содержащие указатель. Кстати, вот именно такая архитектура и является максимально характерной для мира Java/C#.
_>Что касается кэша, то конечно же любая косвенность снижает его эффективность. Но какие-то самые банальные её уровни предсказатель всё же способен побороть. Но при многоуровневой косвенности эффективная работа кэша умирает сразу. )))
В кэше не только данные, к которым обращение проходит последовательно, но и данные, к которым недавно было обращание. Причем второй вариант актуален гораздо чаще, чем первый. Кэшировать последовательное обращение нужно скорее для инструкций, чем для данных.
_>Здравствуйте, Qbit86, Вы писали:
Q>>И, раз уж массив указателей это плохо для кэша, то почему это не плохо для массива moveable-объектов, которые (для реализации move-семантики) реализованы через тот же указатель, только внутри?
_>У тебя не верное сравнение. Структура объекта очевидно определяется не тем, как его будут хранить в массивах, а его прикладными свойствами. Так что в итоге в варианте использования массива указателей у нас получится массив указателей на объекты содержащие указатель. Кстати, вот именно такая архитектура и является максимально характерной для мира Java/C#.
_>Что касается кэша, то конечно же любая косвенность снижает его эффективность. Но какие-то самые банальные её уровни предсказатель всё же способен побороть. Но при многоуровневой косвенности эффективная работа кэша умирает сразу. )))
В кэше не только данные, к которым обращение проходит последовательно, но и данные, к которым недавно было обращание. Причем второй вариант актуален гораздо чаще, чем первый. Кэшировать последовательное обращение нужно скорее для инструкций, чем для данных.
Re[31]: this_thread::sleep_for(1s);
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Qbit86, Вы писали:
Q>>И, раз уж массив указателей это плохо для кэша, то почему это не плохо для массива moveable-объектов, которые (для реализации move-семантики) реализованы через тот же указатель, только внутри?
_>У тебя не верное сравнение. Структура объекта очевидно определяется не тем, как его будут хранить в массивах, а его прикладными свойствами. Так что в итоге в варианте использования массива указателей у нас получится массив указателей на объекты содержащие указатель. Кстати, вот именно такая архитектура и является максимально характерной для мира Java/C#.
_>Что касается кэша, то конечно же любая косвенность снижает его эффективность. Но какие-то самые банальные её уровни предсказатель всё же способен побороть. Но при многоуровневой косвенности эффективная работа кэша умирает сразу. )))
В кэше не только данные, к которым обращение проходит последовательно, но и данные, к которым недавно было обращание. Причем второй вариант актуален гораздо чаще, чем первый. Кэшировать последовательное обращение нужно скорее для инструкций, чем для данных. Либо, в вычислительных алгоритмах. Но там, скорее всего, будут простые массивы. Пример: я реализовывал алгоритм на простом бинарном графе, и boost::graph работал на 30% медленнее, чем моя структура. Это неплохо, но все равно неприемлемо.
_>Здравствуйте, Qbit86, Вы писали:
Q>>И, раз уж массив указателей это плохо для кэша, то почему это не плохо для массива moveable-объектов, которые (для реализации move-семантики) реализованы через тот же указатель, только внутри?
_>У тебя не верное сравнение. Структура объекта очевидно определяется не тем, как его будут хранить в массивах, а его прикладными свойствами. Так что в итоге в варианте использования массива указателей у нас получится массив указателей на объекты содержащие указатель. Кстати, вот именно такая архитектура и является максимально характерной для мира Java/C#.
_>Что касается кэша, то конечно же любая косвенность снижает его эффективность. Но какие-то самые банальные её уровни предсказатель всё же способен побороть. Но при многоуровневой косвенности эффективная работа кэша умирает сразу. )))
В кэше не только данные, к которым обращение проходит последовательно, но и данные, к которым недавно было обращание. Причем второй вариант актуален гораздо чаще, чем первый. Кэшировать последовательное обращение нужно скорее для инструкций, чем для данных. Либо, в вычислительных алгоритмах. Но там, скорее всего, будут простые массивы. Пример: я реализовывал алгоритм на простом бинарном графе, и boost::graph работал на 30% медленнее, чем моя структура. Это неплохо, но все равно неприемлемо.