Автор Тема: прикладная монадология...  (Прочитано 28704 раз)

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #45 : Сентябрь 07, 2012, 01:05:12 pm »
... как-то разрулить вложенные регионы...
Возможно, для каждого региона придётся создавать отдельные стеки, и как-то увязывать эти стеки между собой...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #46 : Сентябрь 07, 2012, 01:07:18 pm »
Может стоит эти массивы организовать по принципу регионов памяти? Как стал ненужным какой-то кусок такого массива (группа объектов в нём) -- так и освобождать его целиком, не заботясь об объектах по отдельности...
Тут парится не из-за чего, так как взять или освободить объект на массиве - это O(1). Просто держится список (точнее стек) свободных элементов. Свободить объект означает поместить в этот стек индекс элемента массива. Создать объект означает взять из стека индекс свободного элемента, а если стек пуст, то запросить у ОС ещё одну "страницу".
Это ручное управление памятью в чистом виде внутри отдельного "адресного пространства" (с точно теми же рисками (в рамках того "адресного пространства")). По сути, эмуляция своего аллокатора. В яве подобными вещами тоже занимаются иногда (но не всегда с точно той же целью).

Для программ общего назначения конечно память обратно в систему отдавать надо.
Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: прикладная монадология...
« Ответ #47 : Сентябрь 07, 2012, 01:26:05 pm »
Это ручное управление памятью в чистом виде.
Давай выражение "в чистом виде" оставим для обозначения случая когда сохраняется возможность порчи памяти. Размещение объектов на массивах структур безопасно - порчу памяти вызвать не может. Надо эти градации ручного управления как-то различать.
Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
Да, я имел в виду что-то вроде этого. Надо было сказать для рантаймов общего назначения. В частности рантаймы дотнета, явы или блэкбокса должны уметь возвращать память обратно в ОС. Правда рантайм блэкбокса так этому и не научился до сих пор...

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #48 : Сентябрь 07, 2012, 01:37:55 pm »
Это ручное управление памятью в чистом виде.
Давай выражение "в чистом виде" оставим для обозначения случая когда сохраняется возможность порчи памяти. Размещение объектов на массивах структур безопасно - порчу памяти вызвать не может. Надо эти градации ручного управления как-то различать.
Ну, саму память испортить достаточно сложно (хотя флеш-память в МК я пожалуй смогу убить за несколько дней).

А вот получить по данному индексу/идентификатору не тот объект который ожидаешь (кто-то уже переиспользовал эту ячейку массива объектов) - вполне можно. И это вполне эквивалентно тому, если бы скажем в C++ для объектов некоторого типа я отведу средствами ОС отдельное адресное пространство (то есть как в нем ни гадь, ничего не затрешь из того что вне его), написал свой аллокатор/менеджер памяти для этого адресного пространства, и стал бы там ручками манипулировать (руками new, руками delete).

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

Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
Да, я имел в виду что-то вроде этого. Надо было сказать для рантаймов общего назначения. В частности рантаймы дотнета, явы или блэкбокса должны уметь возвращать память обратно в ОС. Правда рантайм блэкбокса так этому и не научился до сих пор...
Это да. Кстати, поскольку ява больше ориентировалась на сервера (долгое время) странички памяти обратно системе отдавать она научилась довольно недавно - лет шесть-семь назад. Ну и, помню, в Borland C++ Builder'e 6.0 тоже была эта беда, и, видимо в соответствующей делфи тоже. Впрочем народ-делфисты быстро написали свой менеджер памяти который полностью заменяет борландовский стандартный. И счастье наступило (народный менеджер работает быстрее и странички возвращает).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: прикладная монадология...
« Ответ #49 : Сентябрь 07, 2012, 02:01:03 pm »
Кстати, я могу сесть в лужу со своими изысканиями если скорость работы памяти будет расти быстрее чем её объём. Ведь если будет расти скорость работы памяти, то будет расти и скорость работы сборщика мусора. Если бы сейчас память работала в 20 раз быстрее, то сбор мусора на 8 Гигах отнимал бы не более 1 секунды, что для меня приемлемо. Тогда не пришлось бы отказываться от GC.

Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?


valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #50 : Сентябрь 07, 2012, 02:08:35 pm »
Это да. Кстати, поскольку ява больше ориентировалась на сервера (долгое время) странички памяти обратно системе отдавать она научилась довольно недавно - лет шесть-семь назад.
Я подумал, и понял что не прав - это было так (по крайней мере по умолчанию) в сановских реализациях java, но ведь были и другие (сертифицированные, то есть прошедшие все тесты) реализации которые никак от sun не зависили, например от IBM. Кроме того, возможно что например на солярисе сановская jvm память таки отдавала обратно (ну или была такая настройка).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #51 : Сентябрь 07, 2012, 02:11:29 pm »
Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?
Думаю да. Но скорее всего быстрее случится что во-первых раз в несколько вырастет сткорость ОЗУ + изменятся алгоритмы GC (я уверен что про эту проблему они знают, и в java вроде бы даже решили её (в оракловской реализации)). Тут ява немного впереди, потому что на серверах она используется более активно чем .net (в любых его ипостасях).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re: прикладная монадология...
« Ответ #52 : Сентябрь 07, 2012, 02:14:54 pm »
Кстати, я могу сесть в лужу со своими изысканиями если скорость работы памяти будет расти быстрее чем её объём. Ведь если будет расти скорость работы памяти, то будет расти и скорость работы сборщика мусора. Если бы сейчас память работала в 20 раз быстрее, то сбор мусора на 8 Гигах отнимал бы не более 1 секунды, что для меня приемлемо. Тогда не пришлось бы отказываться от GC.

Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?
А хрен его знает - вы же ведь не из ленивых -  производительность связана с частотой,  последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
« Последнее редактирование: Сентябрь 07, 2012, 02:16:46 pm от DIzer »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: прикладная монадология...
« Ответ #53 : Сентябрь 07, 2012, 02:19:02 pm »
А хрен его знает - вы же ведь не из ленивых -  производительность связана с частотой,  последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re: прикладная монадология...
« Ответ #54 : Сентябрь 07, 2012, 02:19:25 pm »
но в любом случае, думаю , что в течении некоторого времени ваш подход 3 - 5 лет будет иметь преимущества...

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: прикладная монадология...
« Ответ #55 : Сентябрь 07, 2012, 02:20:05 pm »
Если по закону Мура, то через 22 года размер кэшпамяти у процессора в десктопном компьютере станет 32 гигабайта. То есть через 22 года GC стопудово можно будет использовать для программ использующих 32 гигабайта памяти. Но только по тому же закону Мура объём оперативки в десктопе станет 64 террабайта. При наличии 64 террабайтов кому будут нужны мелкие жалкие программки использующие ничтожные 32 гига?  :) :) :)

DIzer

  • Гость
Re: прикладная монадология...
« Ответ #56 : Сентябрь 07, 2012, 02:20:50 pm »
А хрен его знает - вы же ведь не из ленивых -  производительность связана с частотой,  последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
да знаю я это, по этому и намекаю на то, что оценка требует определенных трудозатрат...

DIzer

  • Гость
Re: прикладная монадология...
« Ответ #57 : Сентябрь 07, 2012, 02:46:14 pm »
А хрен его знает - вы же ведь не из ленивых -  производительность связана с частотой,  последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
да знаю я это, по этому и намекаю на то, что оценка требует определенных трудозатрат...
нда - вроде как смена архитектуры на ivy bridge - дала на тех же частотах всего 15% процентов чистой производительности..

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: прикладная монадология...
« Ответ #58 : Сентябрь 07, 2012, 03:35:07 pm »
вроде как смена архитектуры на ivy bridge - дала на тех же частотах всего 15% процентов чистой производительности..
У меня на работе неразогнанный 2600K, а дома 3770K разогнанный до 4.2 ГГц. Память одинаковая 1600 МГц 9-9-9-24. Разница в производительности примерно 10%.

DIzer

  • Гость
Re: прикладная монадология...
« Ответ #59 : Сентябрь 07, 2012, 03:53:20 pm »
ну да Интель в массовом сегменте похоже , что сконцентрировалось на повышение эффективности - то есть  в грубо можно предположить что  при изменении архитектуры производительность изменяется на 20%   а архитектура меняется раз в год прорыв (увеличение производительности скачком в 2-3 раза случается через 5 лет)  можно оценить когда производительность увеличится в 80 раз (конечно лучше опираться на инфу о перспективных Интеловских разработках...).