История изменений

Я серьёзно. =)))

Небольшая поправочка: не «доступного объёма RAM», а «доступного virtual address space» - отмапить целиком 4Gb+ файл (реальный предел существенно ниже) в 32-битной апликухе не удастся ни при каких раскладах, даже если операционка 64-битная и физической памяти завались.

В принципе, Вы конечно правы. Но только теоретически. Всегда для high-load нужно чётко понимать чем мы рискуем. Оно, правда, и не для high-load было бы хорошо, конечно, но тут уж не до жиру, быть бы живу.

Если мы переходим в virtual address space, то мы подразумеваем что у нас есть объём RAM + объём swap. Всё верно. Но если мы начинаем свапиться на больших файлах, то это уже плохо. Если мы начинаем свапиться на больших файлах и, вдобавок ещё и часто (хуже может быть только «постоянно»), то всё совсем плохо. Производительность системы будет в районе ни х… «никакая». Поэтому, тут уже надо смотреть сколько памяти у нас есть в распоряжении RAM и именно в рантайме, в момент исполнения нашего кода. Ну и прикидывать нагрузку на систему хотя бы примерно. Чтобы получить более-менее удовлетворительный по производительности результат. Потому что если система уйдёт в свап но уже не из-за Вашего кода, а из-за моего, то какая на фиг разница для заказчика почему система ушла в свап и еле-еле ногой дрыгает… =)))

P.S. Был такой ныне забытый термин robust programming. Ну вот. Оно и есть. =)

Я серьёзно. =)))

Небольшая поправочка: не «доступного объёма RAM», а «доступного virtual address space» - отмапить целиком 4Gb+ файл (реальный предел существенно ниже) в 32-битной апликухе не удастся ни при каких раскладах, даже если операционка 64-битная и физической памяти завались.

В принципе, Вы конечно правы. Но только теоретически. Всегда для high-load нужно чётко понимать чем мы рискуем. Оно, правда, и не для high-load было бы хорошо, конечно, но тут уж не до жиру, быть бы живу.

Если мы переходим в virtual address space, то мы подразумеваем что у нас есть объём RAM + объём swap. Всё верно. Но если мы начинаем свапиться на больших файлах, то это уже плохо. Если мы начинаем свапиться на больших файлах и, вдобавок ещё и часто (хуже может быть только «постоянно»), то всё совсем плохо. Производительность системы будет в районе ни х… «никакая». Поэтому, тут уже надо смотреть сколько памяти у нас есть в распоряжении RAM и именно в рантайме, в момент исполнения нашего кода. Ну и прикидывать нагрузку на систему хотя бы примерно. Чтобы получить более-менее удовлетворительный по производительности результат. Потому что если система уйдёт в свап но уже не из-за Вашего кода, а из-за моего, то какая на фиг разница для заказчика почему система ушла в свап и еле-еле ногой дрыгает… =)))

Я серьёзно. =)))

Небольшая поправочка: не «доступного объёма RAM», а «доступного virtual address space» - отмапить целиком 4Gb+ файл (реальный предел существенно ниже) в 32-битной апликухе не удастся ни при каких раскладах, даже если операционка 64-битная и физической памяти завались.

В принципе, Вы конечно правы. Но только теоретически. Всегда для high-load нужно чётко понимать чем мы рискуем. Оно, правда, и не для high-load было бы хорошо, конечно, но тут уж не до жиру, быть бы живу.

Если мы переходим в virtual address space, то мы подразумеваем что у нас есть объём RAM + объём swap. Всё верно. Но если мы начинаем свапиться на больших файлах, то это уже плохо. Если мы начинаем свапиться на больших файлах и, вдобавок ещё и часто (хуе может быть только «постоянно»), то всё совсем плохо. Производительность системы будет в районе ни х… «никакая». Поэтому, тут уже надо смотреть сколько памяти у нас есть в распоряжении RAM и именно в рантайме, в момент исполнения нашего кода. Ну и прикидывать нагрузку на систему хотя бы примерно. Чтобы получить более-менее удовлетворительный по производительности результат. Потому что если система уйдёт в свап но уже не из-за Вашего кода, а из-за моего, то какая на фиг разница для заказчика почему система ушла в свап и еле-еле ногой дрыгает… =)))

Я серьёзно. =)))

Небольшая поправочка: не «доступного объёма RAM», а «доступного virtual address space» - отмапить целиком 4Gb+ файл (реальный предел существенно ниже) в 32-битной апликухе не удастся ни при каких раскладах, даже если операционка 64-битная и физической памяти завались.

В принципе, Вы конечно правы. Но только теоретически. Всегда для high-load нужно чётко понимать чем мы рискуем. Оно, правда, и не для high-load было бы хорошо, конечно, но тут уж не до жиру, быть бы живу.

Если мы пепеходим в virtual address space, то мы подразумеваем что у нас есть объём RAM + объём swap. Всё верно. Но если мы начинаем свапиться на больших файлах, то это уже плохо. Если мы начинаем свапиться на больших файлах и, вдобавок, то всё совсем плохо. Производительность системы будет в районе ни х… «никакая». Поэтому, тут уже надо смотреть сколько памяти у нас есть в распоряжении RAM и именно в рантайме, в момент исполнения нашего кода. Ну и прикидывать нагрузку на систему хотя бы примерно. Чтобы получить более-менее удовлетворительный по производительности результат. Потому что если система уйдёт в свап но уже не из-за Вашего кода, а из-за моего, то какая на фиг разница для заказчика почему система ушла в свап и еле-еле ногой дрыгает… =)))