The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Научные журналы на пути к требованию сопровождать все публик..., opennews (?), 21-Апр-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


38. "Научные журналы на пути к требованию сопровождать все публик..."  +2 +/
Сообщение от Аноним (-), 22-Апр-12, 03:56 
> Осталось понять куда это выкладывать и зачем это редактору, рецензентам и тд.

Затем что без исходников они могут отправляться в РАЕН к Чудинову искать буковки на какашках. Без открытости нет никакой науки.

> У меня например файлы ежедневно генерируются по несколько сотен гигабайт

Был у меня бывший однокурсник из физтеха "с несколькими сотнями гигабайт в день"... Как-то научил его сначала не спользовать XML, потом fixed point форматам, префиксной и delta- компрессии и zlib. И внезапно вдруг стало "гигабайты в день", полгода экспериментов храняться на обычном винте. Хотя и сотни гигабайт в день нынче копейки, у меня одних торрентов в день сравнимо качается (25-50ГБ bdrip фильмец вечером посмотреть), данные стирать давно отвык.

> Вот если бы обязать автора предоставлять читателям полный (в разумных пределах) исходный
> материал по статье - это другое дело.

Это и есть весь код и данные.

Ответить | Правка | Наверх | Cообщить модератору

48. "Научные журналы на пути к требованию сопровождать все публик..."  +/
Сообщение от тоже Анонимemail (ok), 22-Апр-12, 11:19 
Грамотное сочетание XML и zlib позволяет сохранить высокий уровень абстракции (с возможностью расширения и легким чтением из любых языков на любых платформах), при этом дает не такой уж большой оверхед по объему хранимой информации. Так что отказ от XML первым делом - не лучшая практика.
Ответить | Правка | Наверх | Cообщить модератору

74. "Научные журналы на пути к требованию сопровождать все..."  +/
Сообщение от arisu (ok), 22-Апр-12, 16:11 
> Грамотное сочетание XML и zlib позволяет

…затормозить даже хорошие алгоритмы. отказ от xml — это очень хорошая практика. потому что xml — это double fail: машиной он читается с трудом, человеком тоже. тот же yaml, например, и глазами читается проще, и парзер для него проще.

xml — это такой модный buzzword. технологически эта штука применима весьма в малом количестве случаев. зато пихают её везде, потому что «xml — это круто, бакланы!»

Ответить | Правка | Наверх | Cообщить модератору

131. "Научные журналы на пути к требованию сопровождать все..."  –1 +/
Сообщение от тоже Аноним (ok), 23-Апр-12, 12:43 
Нет, просто XML - это самое простое и легко поддерживаемое, что можно сделать.
Отказ от него должен быть обоснованным, как и любая оптимизация.
В качестве первого шага отказываться от широко поддерживаемых форматов и переходить на велосипедные блобы - порочный метод, и применяться он должен только по необходимости.
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

157. "Научные журналы на пути к требованию сопровождать все..."  +/
Сообщение от тоже Аноним (ok), 23-Апр-12, 17:35 
Вы - вряд ли. Но те мои программы, которые используют XML, потребляют считанные килобайты, и утаптывать их в блобы - значит либо потерять обратную совместимость между версиями, либо поддерживать ее с куда большими усилиями, чем сейчас. Смысл?
Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

159. "Научные журналы на пути к требованию сопровождать все..."  +/
Сообщение от arisu (ok), 23-Апр-12, 17:49 
я про блобы, заметь, ничего не говорил. я говорил только про человекочитаемые форматы. xml таковым не является.
Ответить | Правка | Наверх | Cообщить модератору

176. "Научные журналы на пути к требованию сопровождать все..."  +1 +/
Сообщение от XoRe (ok), 24-Апр-12, 01:12 
> Нет, просто XML - это самое простое и легко поддерживаемое, что можно
> сделать.

Для гигабайт бинарных данных?

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

78. "Научные журналы на пути к требованию сопровождать все публик..."  +/
Сообщение от Аноним (-), 22-Апр-12, 17:20 
> Грамотное сочетание XML и zlib позволяет

