Вау, джава не медленнее Си на обработке больших текстовых массивов

> Те кто в теме поймут. Правда они обычно прекрасно в курсе что подобное лучше на перле писать

может поэтому не некоторых сайтах пишут, типа: «мы ранним батч процесс, приходите через 3 дня».

Срока там будет каждая по миллиону рекордов. Я на шелл-скриптах, ауке, седе пробовал делать - очень мееееедленно, ждёшь тех же самых файлов (что и на джаве и на си отрабатывают за секунду) на порядки дольше. Перл конечно побыстрее пайплайнов будет, но он ведь читает строками, не?
(на чистом оуке я, правда, не писал, и как предполагаю, в его случае тормозили пайплайны).

Если предположить, что ява вм и библиотеки jni собраны тем же компилятором, что и приложение на си, то всё не так уж плохо.

ну я пробовал алгоритм Бернштейна, sdbm, алгоритм беркли ДБ используя свои простые структуры.
Там нечего буферизовать, всё и так в памяти, а полиномы простые, эффективнее вроде уже не напишешь, умножения все через сдвиги.

И пробовал B+tree («красно-чёрные деревья», в терминах Кнута?) джавовский, получилось быстрее.

http://siberean.livejournal.com/2253.html

> (пока в строке под миллион аллелей а в будущем может быть до 2х и может и больше)

случайно не SNP-чипы анализируются? Больше вспомнить не могу где подобный объем данных единовременно может быть. Чем тогда bioconductor не устраивает?

>Если предположить, что ява вм и библиотеки jni собраны тем же компилятором, что и приложение на си, то всё не так уж плохо.

Это предположение ничем не обосновано. Вот PyPy быстрее интерпретатора питона на си работает, угадай почему

>но он ведь читает строками, не?

может работать с текстовыми файлами как с бинарными - читать/писать через буфер. Другое дело что на числодробилке он будет на порядок медленнее

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

>Наверное из-за jit.

ЕМНИП там жита нет

В самом худшем случае обычно можно сменить компилятор.

В си??? Попробуй собрать ведро компилятором отличным от gcc

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

> Из последнего я понял, что джава не так уж и плоха.

Ага, для IO-bound задач, если перенбрегать временем на старт :)

> случайно не SNP-чипы анализируются?

ага.

Чем тогда bioconductor не устраивает?

у нас свои алгоритмы. Например, Half-IBD (Identity by descent) для нохождения участков полусовпадения, либо перегон сериез-матриц Бехара в другие форматы. bioconductor наверняка этого не умеет.

> а теперь 2 вопроса:

1) на выходе - как правило один файл. Всё равно надо мерджить. Как распараллеливать? Там не процессинг-баунд, а IO-баунд (переливать большие файлы из одного сосуда в другой, с какими-то преобразованиями).
2) можно сказать нисколько, я прежде всего думаю - как так прочитать файл - чтобы вывести нужный результат с наименьшим контекстом. Тот контекст обычно мал (если подходить чисто алгоритмически)

> Ага, для IO-bound задач, если перенбрегать временем на старт :)

Ну тогда буду писать на джаве, а не ANSI C.

Думаю, в генетике большинство задач будут IO-баунд, где объёмы данных в файле - гигабайты. У человека 2 миллиона снипов (если считать только то что сейчас считают, в будущем будет больше). И файлы могут быть на много-много строк, например для большой выборки или целой популяции. Если зафигачить в базу - там будет всё намного хуже.

Собираюсь также перегонять HAPMAP файлы (начал было но не закончил)

> 1) на выходе - как правило один файл.

поправлюсь: конечно же не везде. Вот в преобразовании PED в формат RAW - на выходе получается куча файлов, каждый из которых - по миллиону снипов. Размер исходного - не определён и, думаю, может быть очень-очень большим.
Т.е. именно тот один фильтр-преобразователь можно было бы распараллелить. Но хочу ли я нагораживать pthreads только из-за одного фильтра - не уверен.

> Если зафигачить в базу - там будет всё намного хуже.

Правда сейчас идея пришла загрузить не в RDB, а в берклиDB (с ней я когда-то работал), без синхронизации, или в люцину, и работать с ней.
Будет время - попробую и люциновский вариант. Только для тех задач, где нужен очень большой контекст (т.е. есть правила-зависимости между строками) и надо много раз проходить.
Кстати, я иногда читаю один файл 22 раза (для каждой хромосомы), выбирая подмножество - чтобы не грузить гигабайт в память (это когда нужен мэп-хэш, и этот мэп большой). Ну не люблю я память рашодовать, насмотрелся как люди по 4 гигабайтов захавывают и им этого мало. Поэтому иду «снизу». По-крайней мере прочитав один файл много раз - не возникнет катастрофических проблем у юзера, с нехваткой памяти, краша. Ну, пусть будет немного более IO-баунд.

> портил

