Как предполагается работать с массивами памяти более 4Гб ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
existing managed code that deals with arrays as virtually all APIs that deal with lengths and offsets are encoded using int. This penalizes the 90% case due to the need for conversions, which makes the developers code more complicated, which might also impact the ability for the code gen to emit performant code.
ну такое объяснение достаточно спорное, да есть проблема например при конвертации в массив, но ее можно решить исключением если длинна превышает int32,
хочешь получить старый массив — будь добр уважать старые традиции и не выходить за рамки int32 — делай Slice(0, Int32.Max) нарезай список массивов.
А если тебе не нужно конвертировать в массив — то почему бы не работать с новым Span/Memory который был бы не ограничен Int32
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, okon, Вы писали:
O>>Как предполагается работать с массивами памяти более 4Гб ?
VD>А где на практике это надо? VD>Для 0.001% случаев можно воспользоваться указателями. Зато 99.999% остальных случаев будут использовать более компактное представление.
Много где. Например видео — любая обработка. Хоть на телефоне, хоть на компьютере. Например 4К разрешение 120 кадров в секунду — у тебя будет 2Гб+ за 1 секунду.
Практически любая работа с файлами — например архивация или любая другая операция к ним же СУБД , работа с бэкапами, везде нужно будет помнить что файл может быть более 2Гб и
отказываться либо от обработки файла в памяти ( если алгоритм позволяет эффективно использовать ) либо от Span
Научные модельки — которые стараются максимально память использовать, они конечно на фортране в основном делаются, но все равно иногда прототип и на шарпе можно сделать.
Во всех случаях придется отказываться от Span т.к. данных может оказаться более 2 Гб.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Using this element in your application configuration file enables arrays that are larger than 2 GB in size, but does not change other limits on object size or array size:
The maximum number of elements in an array is UInt32.MaxValue.
The maximum index in any single dimension is 2,147,483,591 (0x7FFFFFC7) for byte arrays and arrays of single-byte structures, and 2,146,435,071 (0X7FEFFFFF) for other types.
Здравствуйте, okon, Вы писали:
O>Много где. Например видео — любая обработка. Хоть на телефоне, хоть на компьютере. Например 4К разрешение 120 кадров в секунду — у тебя будет 2Гб+ за 1 секунду.
Полноэкранный 4К — это 4096 × 3072 = 12 582 912 пикселей. Возьмем 32-битный цевет 12 582 912 * 4 = 50 331 648. Итого ~50 Мб, а ни какие не 2+ Гб.
Это во первых, во вторых такие вещи обычно не обрабатывают целиком. Их режут на море частей и вешают на видеокарты, спец-процессоры или хотя бы разные ядра процессоров.
O>Практически любая работа с файлами — например архивация или любая другая операция к ним же СУБД , работа с бэкапами, везде нужно будет помнить что файл может быть более 2Гб и
То что файл 2 или даже 10 Гб не значит, что его надо весть в оперативку тянуть. Так делают только начинающие думая, что это что-то даст.
O>отказываться либо от обработки файла в памяти ( если алгоритм позволяет эффективно использовать ) либо от Span
Дык никто этим и не занимается. Даже буфер в 2 Гб это глупость. Твоя обработка вылетит за все кэши процессоров.
O>Научные модельки — которые стараются максимально память использовать, они конечно на фортране в основном делаются, но все равно иногда прототип и на шарпе можно сделать.
Модельки всегда состоят из миллионов объектов. Так что тоже мимо.
O>Во всех случаях придется отказываться от Span т.к. данных может оказаться более 2 Гб.
Просто не надо выбирать детские, глупые решения и пихать все в один блок памяти. Когда-то процессоры работали с памятью в страничном режиме. И страницы были действительно маленькими (64 Кб). Вот это было неприятно. Но и тогда люди с успехом писали сложный софт обрабатывающих гигабайты данных.
Сейчас же ограничение в 2 Гб совершенно призрачно. В реальной задаче его превысить очень сложно. Если же такое решение оказалось более удобным (что вряд ли) можно тупо переставлять слайс в ифе или воспользоваться указателями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, okon, Вы писали:
O>>Много где. Например видео — любая обработка. Хоть на телефоне, хоть на компьютере. Например 4К разрешение 120 кадров в секунду — у тебя будет 2Гб+ за 1 секунду.
VD>Полноэкранный 4К — это 4096 × 3072 = 12 582 912 пикселей. Возьмем 32-битный цевет 12 582 912 * 4 = 50 331 648. Итого ~50 Мб, а ни какие не 2+ Гб.
Да только ты посчитал 1 кадр, а в секунду 120 кадров. т.е. умножь еще на 120.
VD>Это во первых, во вторых такие вещи обычно не обрабатывают целиком. Их режут на море частей и вешают на видеокарты, спец-процессоры или хотя бы разные ядра процессоров.
Если такие вещи не лезут в память то да, а если памяти хватает то лучше загрузить в память и обрабатывать.
O>>Практически любая работа с файлами — например архивация или любая другая операция к ним же СУБД , работа с бэкапами, везде нужно будет помнить что файл может быть более 2Гб и
VD>То что файл 2 или даже 10 Гб не значит, что его надо весть в оперативку тянуть. Так делают только начинающие думая, что это что-то даст.
Конечно не стоит тянуть но в ряде задач в той же СУБД или расчетах желательно максимально использовать доступную оперативку — иначе зачем она нужна.
O>>отказываться либо от обработки файла в памяти ( если алгоритм позволяет эффективно использовать ) либо от Span VD>Дык никто этим и не занимается. Даже буфер в 2 Гб это глупость. Твоя обработка вылетит за все кэши процессоров.
O>>Научные модельки — которые стараются максимально память использовать, они конечно на фортране в основном делаются, но все равно иногда прототип и на шарпе можно сделать. VD>Модельки всегда состоят из миллионов объектов. Так что тоже мимо. O>>Во всех случаях придется отказываться от Span т.к. данных может оказаться более 2 Гб. VD>Просто не надо выбирать детские, глупые решения и пихать все в один блок памяти. Когда-то процессоры работали с памятью в страничном режиме. И страницы были действительно маленькими (64 Кб). Вот это было неприятно. Но и тогда люди с успехом писали сложный софт обрабатывающих гигабайты данных.
C каких пор эффективное использование доступной оперативной памяти считается глупостью.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Тебя обязательно банить, чтобы ты научился цитировать только то что нужно?
Будь добр, цитируй только то на что отвечаешь.
O>Да только ты посчитал 1 кадр, а в секунду 120 кадров. т.е. умножь еще на 120.
Да какая разница сколько кадров в секунду? Ты их все равно последотально считать будешь.
В видео есть так называемые ключевые кадры. Они содержат полную картинку. Отсальные записываются/читаются отросительно предыдущих. Держать их в памяти бессмысленно. Ну, даже если ты их будешь держать в памяти, ты все равно будешь деражать отдельные буферы для каждого кадра. Зачем их в один буфер то складывать?
O>Если такие вещи не лезут в память то да, а если памяти хватает то лучше загрузить в память и обрабатывать.
Так поступают только начинающие, по неопытности. Никакого толку брать все в память нет. И еще раз повторяю — для каждого кадра ты создашь отдельный буфер. Все равно взять все видео в в формате 4К в несжатом виде ни в какуб память нельзя. Это сотни гигабайт. Оно в сжатом то виде в десятки гиг превращается. А в несжатом и подавно.
Меж тем банальная буферизация чтения и записи снимает любые проблемы. Быстрее о того что все в памятть загрузится не будет. Один хер все упрпется в производительность вычислительных мощностей и системы ввода-вывода.
O>Конечно не стоит тянуть но в ряде задач в той же СУБД или расчетах желательно максимально использовать доступную оперативку — иначе зачем она нужна.
Ну, не говори о том чего не знаешь. Чушь же несешь несусветную. Детский сад какой-то.
Базы данных совсем по другому с памятью работают. Они могут большую часть оперативки компьютера использовать, но при этом вся память делитсся на страницы и в каждый конкретный момент времени работа идет со страницей размер которй жалкие несколько клиобойт. Вот подкрузка и сброс (запись на диск) страниц — это охренительно не простой код, так как он всегда упираеися в IO.
O>C каких пор эффективное использование доступной оперативной памяти считается глупостью.
Это не эффетинвость, а глупость. Эффективность зависит от совсем других вещей. От алгоритомов и оптимизаций. Но буферы по 4 гига — это точно глупость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, okon, Вы писали:
VD>Тебя обязательно банить, чтобы ты научился цитировать только то что нужно? VD>Будь добр, цитируй только то на что отвечаешь.
Я не понимаю о каком цитировании тебя бомбит — я оставляю часть переписки чтобы можно было легко понять хронологию без листания всего форума.
O>>Да только ты посчитал 1 кадр, а в секунду 120 кадров. т.е. умножь еще на 120. VD>Да какая разница сколько кадров в секунду? Ты их все равно последотально считать будешь. VD>В видео есть так называемые ключевые кадры. Они содержат полную картинку. Отсальные записываются/читаются отросительно предыдущих. Держать их в памяти бессмысленно. Ну, даже если ты их будешь держать в памяти, ты все равно будешь деражать отдельные буферы для каждого кадра. Зачем их в один буфер то складывать?
Что эффективнее выделить память 120 раз или 1 раз ?
O>>Если такие вещи не лезут в память то да, а если памяти хватает то лучше загрузить в память и обрабатывать.
VD>Так поступают только начинающие, по неопытности. Никакого толку брать все в память нет. И еще раз повторяю — для каждого кадра ты создашь отдельный буфер. Все равно взять все видео в в формате 4К в несжатом виде ни в какуб память нельзя. Это сотни гигабайт. Оно в сжатом то виде в десятки гиг превращается. А в несжатом и подавно.
Когда не помещается в память тогда да. Зависит от алгоритма.
Но когда в память влезает — то как правило в большинстве случаев это эффективно.
Приведи пример алгоритма сложнее O(1*N) ( 1 — потому что даже 2 * N будет на мой взгляд эффективнее держать в памяти )
в котором результат быстрее посчитается если не хранить все данные в памяти.
VD>Меж тем банальная буферизация чтения и записи снимает любые проблемы. Быстрее о того что все в памятть загрузится не будет. Один хер все упрпется в производительность вычислительных мощностей и системы ввода-вывода.
O>>Конечно не стоит тянуть но в ряде задач в той же СУБД или расчетах желательно максимально использовать доступную оперативку — иначе зачем она нужна. VD>Ну, не говори о том чего не знаешь. Чушь же несешь несусветную. Детский сад какой-то. VD>Базы данных совсем по другому с памятью работают. Они могут большую часть оперативки компьютера использовать, но при этом вся память делитсся на страницы и в каждый конкретный момент времени работа идет со страницей размер которй жалкие несколько клиобойт. Вот подкрузка и сброс (запись на диск) страниц — это охренительно не простой код, так как он всегда упираеися в IO.
Незнаю Оракл с тобой вроде как не согласен и старается держать таблицы в памяти — мне даже очевидно зачем, но может чего-то не знаем.
Расскажи почему работа с таблицей в памяти будет медленее чем если она будет лежать на каком-нибудь диске ( не RAM диске )
O>>C каких пор эффективное использование доступной оперативной памяти считается глупостью.
VD>Это не эффетинвость, а глупость. Эффективность зависит от совсем других вещей. От алгоритомов и оптимизаций. Но буферы по 4 гига — это точно глупость.
Но вот выделять память 1 раз или 120 раз это оптимизация на твой взгляд или нет ?
С какого размера у тебя буфер считаьься глупостью — надо срочно в майкрософт написать чтобы в этом случае был эксепшен StupidBufferSizeException.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Qbit86, Вы писали:
Q>Мне не нравится такая манера общения: «Тебя обязательно банить, чтобы ты научился цитировать только то что нужно?»
Какая манера? Это я ему делаю дружеское предупреждение. Он оверквоит не смотря на предупреждения. Ну, хорошого отношения он не заслуживает. Теперь красные баны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