Мужик, OSMщики уже вкурили как это "удобно" когда 250Gb данных - в XML :) Эти сраные абстракции в таком виде в жизни не сожрет ни 1 текстовый редактор, ибо не заточены текстовые редакторы на чушки в полтора терабайта. Распарсить сие займет адово количество времени. Сжатие - еще и сверху добавит.

Плюнули чуваки и сделали иной формат выгрузки - бинарный и даже слегка задрюченный. Стало 16 гигз вместо 250... это меньше чем если ту 250Гб XML в непрерывном виде bzip2 пожать.

Так что да. Гнать ссаными тряпками и сраной метлой из мест где более сотен кило данных ожидается.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

52. "Научные журналы на пути к требованию сопровождать все публик..."  +/
Сообщение от Аноним (-), 22-Апр-12, 12:29 
Речь про поток данных с сисиди камеры, 320 мбит/с, изображение динамичное, пикселизация очень важна. Я, конечно, не такой умный как вы, но эффективно упаковывать 12бит данные, рассчитывать ключевые кадры и дельта-кадры и записывать в таком виде все таки умудрился. В результате получилось около 15 мбайт/с. Дальнейшее сжатие всеми известными архиваторами дает эффект максимум порядка 20-30%, а занимает времени в разы больше чем сами эксперименты (по несколько часов в день). После обработки получается данных в десятки мегабайт, которые и хранятся. Хранить сами исходные файлы за сколь нибудь обозримый период времени не вижу смысла. Но раз редакция даст мне место под это - почему бы и нет, я с радостью закачаю и вам пару сотен гигабайт. Адресок только не забудьте предоставить.
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

79. "Научные журналы на пути к требованию сопровождать все публик..."  –1 +/
Сообщение от Аноним (-), 22-Апр-12, 17:43 
> Дальнейшее сжатие всеми известными архиваторами дает эффект максимум порядка 20-30%, а
> занимает времени в разы больше чем сами эксперименты

Сэр, алгоритмы тивы LZ4/LZO/Snappy - могут все еще ать некое сжатие, а поток 15Мб/сек для них ну вообще не проблема. Они при сжатии в 10 раз больше на современном проце класса core2 прожуют спокойно, так что если данные хорошо шмутся - вариант.

> Адресок только не забудьте предоставить.

А вы как торенты раздвайте. Договориться с парой челов что они будут "бэкапы сервировать" наврядли большая проблема. При современных объемах HDD сотни гиг может простой Пупкин прихранить. А что такое сотня гб при майнстрим винчах на 1-2Tb? А адресом может быть вообще magnet link например - абстрактный идентификатор набора данных :).

Просто пока вы снимки с CCD камер изучаете, другие парни двигали вперед другие области знаний, в том числе и о том как раздать сотни Гб тысячам людей без затрат ресурсов.

Как-то так оказалось что в XXI веке ну совсем не проблема раздать 1000 людей файл в 100Гб. Для этого надо просто привлечь к раздаче их самих. Они же и бэкапом выступить могут, в принципе. Как видите, проблема в принципе решаема, если захотеть. На самом деле даже очень злые копирасы нынче под внутренние цели эти технологии юзают. Публично чертыхаясь, но внутри себя кантуя многогиговые чушки на кучи машин при помощи торентов :)

Ответить | Правка | Наверх | Cообщить модератору

85. "Научные журналы на пути к требованию сопровождать все публик..."  +1 +/
Сообщение от Аноним (-), 22-Апр-12, 18:13 
Я пробовал и эти в том числе на своих данных. Скорость там в ущерб сжатию - что толку что они прокачивают сотни мегабайт в секунду если неспособны их сжать хотя бы еще на 10%. После того как я сделал предварительное сжатие - отбросив незначащие биты, плюс примитивная дельта по кадрам, ни один из доступных под линукс алгоритмов не дал более 20% сжатия. Что, в принципе, неудивительно: изображения динамичные и шумные - без потерь хорошо не сжать. А чтобы хранить разумное время разумное количество данных требуется сжатие хотя бы в несколько раз.

