А в памяти моей такая скрыта мощь...

[zVlad]

В системах с виртуальной памятью и "интеллекктуальным" механизмом "кражи" страниц в реальной памяти (frames) происходит адаптивный процесс накопления используемых страниц в реальной памяти.
Так что забивать реальную память неиспользуемыми страницами данных вовсе не обязательно, и даже глупо.

[Dm.uk]

В embedded приложениях всегда бюджет памяти специфицируется на все.

... скорее сперва "сколько жрет", ну а потом уже "сколько памяти" ;-)

[Palych]

В системах с виртуальной памятью и "интеллекктуальным" механизмом "кражи" страниц в реальной памяти (frames) происходит адаптивный процесс накопления используемых страниц в реальной памяти.
Так что забивать реальную память неиспользуемыми страницами данных вовсе не обязательно, и даже глупо.

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

[OtherSide]

Вы же слышали о том, что преждевременная оптимизация - зло? Так зачем экономить память пока ее все еще хватает?

[Palych]

Вы же слышали о том, что преждевременная оптимизация - зло? Так зачем экономить память пока ее все еще хватает?

Вообще-то неэкономия памяти, бездумное кеширование - тоже результат преждевременной оптимизации: во многих(большинстве) случаях никто не смотрит насколько кеширование реально помогает.

[Palych]

oops

[zVlad]

В системах с виртуальной памятью и "интеллекктуальным" механизмом "кражи" страниц в реальной памяти (frames) происходит адаптивный процесс накопления используемых страниц в реальной памяти.
Так что забивать реальную память неиспользуемыми страницами данных вовсе не обязательно, и даже глупо.

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

Я не говорил что на wintel нет виртуальной памяти.....

[mskmel]

Вообще-то неэкономия памяти, бездумное кеширование - тоже результат преждевременной оптимизации: во многих(большинстве) случаях никто не смотрит насколько кеширование реально помогает.

А также разные connection pools, service listeners, etc.

[Palych]

В системах с виртуальной памятью и "интеллекктуальным" механизмом "кражи" страниц в реальной памяти (frames) происходит адаптивный процесс накопления используемых страниц в реальной памяти.
Так что забивать реальную память неиспользуемыми страницами данных вовсе не обязательно, и даже глупо.

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

Я не говорил что на wintel нет виртуальной памяти.....

Извиняюсь, не догнал.
То есть - если данные кешируются, но кеш не используется - эти данные в итоге упадут в своп?
Я не спец во внутреннем устройстве современных систем, типа JVM.
Но на основании простого житейского опыта предположу что даже теоретически никуда эти данные не выпадут.
Прошу поправить мои доводы тех кто в теме:
1. На уровне ОС память распределяется/свопится страницами. JVM управляет объектами, которые неизбежно раскидываются между страницами.
2. Объекты в JVM постоянно "дергаются" сборщиком мусора.

[fleshold]

На самом деле чем больше память, тем важнее писать cache-friendly code

Например, производительность двух фрагментов кода ниже отличается в 20 раз примерно:

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[i,j];

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[j,i];

Ну точно не в 20, а наверное раза в полтора, ну может в 2. A[i,j]? Что за языг?

[Dmitry67]

На самом деле чем больше память, тем важнее писать cache-friendly code

Например, производительность двух фрагментов кода ниже отличается в 20 раз примерно:

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[i,j];

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[j,i];

Ну точно не в 20, а наверное раза в полтора, ну может в 2. A[i,j]? Что за языг?

хоть C#, хоть C, хоть C++
Или уже выросло поколение которое пишет только A[j]?
Матриц на вас нет!)))

разница 15-20 раз - вы ее не дооцениваете.

[OtherSide]

в смысле. В c/с++ только одномерные массивы

[Dmitry67]

в смысле. В c/с++ только одномерные массивы

Значит с фортраном перепутал)

[tessob]

Ну точно не в 20, а наверное раза в полтора, ну может в 2.

Я вообще не понимаю почему должна возникнуть даже двукратная разница. У нас же по идее при аллокации памяти под n-мерный массив сразу должна выделяться вся память. Соответственно, при изменении значения одного из элементов нам просто нужно найти указатель на первую ячейку в выделенном пространстве. Чего я упускаю?

[fleshold]

На самом деле чем больше память, тем важнее писать cache-friendly code

Например, производительность двух фрагментов кода ниже отличается в 20 раз примерно:

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[i,j];

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[j,i];

Ну точно не в 20, а наверное раза в полтора, ну может в 2. A[i,j]? Что за языг?

хоть C#, хоть C, хоть C++
Или уже выросло поколение которое пишет только A[j]?
Матриц на вас нет!)))

разница 15-20 раз - вы ее не дооцениваете.

Comma в языке C++ sequencing оператор.
10000*10000*4 примерно 380 метров. Проверить, так то несложно. Да и не стал бы я палиться написав сообщение что то недооценив. В случае

Code: Select all

A[i][j]

будет крутиться где то около секунды, допустим 777 мс, в случае

Code: Select all

A[j][i]

около двух, гдето 1666 мс. difftime() моментов до и после цикла выдаст 0 и 1 секунду соответственно. Неважно, хоть глобальной объяви A, хоть в кучу (локальной не получится). Не будет в 20 раз по любому.