Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravУ нас в файле два региона. У каждого региона по две границы (память линейная). Эти две границы произвольным образом находятся в максимум двух кластерах. Итого у нас максимум четыре кластера которые нужно изменять. Всё остальное мы «переставляем» меняя список (массив?) кластеров, который по сути является списком физических адресов кластеров на носителе. Кроме четырёх кластеров и списка мы ничего не перемещаем. А это всего несколько десятков килобайт на изменение. Изопропил про то же самое что и я. Медитируй над моим примером 18162053 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 18:11 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Изопропилpetrav, у тебя кластеры переменной длины? сдвинь плиз содержимое файла со смещения 100000 до 200000 на два байта влево И эту задачу решить не получилось. Что-то я тут с кластерами не додумал. :( Нужно в спокойной обстановке посидеть, покумекать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 18:12 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima TpetravУ нас в файле два региона. У каждого региона по две границы (память линейная). Эти две границы произвольным образом находятся в максимум двух кластерах. Итого у нас максимум четыре кластера которые нужно изменять. Всё остальное мы «переставляем» меняя список (массив?) кластеров, который по сути является списком физических адресов кластеров на носителе. Кроме четырёх кластеров и списка мы ничего не перемещаем. А это всего несколько десятков килобайт на изменение. Изопропил про то же самое что и я. Медитируй над моим примером 18162053 . Над ним и медитировал по заданию Изотропила. Затупил я. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 18:14 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
mayton, пятницы не дождался :) Изопропил дал код, написал альтернативный testio.cpp Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. test.cmd Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Писал на скорую руку, поэтому проверок размеров нет, файлы > 2 Гб не поддерживаются. Берем файл > 1 Гб и < 2 Гб и запускаем Код: plaintext 1. в результате будет что-то типа Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Это мой результат. Запускал на Win7x64. А дальше обсуждаем чем так плох мап :) PS Изопропил извини за Izotropil, petrav навеял очепяткой, только заметил. Править в коде и перетестивать не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 19:50 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Вот торопыга! А! Не высидел даже до устаканивания ТЗ. Вот щас Изопропил скажет что нифига это не его код. И давай фундаментально подойдем. Сделай-кто файл раз в 10 превышающий твою оперативу. И заполни хоть чем-то полезным. Белым шумом чтоли. Чтоб не константа была. И для стационарного состояния прогони хотя-бы циклов 2-3 каждый тест по очереди. Контрольный замер - последний. И сделай скрин загрузки memory в динамике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:12 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima TА дальше обсуждаем чем так плох мап :) У вас же маппинг выдал гораздо более лучший результат? Мне кажется что результат должен быть одинаковым, если не предполагать, что в данном алгоритме ОС на прямую при меппинге дала команду контроллеру диска, т.е. в оперативке при меппинге данные никогда не были. Хотя какую команду она могла бы дать если контроллер ничего не знает про файловую систему? Почему обычные файловые операции используют буфер в 4-ре килобайта? Может в этом и причина такого отставания? Вообще это сложная игра. Перед запуском программы файл не копировался с диска на диск? Не был ли он уже в кеше ОС? Компьютер перезагружали перед запуском? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:18 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
maytonИ заполни хоть чем-то полезным. Белым шумом чтоли. Чтоб не константа была. Ты считаешь, что ОС или контроллер диска делают что-то подобное архивации данных на лету? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:27 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
maytonВот щас Изопропил скажет что нифига это не его код. fc сделаем :) maytonИ давай фундаментально подойдем. Давай. Подумай что меряем, при каких условиях. Согласен что машинка для тестов у меня нестандартная. Предтоповый i7 (на тот момент) + 32 Гб DDR3 оперативки. Через год DDR4 подешевеет - заменю. Это считалка для тяжелых расчетов. 7-8 часов в день считает, но больше 1-2 ядер не нагружает, все что надо закэшировано в 15-20 Гб оперативки (недавно воткнул SSD навороченный - ничего не поменялось, жалко денег :)). Все остальное свободно для виртуалок и тестов. В виртуалке возможна любая конфигурация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:34 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravDima TА дальше обсуждаем чем так плох мап :) У вас же маппинг выдал гораздо более лучший результат? Мне кажется что результат должен быть одинаковым, если не предполагать, что в данном алгоритме ОС на прямую при меппинге дала команду контроллеру диска, т.е. в оперативке при меппинге данные никогда не были. Хотя какую команду она могла бы дать если контроллер ничего не знает про файловую систему? Но ОС знает про ФС и контроллер. Выше уже писал что ОС виднее как рулить памятью и диском, потому что ОС рулит этим. Любые обращения к ОС средствами языка по определению медленнее чем API ОС, т.к. это обертки на API. Но если честно не ожидал такого результата, ожидал что на 10-20% будет быстрее, но не в разы. Я исходники дал. Компилируем и тестим. Результаты выкладываем и обсуждаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:44 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravmaytonИ заполни хоть чем-то полезным. Белым шумом чтоли. Чтоб не константа была. Ты считаешь, что ОС или контроллер диска делают что-то подобное архивации данных на лету? :) Я считаю что наш мир сложен. Я встречал такие программно аппаратные решения которые херили все мои тесты. Чего только sparse files стоит. Или аппаратное сжатие на стриммерах. Это опимизация-невидимка. Поэтому там где есть хотя-бы ВЕРОЯТНОСТЬ того что результат соптимизирует какой-то девайс надо держать ситуацию под контролем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:52 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravПочему обычные файловые операции используют буфер в 4-ре килобайта? Может в этом и причина такого отставания? Вообще это сложная игра. Перед запуском программы файл не копировался с диска на диск? Не был ли он уже в кеше ОС? Компьютер перезагружали перед запуском? Исходники есть. Поставь буфер какой надо. Файл копировался по причине того что в итоге файл будет испорчен. В кэш ОС попал. Но поэтому поставил выполнение своего кода перед кодом Изопропила. Для чистоты эксперимента. Опять же исходники дал, правим под себя, тестим и выкладываем со своими результатами. Но на уровне кода никаких хитрых ходов. Оба варианта работают стандартно без каких либо ососбых требований от ОС. Обычный код для обычного приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 20:56 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
maytonВот щас Изопропил скажет что нифига это не его код. это то я стерплю, вопрос в предмете тестирования ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 21:02 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima Tpetravпропущено... У вас же маппинг выдал гораздо более лучший результат? Мне кажется что результат должен быть одинаковым, если не предполагать, что в данном алгоритме ОС на прямую при меппинге дала команду контроллеру диска, т.е. в оперативке при меппинге данные никогда не были. Хотя какую команду она могла бы дать если контроллер ничего не знает про файловую систему? Но ОС знает про ФС и контроллер. Выше уже писал что ОС виднее как рулить памятью и диском, потому что ОС рулит этим. Любые обращения к ОС средствами языка по определению медленнее чем API ОС, т.к. это обертки на API. Но если честно не ожидал такого результата, ожидал что на 10-20% будет быстрее, но не в разы. Ну хорошо. Предположим, что в данном алгоритме при меппинге ОС так разрулила контроллером диска, что данные никогда не проходили через интерфейсную шину диска, данные никогда не были в оперативной памяти и контроллер сам внутри винчестера всё скопировал. И в этом и результат такой впечатляющий. Мне почему-то кажется, что используя меппинг мы отказываемся от кеширующего механизма ОС. Что в 99.9% случаев приведёт к кардинальному замедлению программ. И при меппинге нужно подключать специалиста и чётко обосновывать зачем и как мы это делаем. И самим реализовывать кеширование. Возможно я не прав. А ReadFile() и fread() уж точно практически идентичны в плане производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 21:06 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravМне почему-то кажется, что используя меппинг мы отказываемся от кеширующего механизма ОС не то что бы отказываемся - механизм то работать будет, но исходить то он будет из потребностей не последовательного, а прямого доступа к данным( в многозадачной среде будет неуютно) petravА ReadFile() и fread() уж точно практически идентичны в плане производительности. кто-то иначе полагает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 21:19 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Если кому интересно. Мой единственный опыт с маппингом файлов на оперативную память. Была задача чтения текстового файла на несколько гигабайт. Просто таблица с данными — потом данные отправлялись на обработку. Читался этот файл с помощью обычного fscanf(). Автору программы показалось, что его приложение тормозит именно из-за операций чтения из файла. :) В общем, я разобрался с меппингом файлов и программу перевели на sscanf(). Я не верил в какое-то ускорение, а даже предполагал замедление программы. Случилось ужасное. Производительность приложения на маппинге упала в сотни раз (или даже в тысячи, точно не помню). Google it и я выяснил, что sscanf() перед своей работой обязательно ищет терминирующий ноль. Возможно в целях безопасности. Понятное дело, что в файле отображенном на память строки не разделяются нулевым символом. И ноль sscanf() находил хрен знает где, просто где-то случайно в памяти за пределами файла. На этом поиске и были тормоза. Доработали программу что бы она перед sscanf() заменяла '\n' на '\0'. :) Помогло. Но программа с мэппингом начала тормозить не в сотни раз, а всего лишь в пять раз. На этом эксперимент был прекращён, а пол рабочего дня вылетели в трубу. Так что все эти игры с меппингом дело сугубо специфичное. И только в руках профи оно может дать преимущество. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 21:48 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravИ только в руках профи оно может дать преимущество. так в чём проблемы - изучайте матчасть - madvise , в частности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2015, 21:57 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima TI/O в СУБД это другое, оракл не изучал, в основном MSSQL, но суть таже. Ровно то же самое. IO и в африке IO. Dima TТам оптимизация за счет индексов, статистик и т.п., т.е. за счет организации и использования метаданных. Там оптимизация сводится к тому чтобы прочитать минимум метаданных и получить данные или указатель на место где данные. Это всё именно для того, чтобы не делать лишнее IO, чтобы читать и писать меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 00:07 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
В Oracle много лет начиная с девятки под Linux конфигурят параметры Код: plaintext 1. 2. Как конфигурируется я щас не помню точно. Выставлени асинк порождает класс процессов которые связаны с фоновыми задачами I/O, а выставление DIRECT обладает способностью обходить ФС и работать ближе к диску ЕМНИП. К файлам оракл доступаеется ЕМНИП обычным open/read/seek/write API в том случае если датафайлы лежат на ФС. Под ASM и RAW весь ввод вывод идёт через более низкоуровневый API. Точно не уверен но кажется это уровень блочных символьных устройств в Unix. Упоминания о mmap files в документации именно по DBMS не встречаются ЕМНИП. Хотя есть в блогах и технофорумах посвящённых ОС и апп-серверам. В процессе работы DBMS открывает не просто много а очень много файловых дескрипторов. Есть отдельные части конфигурирования kernel специально предназначенные для снятия ограничений на одновременное открытие файлов. Разумеется представить себе mmap ввод вывод при количестве открытых файлов за 300 просто немыслимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 00:35 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
maytonВ Oracle много лет начиная с девятки под Linux конфигурят параметры Код: plaintext 1. 2. Как конфигурируется я щас не помню точно. Выставлени асинк порождает класс процессов которые связаны с фоновыми задачами I/O, а выставление DIRECT обладает способностью обходить ФС и работать ближе к диску ЕМНИП. Насколько я знаю, разработчики СУБД не ориентируются ни на механизм кеширования файловых операций в ОС, ни тем более на своп файл. Потому что это универсальные алгоритмы. А в СУБД разработаны собственные аналоги этих алгоритмов, но специализированные под конкретные задачи, которые решает СУБД. И в этом их производительность. (Плюс требования к отказоустойчивости). Там, наверное, мэппинг файлов на память и пригождается во всей своей красе. Но этим нужно серьезно заниматься и не по пятницам. Если нет — то лучше доверится ОС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 01:01 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
petravБыла задача чтения текстового файла на несколько гигабайт. Просто таблица с данными — потом данные отправлялись на обработку. Читался этот файл с помощью обычного fscanf(). Автору программы показалось, что его приложение тормозит именно из-за операций чтения из файла. :) В общем, я разобрался с меппингом файлов и программу перевели на sscanf(). Я не верил в какое-то ускорение, а даже предполагал замедление программы. Случилось ужасное. Производительность приложения на маппинге упала в сотни раз (или даже в тысячи, точно не помню).... мап тут вообще ни при чем, у тебя главный тормоз scanf`ы. Надо было писать свой парсер строки заточенный под твою строку. В идеале разбор строки в один проход. Дальше без разницы: читать кусок файла в буфер, парсить, читать следующий кусок и т.д. или сделать мап и обработать как один большой кусок. Вариант с мап просто удобнее, т.к. код меньше и проще. В случае с буфером надо попутно решать проблемы контроля вся ли строка в буфере, докачка в буфер с учетом этого и т.п. В принципе несложно, но с мап этого вообще не надо. Дальше от непонимания сути рождаются домыслы из серии "мап - магическая штука :)" petravНу хорошо. Предположим, что в данном алгоритме при меппинге ОС так разрулила контроллером диска, что данные никогда не проходили через интерфейсную шину диска, данные никогда не были в оперативной памяти и контроллер сам внутри винчестера всё скопировал. И в этом и результат такой впечатляющий. Мне почему-то кажется, что используя меппинг мы отказываемся от кеширующего механизма ОС. Что в 99.9% случаев приведёт к кардинальному замедлению программ. И при меппинге нужно подключать специалиста и чётко обосновывать зачем и как мы это делаем. И самим реализовывать кеширование. Возможно я не прав. ХЗ что ответить на этот поток сознания :) Напишу как я понимаю работу виндовса с файлами: при любом доступе к файлу (копирование, чтение, мап) данные из файла попадают в кэш ОС, а дальше при повторном чтении (неважно fread() или мап) берутся уже из кэша. При записи сначала пишется в кеш, затем из кэша на диск (в файл). Теперь рассмотрим детально что происходит на примере изменения 1 байта в файле: 1. Мап. Замапили файл, обращаемся в этому байту, происходит чтение 4 кб (страницы памяти) в кэш, т.е. получаем страницу физической памяти ассоциированную с куском файла, дальше эта физическая страница подставляется в адресное пространство моего процесса, т.е. фактически я меняю сразу в кэше ОС. Дальше менеджер памяти скидывает из кэша на диск. 2. fread(1 байт) происходит чтение 4 кб (страницы памяти) в кэш (как в п.1), оттуда байт копируется в память моего процесса, затем там его меняю, fwrite(1 байт) - ОС копирует из моей памяти в ту самую страницу кэша. Дальше как в п.1 Никакой мистики и магии. Мап быстрее за счет того что нет этих лишних копирований в памяти. Работа напрямую с кэшем ОС. И плюс накладные расходы на вызов fread()/fseek()/fwrite() в цикле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 07:25 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima T, немного изменил test.cmd Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. на ссд разница уже гораздо меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 07:48 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Заменил буфер с 4 кб на 1 Мб, результаты правдоподобнее. Сделал по два запуска. Код: plaintext 1. 2. 3. 4. Тормоза были из-за накладных расходов fread()/fseek()/fwrite() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 08:04 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
m_Slaна ссд разница уже гораздо меньше Затестил свой код на SSD. Победил Изопропил с кэшем 1 Мб Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 08:20 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
Dima T, на msdn про UnmapViewOfFile написано: Modified pages in the unmapped view are not written to disk until their share count reaches zero, or in other words, until they are unmapped or trimmed from the working sets of all processes that share the pages. Even then, the modified pages are written "lazily" to disk; that is, modifications may be cached in memory and written to disk at a later time. To minimize the risk of data loss in the event of a power failure or a system crash, applications should explicitly flush modified pages using the FlushViewOfFile function. т.е. реальное быстродействие UnmapViewOfFile вообще тяжело оценить вызов UnmapViewOfFile может закончиться за 0,5 сек, а потом ОС будет 10 сек лопатить файл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 08:23 |
|
||
|
замена 2 произвольных строк в огромном файле
|
|||
|---|---|---|---|
|
#18+
m_SlaDima T, на msdn про UnmapViewOfFile написано: Modified pages in the unmapped view are not written to disk until their share count reaches zero ... Это про совместное использование несколькими процессами. Т.е. пока все не освободят - записи не будет. Не наш случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2015, 08:31 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39054290&tid=2018833]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 285ms |
| total: | 444ms |

| 0 / 0 |
