Комментарии 2
Кстати, кому интересно почитать про опыт использования D в области биоинформатике можете почитать это тут thebird.nl/blog/D_Dragon.html
Увы, но в статье нет главного: исходных условий, которые вообще потребовали специальной оптимизации.
Например, я бы ожидал такое вступление.
В ежедневной работе многих ученых, работающих с генами, есть две большие взаимосвязанные проблемы — это огромный объем обрабатываемых данных и длительное сжатие/сохрание результатов расчетов. Причем эти проблемы взаимозависимы: хотите меьший объем данных на диске — ждите больше времени на упаковку. В результате приходится или забивать 1ТБ-диск данными в течение месяца, или ждать по часу в день из-за более тщательного сжатия. Поэтому мы решили попробовать найти и сконфигурировать библитеку сжатия с существенно лучшими параметрами сжатия по сравнению со стандартыми…
… и далее шла бы вся статья.
А в конце практические результаты применения:
— со стандартными средствами 1 час ожидания сжатия и 5GB данных в день.
— с новой библиотекой: 15 минут ожидания сжатия и 5.2GB данных в день.
Тогда бы было все понятно — зачем и почему. А то как-то слишком абстрактно. Более того, что-то мне подсказывает, что время на сжатие данных — это меньше 1% времени работы ученого. Тогда вопрос: а зачем вообще оптимизировать этот 1%?
Далее, в приведенном алгоритме вижу сразу две возможности существенно увеличить производительность:
1. Перейти на асинхронный ввод-вывод, или
2. Перейти на трехпоточный алгоритм: один поток читает, второй сжимает, третий пишет.
Это не говоря о том, что fast_lz, наверное, можно заставить выполняться на видеокарте, что ускорит время самого сжатия раз в 20-40.
Такие вот ощущения от статьи. :)
Например, я бы ожидал такое вступление.
В ежедневной работе многих ученых, работающих с генами, есть две большие взаимосвязанные проблемы — это огромный объем обрабатываемых данных и длительное сжатие/сохрание результатов расчетов. Причем эти проблемы взаимозависимы: хотите меьший объем данных на диске — ждите больше времени на упаковку. В результате приходится или забивать 1ТБ-диск данными в течение месяца, или ждать по часу в день из-за более тщательного сжатия. Поэтому мы решили попробовать найти и сконфигурировать библитеку сжатия с существенно лучшими параметрами сжатия по сравнению со стандартыми…
… и далее шла бы вся статья.
А в конце практические результаты применения:
— со стандартными средствами 1 час ожидания сжатия и 5GB данных в день.
— с новой библиотекой: 15 минут ожидания сжатия и 5.2GB данных в день.
Тогда бы было все понятно — зачем и почему. А то как-то слишком абстрактно. Более того, что-то мне подсказывает, что время на сжатие данных — это меньше 1% времени работы ученого. Тогда вопрос: а зачем вообще оптимизировать этот 1%?
Далее, в приведенном алгоритме вижу сразу две возможности существенно увеличить производительность:
1. Перейти на асинхронный ввод-вывод, или
2. Перейти на трехпоточный алгоритм: один поток читает, второй сжимает, третий пишет.
Это не говоря о том, что fast_lz, наверное, можно заставить выполняться на видеокарте, что ускорит время самого сжатия раз в 20-40.
Такие вот ощущения от статьи. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Высокопроизводительное сжатие DEFLATE с оптимизацией для геномных наборов данных