Просто у каждого своя специфика, кому то обязательно хранить огроменные массивы данных, кому-то после обработки они уже не нужны. Ну, например, какие нибудь спецы по крипто могут генерировать сумасшедшие по размерам таблицы нужные всего один раз. Или там результаты по молекулярной динамике - сохранил всю симуляцию, обработал и все, дальше саму симуляцию хранить без толку.

Хотя спор по большому счету ни о чем - речь, как оказалось, все-таки идет про предоставление доступа к использованным сырцам, а не к обрабатываемым данным программами из этих сырцов. В этом плане все выглядит гораздо разумней, речь пойдет в среднем про несколько мегабайт. Правда, непонятно, что делать с проприетарным софтом типа Comsol.

Ответить | Правка | Наверх | Cообщить модератору

112. "Научные журналы на пути к требованию сопровождать все публик..."  +1 +/
Сообщение от Аноним (-), 23-Апр-12, 05:46 
> Я пробовал и эти в том числе на своих данных. Скорость там
> в ущерб сжатию - что толку что они прокачивают сотни мегабайт
> в секунду если неспособны их сжать хотя бы еще на 10%.

Да, они ловят только откровенную рыхлость данных. В принципе может помочь какой-то тривиальный препроцессинг, типа дельта кодировария между сэмплами и/или расщепление разрядов отсчетов, так что хотя сами отсчеты не совпадают, после препроцессинга рыхлость сильно возрастет и простой лемпел-зив на ура скостит обнаруженную избыточность. Но это от природы данных зависит. В этом плане умные парни обитают в районе compression.ru - они могут дельно подсказать.

> После того как я сделал предварительное сжатие - отбросив незначащие биты,
> плюс примитивная дельта по кадрам, ни один из доступных под линукс
> алгоритмов не дал более 20% сжатия.

То что с камер обычно валится - имеет некий шум и прочая, что делает такой материалец не подарком для обычных lossless алгоритмов сжатия. Им надо точные совпадения, а с этим получается небогато. Однако есть ряд трюков с препроцессингом. При том ряд методов препроцессинга прост и быстр а результат куда удобнее для LZ-образных чем сразу влобешник с "датчика" с кучей шума.

> Что, в принципе, неудивительно: изображения динамичные и шумные - без потерь
> хорошо не сжать. А чтобы хранить разумное время разумное количество данных
> требуется сжатие хотя бы в несколько раз.

Может быть, вас устроят какие-то lossy данные или специфичные штуки типа huffYUV, ориентированные на нечто подобное? Особенно если после постпроцессинга.

> Просто у каждого своя специфика, кому то обязательно хранить огроменные массивы данных,
> кому-то после обработки они уже не нужны.

А тут имхо есть риск нарваться на ситуацию когда осознаешь что обработка была кривая, а пересчитать уже опаньки - исходного материала то нет. Впрочем вам наверное виднее.

> Ну, например, какие нибудь спецы по крипто могут генерировать сумасшедшие
> по размерам таблицы нужные всего один раз.

Ой, вон в торентах радужные таблицы на десятки и сотни гигз есть. Они нужны не 1 человеку и не 1 раз. А некоторые особо шустрые не только понасчитали но и продают даже.

> Или там результаты по молекулярной динамике - сохранил всю
> симуляцию, обработал и все, дальше саму симуляцию хранить без толку.

А что будет если обнаружится что в обработке был баг?

> Хотя спор по большому счету ни о чем - речь, как оказалось,
> все-таки идет про предоставление доступа к использованным сырцам, а не к
> обрабатываемым данным программами из этих сырцов.

Ну да, сами данные по идее те кто воспроизводить эксперименты будут и сами добыть смогут.

> В этом плане все выглядит гораздо разумней, речь пойдет в среднем про
> несколько мегабайт.