Как точно сказано (:

> ЕМНИП там жита нет

Эм, а из-за чего ты думаешь там повышение производительности идет?

> ну я пробовал алгоритм Бернштейна, sdbm, алгоритм беркли ДБ используя свои простые структуры.

Так бы и сразу: это называется хеш-таблицы. Судя из ссылки на жж, сравнивалась современная реализация на яве и древний сишный СТЛ. Надо было хотя бы буст противопоставить...

И пробовал B+tree («красно-чёрные деревья», в терминах Кнута?) джавовский, получилось быстрее.

Предлагаю эту явовую реализацию запостить сюда: http://shootout.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=all . Может, она что-то и поменяет в этом рейтинге. А пока, первое, что приходит в голову - это кривость реализации в случае Си.

> Свинг несравнимо богаче тикля.

ага, а gtk богаче с++

>> портил

Как точно сказано (:

а для пользы дела, что-то конкретное сказать нечего? (кроме того что уже сказали)
Вон ахо я благодарен - за то что он меня ткнул в буфер и числа (В след.раз использую буферизированный read). Читать по чару всё равно надо (но уже из буфера), так как там совершенно не ясна длина рекордов (это же не старые-добрые fixed-length форматы, а delimited).

Есть конкретные предложения?

> Надо было хотя бы буст противопоставить...

Я буст не знал, каюсь. Был один большой проект на плюсах, до сих пор плююсь, ниасилил темплекты до конца и ломало классы прописывать. Да скецификацию, в отличие от тоненького K&R, нужно штудировать годами и иметь минимум десятилетие опыта, имхо, чтобы нормально на плюсах писать.

Предлагаю эту явовую реализацию запостить сюда: http://shootout.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=all . Может, она что-то и поменяет в этом рейтинге. А пока, первое, что приходит в голову - это кривость реализации в случае Си.

явовую реализацию чего? Конвертера кастомного, никому ненужного (кроме ресёрчеров) файла - в другой никому (из широкой публики) ненужный формат? Не засмеют? Потом надо большие файлы (гигабайтовые) готовить, искуственные, из ненастоящего генотипа, анонимный. Влом (это несколько часов скриптов). А оно мне надо?

>> Свинг несравнимо богаче тикля.

ага, а gtk богаче с++

не понял коментария, если честно. Разверните, если можно, для тугодума.

> А пока, первое, что приходит в голову - это кривость реализации в случае Си.

Там же ничего нет, посмотрите сами.

> явовую реализацию чего? Конвертера кастомного, никому ненужного

Нет, работы с деревьями. Или это тоже что-то стандартное?

tcl (тикль) это язык, а tk - это gui.

tcl может иметь биндинги к другим либам и gui.
например:
http://www.gnocl.org/

tk страшен ?
думаю тут от рук и школы все больше зависит:
ftp://h0.org.ua/pub/elipse/debian/img/tk/fig10.png
ftp://h0.org.ua/pub/elipse/debian/img/tk/fig11.png

ааа, понятно.
ок, подумаю (для этого надо будет сделать интересные синтетические тесты)

> tcl (тикль) это язык, а tk - это gui.

когда я сказал «тикль» - я имел в виду конечно же ГУИ, tk (я думал, что тиклем в рунете зовут именно его, и только сейчас идентифицировал что
tcl (ти си эль) это может быть прочитано как ти-к-л (хотя тк было бы ближе по звучанию).

Я не делал сложных Гуёвин на нём, только кнопки, выбор файлов, выбор выводов и подобное. Это одна простыня скриптов, но для некоторых юзеров - это по-любому лучше чем коммандная строка.

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

> ок, подумаю (для этого надо будет сделать интересные синтетические тесты)

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

Ты привел неудачный пример. Ядро изначально затачивалось на расширения gcc, но кто-то неск лет назад все таки собирал его каким-то другим компилятором.

Вобщем не будем флудить, моя мысль такова: если ява может работать с определенной скоростью, значит и на си можно написать не хуже. Цена этого «не хуже» конечно сильно зависит от конкретного проекта.

>Попробуй собрать ведро компилятором отличным от gcc

Непортируемый код, не соответствующий стандарту, можно написать на любом языке. Между тем, ядро сейчас компилируется и clang, и icc

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

дык сделайте, и скажите - если я смогу быть чем-то полезным.

или хотите развивать сишный вариант аналога aisconvert (всего тулкита или отдельных тулзов? Там HIR search самый сложный. ped2raw - самый лёгкий, гомозиготность - в середине) - милости просим.
Я дал линки на проект выше. Ещё была давно новость: http://www.linux.org.ru/forum/talks/4895524.

Или лучше - делать такие проекты - которые ещё не реализованы ни на одном из языков, а люди ждут, и скажут спасибо.
Вот, регистрируйтесь на молгене и там есть какие-то спеки и примеры, типа:
http://forum.molgen.org/index.php/topic,2491.new/topicseen.html
(Бехаровские сериез-матрикс файлы или перегнать хапмапы во что-то совместимое с PLINK etc)

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

Вы меня неправильно поняли - я имел в виду спор относительно быстродействия. Т.е. написать небольшой кусок кода на си, реализующий эти самые красно-чёрные деревья. Для участия даже в небольшом опен-сорс проекте у меня сейчас просто времени нет.

ну тогда хотя бы их напишите, сравните с хэшем по алгоритму Беркли DB, с C++овским ХэшМапом и джавовским ХэшМапом. С интересом почитаем результаты инсерта в и доступа к какому-нибудь много-миллионному массиву.

с выходом из анабиоза, товарисч!

>когда я сказал «тикль» - я имел в виду конечно же ГУИ, tk (я думал, что тиклем в рунете зовут именно его, и только сейчас идентифицировал что
tcl (ти си эль) это может быть прочитано как ти-к-л (хотя тк было бы ближе по звучанию).

Так ведь не только в Рунете, его как раз в англоязычных Интернетах так в первую очередь называют. Дискуссия тут: http://wiki.tcl.tk/11902

ну не слышал я от сотрудников тикль, каюсь. Только ти-си-эль. Потому что си это си, а не кэ, когда отдельным звуком.