В современном мире нет никаких проблем раздать кусок в 100Гб данных толпе в 1000 человек, если уж такая задача есть. При том не требуется ни супер-серверов, ни архидорогих датацентров.

> Правда, непонятно, что делать с проприетарным софтом типа Comsol.

По уму - закaпывать. Потому что бред это собачий, когда бабло побеждает здравый смысл в ущерб всему остальному. Когда вы получаете выводы прогнав некие данные через некий черный ящик делающий "хзчто, но мамой клянусь что там все замечательно" - достоверность таких результатов под большим вопросом. В силу невозможности полноценной верификации: все упирается в неизвестность содержимого черного ящика и насколько он реально делал именно то что заявлено.

Ответить | Правка | Наверх | Cообщить модератору

129. "Научные журналы на пути к требованию сопровождать все публик..."  +2 +/
Сообщение от Аноним (-), 23-Апр-12, 12:26 
Ну, собственно, вот наглядный пример как далее будут развиваться события.

Достаточно было заикнуться что у меня сотни гигабайт в день - как меня начали учить что не надо использовать xml, а надо в бинарном виде, с плавающей точкой, дельта компрессия и все такое на каком-то совершенно левом примере. Я пояснил что все это уже пройденный этап и даже объяснил откуда берется такой объем и почему его трудно сжать. Мне начали объяснять про новые алгоритмы сжатия, которые должны решить мою проблему. Которые, как я объяснил, не применимы в моем случае. Мне начали давать новые указания куда дальше копать, несмотря на то что текущая ситуация меня удовлетворяет почти полностью. Да и вносить изменения в программную часть уже после начала серии экспериментов нежелательно, неизменность условий эксперимента может нарушиться совершенно неочевидным или неожиданным способом. А после серии экспериментов и написания статьи я может быть переключусь совсем на другое и все эти оптимизации просто окажутся растратой времени. Например, полгода назад эта же установка генерировала килобайты в секунду потому что обходилась фотодиодом и возможно я еще вернусь к тому варианту. Или отброшу временное разрешение и разные входные условия как ненужное и начну интегрировать по 20-30 однотипных кадров в один, не теряя в пикселизации. Хотя и тут найдутся люди которые начнут учить как надо делать, хотя ни слова про что я делаю, как измеряю и зачем ещё не было произнесено.

То есть, обратите внимание: про предметную часть ни слова еще не было произнесено! У кого нибудь еще есть сомнения почему авторам может не понравиться идея публикации исходных кодов?

Дорогой мой анонимный брат! Ты очень умен с своей области. Не обижайся. Но не имея представления "зачем" не стоит лезть к незнакомым людям с советами "что" надо делать. Какими бы тупыми они не выглядели на первый взгляд.

Ответить | Правка | Наверх | Cообщить модератору

139. "Научные журналы на пути к требованию сопровождать все публик..."  +1 +/
Сообщение от Аноним (-), 23-Апр-12, 13:28 
И, все-таки, спасибо за дискуссию - по крайне мере я понял, что шел в правильном направлении и ничего существенного не упустил. То есть смысл публикации кода все-таки есть, если его обсуждение сведется не к тому какой же автор лошара, а к тому как этот код можно было бы быстро и эффективно улучшить.

Аноним с сотней гигабайт

Ответить | Правка | Наверх | Cообщить модератору

127. "Научные журналы на пути к требованию сопровождать все публик..."  +1 +/
Сообщение от ФФ (ok), 23-Апр-12, 11:29 
>А что такое сотня гб при майнстрим
> винчах на 1-2Tb?

5...10% объёма.

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

174. "Научные журналы на пути к требованию сопровождать все публик..."  +/
Сообщение от efrfegv (?), 23-Апр-12, 21:43 
?> Как-то научил его сначала не спользовать XML, потом fixed point  форматам, префиксной и delta- компрессии и zlib.

Я что-то упустил, он вроде до всего этого гуано был физиком, или все таки и тогда не уже был?

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру