А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
Нет, не нужно — diff уже написан. И аналогов есть готовых сотни. Нужно только выбрать. Или описать задачу так, чтоб diff для неё не подошёл.
А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
Если настолько часто, что это загоняет диск, тогда нужно создать отображение filename -> state. Berkley DB/memcache/xattr/что угодно key-value подойдёт. state может быть, например, md5 хэш от содержимого. Здесь — самое важное, при изменении файлов сразу же обновлять эту базу. Тогда сравнение (сначала лезем в базы и отсекаем файлы с одинаковым state) будет супер мега быстрое.
И такое, опять же, тоже есть. Называется git (ну это для скорости, а то ещё и другие тоже есть). Заводите в каждой из директорий по git-репозиторию, на каждом [втором/десятом/etc] изменении файлов делаете git add . && git commit -a -m "". Перед сравнением git fetch ../other-dir, само сравнение git diff other/master. Если выберете этот способ, могу подробно расписать что и зачем надо запускать.
А>Самый adyaq вариант — распаралелить сравнение каталогов. А>Имеет ли смысл использовать для такой задачи эрланг? А>Как у эрланга обстоит дело с чтением текстовых файлов?
Во-первых, на HDD вы раньше упретёсь в скорость диска. А если будете читать много файлов одновременно (в несколько потоков), то загоняете диск и скорость будет только хуже.
Re[13]: Стоит ли использовать erlang для такой задачи?
Влад, ты бы на даты этих ссылок посмотрел, археолог ты наш. А лучше познакомься с языками, о которых пытаешься говорить.
По факту, если посмотреть на современный код на F#, он на окамл совсем не похож, там и синтаксис другой (по умолчанию с отступами), и система типов, и вообще почти все. А если взять любую программу на окамле побольше hello world'a, в ней точно будут функторы из стандартной библиотеки (хотя бы Map), и она уже F#-ом не скомпилится. Если по началу между F# и окамлом было что-то общее — базовый ML, то с переходом на новый синтаксис и этого не осталось.
Re: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>>>Речь о select/poll. И первый, насколько я знаю, даже на винде поддерживается. T>>>select с нулевым таймаутом и будет тот самый "отчёт".
VD>>Можно ссылку на виндовую функцию отвечающую за то о чем ты говоришь. А то я пока что даже не понимаю о чем идет речь.
T>Пожалуйста. :) T>http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx
Это некорректно как минимум по двум причинам. Во-первых, если речь про виндовый select, то он работает только для сокетов. Объекты другого типа можно цеплять почти туда же через WFMO, но это громоздкий гибрид. Во-вторых, даже в Unix, где select/poll/etc. включены в общую систему и могут одинаково применяться к сокетам, пайпам, терминалам и т.д., они неприменимы к объектам прямого доступа, причём принципиально: необходимость задавать дополнительные данные (позицию на диске / в файле) не допускает решения типа "ждём пока нам новые данные сами в руки не приплывут).
Если, как в Erlang, основное исполнение процессов идёт в одном треде на процессор (характерно как минимум для R12 и R13), то дисковый ввод/вывод должен или заказываться через AIO, или через дополнительные системные треды. Posix AIO (aio_read, aio_write, lio_listio...) имеет существенные проблемы на ряде платформ (местами не реализованы, на Linux они обычно вообще делаются через треды), поэтому проще и легче делать это через pthreads или другую местную тредовую библиотеку. Поэтому erl имеет ключ +A для задания "предела ущерба" основной работе такими тредами. Мы у себя обычно ставим 10, хотя для ряда ситуаций имеет смысл уточнять это количество (видимо, переделаем стартёр на детект числа процессоров и зависимость количества дополнительных тредов от процессоров).
T>>>Тебе, может, и виднее как оно реализовано, например, на винде. В теории ввод-вывод это не параллельное выполнение. Потому что это вообще не выполнение. Ввод-вывод, по сути, это ожидание сигнала от устройства. VD>>Все верно. Но сигнал должен быть обработан каким-то потоком ОС. T>Сигнал должен быть обработан ядром. Почему именно потоком? Есть же однопоточный DOS. Железо его прервало, он обработал сигнал: поставил флаг и как-то там сообщил активной программе. АВВ есть, потоков нет.
Для того, чтобы работал такой подход, необходимо, чтобы программа систематически и вовремя проверяла этот флаг. Для Erlang'а самого по себе это достаточно тривиально: можно проверять флаг на каждые K редукций, а также в случае тотальной спячки. Но подключение любого внешнего кода, который работает иначе — уже усложняет обстановку и может привести к тому, что флаг не будет проверен вовремя.
T>Я думал, что мы вот это обсуждаем: T>
Не "почти" тут не катит. Смысл асинхроггого ИО в том, что оно именно что выполняется параллельно в другом потоке ОС, а программа в это время может выполнять другие действия.
T>и моя позиция (с доказательствами) в том, что смысл АВВ несколько более абстрактен: просто не блокироваться на IO. Кажется (я уже не уверен) мы спорим о том, обязательно ли тут нужны ОС потоки.
+5. В качестве показательного примера можно посмотреть на реализацию ядерного AIO во FreeBSD. В начале отработки заказа операции (aio_read, aio_write) проверяется, можно ли оформить просто заказ на данные. Если да — заказ оставляется и на этом действие завершается. Фактически, единственный вариант, который этому не подчиняется и требует явного создания ядерного треда — ввод/вывод файла на FS, потому что требует множества действий, связанных с FS (модификация atime/mtime, корректировка таблиц занятости...)
Аналогично работают kevent и epoll, хотя оформление заказа происходит на userland уровне и к прямому доступу это неприменимо.
С точки зрения API (неважно, ядерного или библиотечного) тут подход один — оставить заказ и описать, каким образом оповещать о его судьбе. Completion port? Пожалуйста. Сигнал процессу? Отлично. Лишь бы не забыли вовремя свистнуть. Что за неонка у ей внутре — начинает иметь значение только тогда, когда от формы неонки идут побочные эффекты.
T>Можно представить, что он "выполняется в другом потоке ОС", если так проще понять АВВ. Я придрался к тому, что 1) ввод-вывод не выполняется, его ждут 2) ОС потоки для этого не нужны (даже если в каких-то ядрах АВВ реализован через потоки).
Правильно сказать всё-таки, что "ОС потоки для этого" не обязательны (не для всех случаев, хотя есть случаи, когда без них не обойтись).
The God is real, unless declared integer.
Re[5]: Стоит ли использовать erlang для такой задачи?
VD>Еще раз. Если есть написанная на низкоуровневом языке библиотека асинхронного ВВ, то потоки вообще не нужны. Если же библиотеки нет, то на легких потоках вообще невозможно реализовать асинхронность, так как какой-то поток должен тупо передать управление в ядро и возобновить работу когда блокирующая операция завершится.
Да хоть десять раз. Я могу все это хоть под DOS где никаких потоков вообще нет устроить.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
DM>>Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
VD>Где, "там"?
В asynchronous workfows. Советую с ними познакомиться, прежде чем продолжать.
VD>И можно услышать твое определение понятия "аналогичный"?
В данном случае: похожий, работающий схожим образом, решающий ту же задачу.
DM>>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
VD>Вот это огромное заблуждение. Для F# дотнет среда не родная.
Для F# нет среды роднее. Если есть — покажи ее.
VD> F# — это адаптированный к дотнету ОКамл.
А Немерле — адаптированный к дотнету Паскаль. Возможно, исторически F# и вдохновлен окамлом, но сейчас между ними различий больше, чем сходств.
Re[17]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
FR>>Ну насколько я знаю основное это ML — модули и все что с ними связанно,
VD>А разве их выкинули?
Угу, в документации к старым версиям было прямо написано, не могу сейчас ссылку найти.
FR>>потом OCaml объекты,
VD>Это видимо для совместимости с объектной системой дотнета. Модули тоже, кстати.
Объекты да сильно разные, но модули при желании наверно можно было сохранить, в том
же SML.NET они есть.
FR>>препроцессор,
VD>Препроцессор в фшарпе есть. Он в оакмле сильно отличался?
Я имел ввиду AST препроцессор http://en.wikipedia.org/wiki/Camlp4
FR>>полиморфные варианты
VD>Кстати, а что значит полиморфные? Разве варианты могут быть не полиморфными?
Это значит что у них чуть ослаблена проверка на типы, для полиморфных вариантов не нужно
заранее описывать его тип и все полиморфные варианты совместимы по типу друг с другом,
что позволяет писать более обобщенный и гибкий код. Ну и плата за это некоторое ослабление
контроля.
Здравствуйте, Code Digger, Вы писали:
CD>Здравствуйте, Аноним, Вы писали:
CD>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.
Но вообще-то сомневаюсь, что подойдёт. У Эрланга блокирующие вызовы системных ф-ий, AFAIK, так что его треды Вас не спасут. Треды нужны нативные. Так что и с Пёрлом вопрос. Берите Хаскель, одним словом.
Re[3]: Стоит ли использовать erlang для такой задачи?
ну тогда ответ очевиден — пишите на том, на чем быстрее напишите и удобнее поддерживать. Вообще хоть я и не любитель перла, но на нем эту программу было бы написать быстрее чем мы тут с Вами обсуждаем
Re[9]: Стоит ли использовать erlang для такой задачи?
T>>1) сначала выяснить готова ли ОС выполнить твой read/write/accept прямо здесь и сейчас и сделать этот вызов, когда данные уже есть в буфере ОС/когда буфер для отправки уже свободен/когда клиент уже ждёт в очереди на подключение
VD>Это какая-то чушь. Я не знаю таких ОС которые отчитывались бы о том, что у них там в кэше, а что еще только планируется прочитать.
Речь о select/poll. И первый, насколько я знаю, даже на винде поддерживается.
select с нулевым таймаутом и будет тот самый "отчёт".
T>>2) установить колбек, который ОС позовёт, когда произойдёт нужный IO
VD>Вот это — да. Это другое дело. Но для этого нужно иметь библиотеку в которой реализован этот самый асинхронный IO.
Нет, речь о поддержке со стороны ОС. В винде это семейство WSAAsync*, WSAEvent* и Overlapped IO.
Ну, мы можем назвать libc и WinAPI такой библиотекой. Тогда для всего нужна эта библиотека и это неконструктивное ограничение.
T>>Для него даже потоки в ядре не нужны.
VD>А вот это не так. Нет многозадачности, нет и параллельного выполнения. Асинхронный ввод-вывод обычно тесно завязаны на менеджеры задач ОС.
Тебе, может, и виднее как оно реализовано, например, на винде. В теории ввод-вывод это не параллельное выполнение. Потому что это вообще не выполнение. Ввод-вывод, по сути, это ожидание сигнала от устройства.
VD>В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
В питоне eventlet реализует асинхронный ввод-вывод на кооперативных потоках и, в частности, select.
OS потоки для IO только вредны. Но только потому что тяжелы.
Спорить тут смысла нет, я просто поправил в чём смысл асинхронного IO. Фактически, придрался к словам; чего тут время терять.
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Mr.Cat, Вы писали:
MC>Мне кажется, в этой точке мы достигли терминологического коллапса.
Возможно.
MC>Мой изначальный тезис был, что асинхронный ВВ и легкие потоки — два взгляда на одну задачу использования минимума потоков ОС с максимумом профита.
Я так и не увидел связи между легкими потоками и АВВ.
VD>>Тут более уместен другой вопрос. А есть ли библиотеки (написанные на С, по всей видимости) для Эрланга которые реализуют этот самый асинхронный ввод-вывод?
MC>Внезапно, я совершенно себе не представляю, как работает ввод-вывод в эрланге. Для легких потоков ВВ блокирующий — это понятно. А вот как с ВВ поступает сам рантайм — я хз. Слышал краем уха, что в итоге всем ВВ в асинхронном режиме занимается отдельный (или ограниченное число отдельных) ОС-поток рантайма.
Ну, то есть АВВ встроен в интерпретатор? Вот это и нужно было бы рассмотреть по подробнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Стоит ли использовать erlang для такой задачи?
A>>А на Nemerle можно сделать поддержку синтаксического сахара для монад, который в Haskell называется "do синтаксис"?
VD>Естественно, да. Только не очень нужно.
Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
Файлов около 10000-20000.
Размеры каждого каталога порядка ~100Mb.
Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
Самый adyaq вариант — распаралелить сравнение каталогов.
Имеет ли смысл использовать для такой задачи эрланг?
Как у эрланга обстоит дело с чтением текстовых файлов?
Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
А>Самый adyaq вариант — распаралелить сравнение каталогов. А>Имеет ли смысл использовать для такой задачи эрланг? А>Как у эрланга обстоит дело с чтением текстовых файлов? А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?
По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.
Re[3]: Стоит ли использовать erlang для такой задачи?
От:
Аноним
Дата:
09.02.10 09:11
Оценка:
CD>Берите Хаскель, одним словом.
Задача конечно не срочная, но с хаскелем я точно быстро не разберусь.
А откладывать задачу на пол года-год как-то не хочется
Re: Стоит ли использовать erlang для такой задачи?
Эрланг использовать совершенно бессмысленно. Дисковый ввод-вывод вывод у него очень тормозной. Дальше три варианта
1) алгоритм сравнения достаточно прост, и производительность ограничена random io, например сравниваются загаловки файлов
2) алгоритм сравнения прост и производительность ограничена linear io. Например считаем контрольные суммы файлов.
3) алгоритм сравнения мегасложен, так что упираемся в cpu.
Если #1 то подойдет по сути любой язык, много Вы не проиграете
Если #2 то подойдет любой язык с вменяемой скорость ввода вывода. perl, python, java, c... только не erlang
Если #3 то тоже что и #2 + нормальная поддержка многопоточности, думаю это есть во всех языках, но на перле я с этим дела не имел. я бы делал на java или c++ если уж совсем скорости не хватает.
Re[2]: Стоит ли использовать erlang для такой задачи?
От:
Аноним
Дата:
09.02.10 10:15
Оценка:
Алгоритм сравнения — простой.
Где-то в начале файла находится строка с айдишником, датой, временем, которую сравнивать не нужно.
Весь остальной текст сравнивается просто построчно до первого различия.
Re: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
Что значит СРАВНИВАЛА? /bin/cmp годится? Это наиболее принципиальный момент.
А>Самый adyaq вариант — распаралелить сравнение каталогов.
На небольшое (2-4-8) число потоков. Для использования двухвёдерных процессоров с быстрыми жёсткими дисками.
И упираться всё будет скорей в них, в диски. Тогда не факт вообще, что распараллеливание не сделает только хуже
(из-за нелинейного чтения). Небольшое же число потоков нагрузки на диск сильной не даст, но позволит отдать процессор
в другие задачи, когда где-то упёрлось в диск (IMHO).
А>Имеет ли смысл использовать для такой задачи эрланг?
Слов нет. А старый добрый fork() ничем не хуже какбы.
Re[4]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Аноним, Вы писали:
CD>>Берите Хаскель, одним словом. А>Задача конечно не срочная, но с хаскелем я точно быстро не разберусь. А>А откладывать задачу на пол года-год как-то не хочется
Вы себя переоцениваете! Нужно быть исключительным идиотом, чтобы потратить на эту задачу полгода, даже изучая Хаскель с нуля.
Первое, что я написал на Хаскеле был "Hello, World", второе — grep.
Многопоточность в Хаскеле вполне понятна, с точностью до местного колорита. Можно писать и как на Си.
Поскольку в этой задаче никаких абстракций Вам городить не придётся, то даже понимать монады не обязательно — достаточно принять как данность IO Monad.
Re[3]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Code Digger, Вы писали:
CD>Здравствуйте, Code Digger, Вы писали:
CD>>Здравствуйте, Аноним, Вы писали:
CD>>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.
CD>Но вообще-то сомневаюсь, что подойдёт. У Эрланга блокирующие вызовы системных ф-ий, AFAIK, так что его треды Вас не спасут. Треды нужны нативные. Так что и с Пёрлом вопрос. Берите Хаскель, одним словом.
Спасут. Стартовать рантайм с опцией async-threads и вперед — никаких проблем. Треды нативные не нужны.
Re[2]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Code Digger, Вы писали:
CD>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.
С тех пор в модуле file как-то тихо появилась функция read_line, или что-то вроде того. Для чтения строки. Если это, что я думаю (а это по ходу оно), то все должно быть отлично с чтением текстовых файлов без плясок с бубном. Главное в этом деле, по большому счету — не использовать модуль io. И вся хитрость.
Re: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
А>Самый adyaq вариант — распаралелить сравнение каталогов. А>Имеет ли смысл использовать для такой задачи эрланг?
Нет. Если надо сравнивать контент файлов находя разницу построчно, есть хорошие шансы упрется в процессор, а не в диск. В случае с Эрлангом — я могу гарантировать упирание в CPU.
Рекомендую С/С++. Параллелить — только по показаниям, количество тредов иметь несколько больше, чем процессорных ядер, чтобы сравнение контента наложилась на операции ввода-вывода. Да, и ни в коем случае ничего не копировать между тредами — предпочтительно в тредах сравнения работать с неизменяемыми данными, и не класть на них блокировок.
Это если очень хочется, чтобы работало очень быстро. А для начала — тупо заколбасить на С/С++, взяв готовую хорошую либу, которая быстро умеет искать diff. Тысячи их.
Re[2]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>Во-первых, на HDD вы раньше упретёсь в скорость диска. А если будете читать много файлов одновременно (в несколько потоков), то загоняете диск и скорость будет только хуже.
Точно. Но конвейеризовать — можно, чтобы наложить чтение на вычисление. Один поток читает файлы последовательно (блоками, чтоб памяти хватило), передает данные второму, второй — на фоне чтения выполняет сравнение.
Возможно, проще будет асинхронным вводом-выводом воспользоваться, делать все в одном треде, и не парить мозг. Вариант.
Re: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
А>Самый adyaq вариант — распаралелить сравнение каталогов.
Эта задача будет упираться в файловый ввод-вывод. Если распараллелете чтение каталогов, скорее всего получите падение скорости. Порядка так на два. Из-за того, что система, пытаясь угодить всем потокам сразу, будет ездить головкой диска туда-сюда, вместо того, чтобы долбить в каком-то одном месте.
Re: Стоит ли использовать erlang для такой задачи?
От:
Аноним
Дата:
10.02.10 03:16
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
А>Самый adyaq вариант — распаралелить сравнение каталогов. А>Имеет ли смысл использовать для такой задачи эрланг? А>Как у эрланга обстоит дело с чтением текстовых файлов? А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?
Читая тему придумал параноидальный вариант для истинных джедаев — сделать враппер файловой системы через фьюз например, который бы следил за записями в каталоги и быстро выдавал бы состояние их идентичности. Правда реализовать это будет существенно сложней, но производительность обещает быть существенно больше при большой частоте операции.
Re[2]: Стоит ли использовать erlang для такой задачи?
От:
Аноним
Дата:
14.02.10 06:40
Оценка:
Здравствуйте, LelicDsp, Вы писали:
LD>Эрланг использовать совершенно бессмысленно. Дисковый ввод-вывод вывод у него очень тормозной.
Да что вы говорите?
На недавней задаче он выдавал до 40мб/с при линейном чтение + обработке (с этого диска dd if=big_file of=/dev/null даёт около 100Mb/s)
Re[2]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
FR>Есть подозрение что многозадачность тут совсем не поможет так как быстродействие будет FR>упираться в файловый ввод-вывод.
Ну, как сказать. Асинхронный ввод-вывод тут очень даже кстати будет. Пока файлы читаются можно будет прочитанные сравнивать. Ну, и сравнение может быть разной степени ресурсоемкости. Одно дело тупо сравнить побайтовый, другое дело некий дифференциал рассчитать.
Вот только все эти задачи не из серии ФП — это точно. Тут нужны хорошие библиотеки или низкоуровневый доступ к ОС (читай С).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Стоит ли использовать erlang для такой задачи?
VD>Ну, как сказать. Асинхронный ввод-вывод тут очень даже кстати будет. Пока файлы читаются можно будет прочитанные сравнивать. Ну, и сравнение может быть разной степени ресурсоемкости. Одно дело тупо сравнить побайтовый, другое дело некий дифференциал рассчитать.
Ну для этого настоящая многозадачность не нужна, достаточно ассинхронного IO или легких потоков. Хотя конечно зависит от тяжести вычислительной части задачи, если простое сравнение то оно и в интерпретаторе будет рантаймом делаться.
VD>Вот только все эти задачи не из серии ФП — это точно. Тут нужны хорошие библиотеки или низкоуровневый доступ к ОС (читай С).
Ну если есть нормальные библиотеки без разницы на чем.
Re[4]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
FR>Ну для этого настоящая многозадачность не нужна, достаточно ассинхронного IO или легких потоков.
Ассинхронного IO достаточно. А вот легкие потоки тут ни с какого боку не сдались.
FR>Хотя конечно зависит от тяжести вычислительной части задачи, если простое сравнение то оно и в интерпретаторе будет рантаймом делаться.
+1
И я о том же.
VD>>Вот только все эти задачи не из серии ФП — это точно. Тут нужны хорошие библиотеки или низкоуровневый доступ к ОС (читай С).
FR>Ну если есть нормальные библиотеки без разницы на чем.
Если есть — несомненно (опять же при условии, что сравнение не ресурсоемкая задача). Но вот как раз с этим у подавляющего числа ФЯ задница наблюдается.
Тут самое время порекламировать Nemerle, но для данной задачи C# или Явы хватит за глаза. И даже особых приемуществ не видно будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали: VD>Ассинхронного IO достаточно. А вот легкие потоки тут ни с какого боку не сдались.
По идее, это ведь два ракурса одних яиц (дешевая почти-параллельность).
На эту тему мне недавно вот какие рассуждения на глаза попались, кстати: http://www.planeterlang.org/en/planet/article/How_do_we_kick_our_synchronous_addiction/ (вкратце — легкие потоки лучше асинхронности).
Re[6]: Стоит ли использовать erlang для такой задачи?
Не "почти" тут не катит. Смысл асинхроггого ИО в том, что оно именно что выполняется параллельно в другом потоке ОС, а программа в это время может выполнять другие действия. При этом они работают на разных камнях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали: VD>Не "почти" тут не катит. Смысл асинхроггого ИО в том, что оно именно что выполняется параллельно в другом потоке ОС, а программа в это время может выполнять другие действия. При этом они работают на разных камнях.
Так и легкие потоки в той же степи: пока один заблокирован, другие продолжают работать, и все это может выполняться в одном потоке ОС.
Re[6]: Стоит ли использовать erlang для такой задачи?
VD>>Ассинхронного IO достаточно. А вот легкие потоки тут ни с какого боку не сдались. MC>По идее, это ведь два ракурса одних яиц (дешевая почти-параллельность). MC>На эту тему мне недавно вот какие рассуждения на глаза попались, кстати: http://www.planeterlang.org/en/planet/article/How_do_we_kick_our_synchronous_addiction/ (вкратце — легкие потоки лучше асинхронности).
Это ортогональные вещи.
В питоне есть библиотека greenlet, она позволяет делать разные странные штуки, в том числе легкие (кооперативные) потоки. Асинхронного IO при этом бесплатно не получится.
Есть библиотеки eventlet и gevent, которые реализуют лёгкие потоки и асинхронный IO.
Есть библиотека Twisted, которая реализует только асинхронный IO, но код раньше приходилось писать через макароны колбеков. (сейчас они добавили сахар, который с трудом, но эмулирует легкие потоки)
Re[7]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали: T>Это ортогональные вещи.
Не ортогональные, а тесно связанные. Я бы сказал, разный взгляд на одно и то же.
T>В питоне есть библиотека greenlet, она позволяет делать разные странные штуки, в том числе легкие (кооперативные) потоки. Асинхронного IO при этом бесплатно не получится.
Ессно, потому как если легкие потоки внутрях не реализуют асинхронное IO, блокирующий вызов может остановить их всех.
T>Есть библиотеки eventlet и gevent, которые реализуют лёгкие потоки и асинхронный IO. T>Есть библиотека Twisted, которая реализует только асинхронный IO, но код раньше приходилось писать через макароны колбеков. (сейчас они добавили сахар, который с трудом, но эмулирует легкие потоки)
Вот видишь, это связанные вещи.
Re[7]: Стоит ли использовать erlang для такой задачи?
MC>>По идее, это ведь два ракурса одних яиц (дешевая почти-параллельность). MC>>На эту тему мне недавно вот какие рассуждения на глаза попались, кстати: http://www.planeterlang.org/en/planet/article/How_do_we_kick_our_synchronous_addiction/ (вкратце — легкие потоки лучше асинхронности).
VD>Не "почти" тут не катит. Смысл асинхроггого ИО в том, что оно именно что выполняется параллельно в другом потоке ОС, а программа в это время может выполнять другие действия. При этом они работают на разных камнях.
Смысл асинхронного (неблокирующегося) IO в том, чтобы не блокироваться на вводе или выводе. И для этого есть две схемы:
1) сначала выяснить готова ли ОС выполнить твой read/write/accept прямо здесь и сейчас и сделать этот вызов, когда данные уже есть в буфере ОС/когда буфер для отправки уже свободен/когда клиент уже ждёт в очереди на подключение
2) установить колбек, который ОС позовёт, когда произойдёт нужный IO
На одном камне асинхронный IO тоже отлично работает. Для него даже потоки в ядре не нужны.
Re[8]: Стоит ли использовать erlang для такой задачи?
T>>Это ортогональные вещи. MC>Не ортогональные, а тесно связанные. Я бы сказал, разный взгляд на одно и то же.
T>>В питоне есть библиотека greenlet, она позволяет делать разные странные штуки, в том числе легкие (кооперативные) потоки. Асинхронного IO при этом бесплатно не получится. MC>Ессно, потому как если легкие потоки внутрях не реализуют асинхронное IO, блокирующий вызов может остановить их всех.
В жизни — да, по жизни они идут рядом. И легкие потоки — это единственный известный мне способ сделать асинхронное IO удобным.
Но в теории они решают совершенно несвязанные задачи. Я хотел сказать, что наличие в языке/рантайме одного не гарантирует наличие второго.
Re[9]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали: T>Но в теории они решают совершенно несвязанные задачи.
Эээ, как это несвязанные? А как же ужать много-много логических потоков выполнения (например, много подключений клиента к серверу) в мало-мало потоков ОС (например, в один)?
Re[10]: Стоит ли использовать erlang для такой задачи?
T>>Но в теории они решают совершенно несвязанные задачи. MC>Эээ, как это несвязанные? А как же ужать много-много логических потоков выполнения (например, много подключений клиента к серверу) в мало-мало потоков ОС (например, в один)?
Подключения это как раз не потоки. Их можно (и это самый удобный способ) обрабатывать в отдельных легких потоках.
Как ещё их можно обрабатывать в одном ОС потоке:
#псевдокод
while 1 {
connections_ready = select(open_sockets, READ | WRITE)
for each conn in connections_ready {
data = read(conn)
write(conn, data) # типа echo сервер
}
}
это называется event loop на select и он на самом деле используется в таком количестве программ, что вы будете, наверное, удивлены.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали: T>Подключения это как раз не потоки. Их можно (и это самый удобный способ) обрабатывать в отдельных легких потоках.
Если их удобно обрабатывать в отдельных легких потоках (о чем я и говорил), то это и есть "логические потоки".
T>это называется event loop на select и он на самом деле используется в таком количестве программ, что вы будете, наверное, удивлены.
Это и есть асинхронное IO с коллбеками.
В итоге, ты все-таки со мной согласен, что асинхронное IO и легкие потоки решают одну и ту же задачу. На примере подключений клиентов к серверу — (далее твои слова) можно все делать через select/poll/etc, но прикольнее, когда умный рантайм разрешает выделять столько легких потоков, сколько хочется.
Re[12]: Стоит ли использовать erlang для такой задачи?
T>>это называется event loop на select и он на самом деле используется в таком количестве программ, что вы будете, наверное, удивлены. MC>Это и есть асинхронное IO с коллбеками.
Там не было колбеков это асинхронное IO с ожиданием первого события. С колбеками это что-то типа read(conn, callback) и ядро позовёт эту функцию, когда посчитает нужным. Но это всё неважно.
MC>В итоге, ты все-таки со мной согласен, что асинхронное IO и легкие потоки решают одну и ту же задачу. На примере подключений клиентов к серверу — (далее твои слова) можно все делать через select/poll/etc, но прикольнее, когда умный рантайм разрешает выделять столько легких потоков, сколько хочется.
Да, конечно. В этом полностью согласен. Изначально я придрался к разнице между (есть легкие потоки, нет асинхронного IO), (есть асинхронное IO, нет легких потоков) и (есть и то и другое). Удобный — только последний вариант.
Re[7]: Стоит ли использовать erlang для такой задачи?
T>В питоне есть библиотека greenlet, она позволяет делать разные странные штуки, в том числе легкие (кооперативные) потоки. Асинхронного IO при этом бесплатно не получится. T>Есть библиотеки eventlet и gevent, которые реализуют лёгкие потоки и асинхронный IO. T>Есть библиотека Twisted, которая реализует только асинхронный IO, но код раньше приходилось писать через макароны колбеков. (сейчас они добавили сахар, который с трудом, но эмулирует легкие потоки)
Хорошие легкие потоки должны реализовывать асинхронный ввод вывод, например как для OCaml'овского lwt
Здравствуйте, Temoto, Вы писали:
T>Да, конечно. В этом полностью согласен. Изначально я придрался к разнице между (есть легкие потоки, нет асинхронного IO), (есть асинхронное IO, нет легких потоков) и (есть и то и другое). Удобный — только последний вариант.
Re: Стоит ли использовать erlang для такой задачи?
От:
Аноним
Дата:
17.02.10 09:57
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов. А>Файлов около 10000-20000. А>Размеры каждого каталога порядка ~100Mb. А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.
А>Самый adyaq вариант — распаралелить сравнение каталогов. А>Имеет ли смысл использовать для такой задачи эрланг? А>Как у эрланга обстоит дело с чтением текстовых файлов? А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?
Здравствуйте, Аноним, Вы писали:
А>А готовая утилита подойдет? А>http://www.cis.upenn.edu/~bcpierce/unison/
А>Написана на OCaml, есть исходники, работает очень быстро, кросплатформенная...
Кстати использует lwt.
Re[6]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>1) сначала выяснить готова ли ОС выполнить твой read/write/accept прямо здесь и сейчас и сделать этот вызов, когда данные уже есть в буфере ОС/когда буфер для отправки уже свободен/когда клиент уже ждёт в очереди на подключение
Это какая-то чушь. Я не знаю таких ОС которые отчитывались бы о том, что у них там в кэше, а что еще только планируется прочитать.
T>2) установить колбек, который ОС позовёт, когда произойдёт нужный IO
Вот это — да. Это другое дело. Но для этого нужно иметь библиотеку в которой реализован этот самый асинхронный IO.
T>На одном камне асинхронный IO тоже отлично работает.
Несомненно.
T>Для него даже потоки в ядре не нужны.
А вот это не так. Нет многозадачности, нет и параллельного выполнения. Асинхронный ввод-вывод обычно тесно завязаны на менеджеры задач ОС.
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Mr.Cat, Вы писали:
MC>Так и легкие потоки в той же степи: пока один заблокирован, другие продолжают работать, и все это может выполняться в одном потоке ОС.
Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали: VD>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно.
А эрланг — это тогда кто?
VD>Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки.
Ну я об этом и говорил. За легкими потоками вполне может стоять асинхронный IO и несколько потоков ОС.
Re[9]: Стоит ли использовать erlang для такой задачи?
MC>>Так и легкие потоки в той же степи: пока один заблокирован, другие продолжают работать, и все это может выполняться в одном потоке ОС.
VD>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки.
Насколько мне известно, в эрланге лёгкие *и* вытесняющие потоки. И это не относится к тому, что они ещё и параллельно выполняются на реальных потоках.
Re[9]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки.
Параллельное выполнение не нужно, достаточно уметь усыплять когда поток доходит до любой операции ввода-вывода передать управление другому потоку и возвращать управление исходному потоку только после того как дождется (и дойдет очередь) асинхронной операции ввода-вывода. Конечно все IO операции обернуты и работают только через рантайм легких потоков.
Обычно в этих рантаймах используется пара-другая системных потоков, но это вовсе необязательно, вполне достаточно чтобы система представляла неблокирующее ожидание завершения.
Re[8]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, D. Mon, Вы писали:
DM>Подозреваю, человек намекал на asynchronous workflows. В Немерле они есть?
Нет. Зато в Немерле есть макросы на базе которых аналогичные решения прикручиваются без вмешательства в компилятор.
К тому же asynchronous workflows немного из другой оперы. Асинхронный ввод-вывод в дотнете делается на базе стандартных классов потоков. Они являются обычными объектами дотнета и работать с ними удобнее из языка для которого дотнет родная среда.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Mr.Cat, Вы писали:
VD>>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. MC>А эрланг — это тогда кто?
В Эрланге за переключением следит интерпретатор. К тому же в эрланге есть возможность выполнять часть легих потоков на разных физических потоках. Такая возможность, кстати, появилась относительно не так давно. До этого там параллельное выполнение можно было получить только при запуске разных физических процессов.
VD>>Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки. MC>Ну я об этом и говорил. За легкими потоками вполне может стоять асинхронный IO и несколько потоков ОС.
Асинхронный ввод-вывод может быть реализован и без потоков вообще, если задействованы библиотеки ОС. Только вот внутри себя там используются потоки ОС и прерывания процессоров. Так что легкие потоки тут никаким боком. Тут более уместен другой вопрос. А есть ли библиотеки (написанные на С, по всей видимости) для Эрланга которые реализуют этот самый асинхронный ввод-вывод?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>Насколько мне известно, в эрланге лёгкие *и* вытесняющие потоки.
Насколько известно мне — это не так.
T>И это не относится к тому, что они ещё и параллельно выполняются на реальных потоках.
Это как раз очень даже относится. Для реализации асинхронности на самом языке требуется явное управлением потоками (один ждет, другой работает). Если же используются АПИ ОС, то потоки вообще не причем. Ни легкие, ни тяжелые, так как ожидание производится в потоках ядра.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
FR>Параллельное выполнение не нужно, достаточно уметь усыплять когда поток доходит до любой операции ввода-вывода передать управление другому потоку и возвращать управление исходному потоку только после того как дождется (и дойдет очередь) асинхронной операции ввода-вывода. Конечно все IO операции обернуты и работают только через рантайм легких потоков. FR>Обычно в этих рантаймах используется пара-другая системных потоков, но это вовсе необязательно, вполне достаточно чтобы система представляла неблокирующее ожидание завершения.
Еще раз. Если есть написанная на низкоуровневом языке библиотека асинхронного ВВ, то потоки вообще не нужны. Если же библиотеки нет, то на легких потоках вообще невозможно реализовать асинхронность, так как какой-то поток должен тупо передать управление в ядро и возобновить работу когда блокирующая операция завершится.
Андестенд?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>Речь о select/poll. И первый, насколько я знаю, даже на винде поддерживается. T>select с нулевым таймаутом и будет тот самый "отчёт".
Можно ссылку на виндовую функцию отвечающую за то о чем ты говоришь. А то я пока что даже не понимаю о чем идет речь.
T>Нет, речь о поддержке со стороны ОС.
ОС — это и есть библиотека. Только вот высокоуровневые ЯП далеко не все могут общаться с ОС на ты.
T>В винде это семейство WSAAsync*, WSAEvent* и Overlapped IO.
О винде или линуксе речь не идет. Речь о ФЯ в которых тупо нет библиотек которые бы предоставляли интерфейс к функционалу ОС.
T>Ну, мы можем назвать libc и WinAPI такой библиотекой. Тогда для всего нужна эта библиотека и это неконструктивное ограничение.
libc и WinAPI доступны из С, С++, Дельфи и дотнета. А вот доступны ли они из Эрланга и Хаскеля?
T>Тебе, может, и виднее как оно реализовано, например, на винде. В теории ввод-вывод это не параллельное выполнение. Потому что это вообще не выполнение. Ввод-вывод, по сути, это ожидание сигнала от устройства.
Все верно. Но сигнал должен быть обработан каким-то потоком ОС. Этот обработчик должен установить некоторый флаг в процессе который инициировал запрос на ввод/вывод. Ну, и естественно, языку должна быть доступна либа которая умеет инициировать асинхронный ВВ и умеет считывать этот флаг. Причем либа должна знать о реализации АВВ в разных ОС.
Так вот если же такой библиотеки нет, то единственный способ написать АВВ на языке — использовать потоки которые тупо будут выполнять блокирующий ввод вывод и по его окончании сделают то, что делает системная библиотека.
T>В питоне eventlet реализует асинхронный ввод-вывод на кооперативных потоках и, в частности, select. T>OS потоки для IO только вредны. Но только потому что тяжелы.
Я не знаток Питона, но наслышан о его "многопоточности". Крайне неудачный пример.
T>Спорить тут смысла нет, я просто поправил в чём смысл асинхронного IO. Фактически, придрался к словам; чего тут время терять.
Я вообще-то о другом говорил. Тут меня почему-то уже двое или даже трое понять не могут (или не хотят).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Да хоть десять раз. Я могу все это хоть под DOS где никаких потоков вообще нет устроить.
VD>Устрой. А когда обломаешься, раскажешь нам о причинах .
MS c Win3.x и производители других подобных оболочек почему-то не обломались
Ну DMA и разбивание длительных операций на кусочки никуда ни денутся.
Re[11]: Стоит ли использовать erlang для такой задачи?
VD>О винде или линуксе речь не идет. Речь о ФЯ в которых тупо нет библиотек которые бы предоставляли интерфейс к функционалу ОС.
Даже бедный на библиотеки OCaml такой интерфейс представляет http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
T>>Ну, мы можем назвать libc и WinAPI такой библиотекой. Тогда для всего нужна эта библиотека и это неконструктивное ограничение.
VD>libc и WinAPI доступны из С, С++, Дельфи и дотнета. А вот доступны ли они из Эрланга и Хаскеля?
У них как и у OCaml'а есть FFI как минимум к си, так что все доступно.
Для Ocamla и WinAPI есть и все готовое http://www.speakeasy.org/~hchomsky/ocaml-win32.html
В Хаскеле части винапи по моему даже из коробки доступны.
Re[14]: Стоит ли использовать erlang для такой задачи?
Тоже прибито гвоздями к ОС?
А почему было не сделать астрактную библиотеку которая на разных платформах использовала бы специфичный для них АПИ?
В дотнете и моно именно так и сделали.
FR>В Хаскеле части винапи по моему даже из коробки доступны.
Ну, про Хаскель вроде как и говорили, что в нем это не проблема (как я понял из коробки).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Стоит ли использовать erlang для такой задачи?
VD>Ошибашся. Асинхронного ВВ не было ни в досе, ни в 16-битной винде.
Угу, но звук в фоне игрался, и даже были утилиты для фонового копирования файлов
FR>>Ну DMA и разбивание длительных операций на кусочки никуда ни денутся.
VD>DMA тут вообще не причем.
Очень даже причем.
Re[11]: Стоит ли использовать erlang для такой задачи?
T>>Речь о select/poll. И первый, насколько я знаю, даже на винде поддерживается. T>>select с нулевым таймаутом и будет тот самый "отчёт".
VD>Можно ссылку на виндовую функцию отвечающую за то о чем ты говоришь. А то я пока что даже не понимаю о чем идет речь.
Пожалуйста. http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx
T>>Ну, мы можем назвать libc и WinAPI такой библиотекой. Тогда для всего нужна эта библиотека и это неконструктивное ограничение.
VD>libc и WinAPI доступны из С, С++, Дельфи и дотнета. А вот доступны ли они из Эрланга и Хаскеля?
Практически во всех языках есть т.н. FFI (foreign function interface), позволяющие заюзать самые стрёмные библиотеки, включая ядро. В хаскеле и эрланге это есть, да.
И следущим аргументом (в уже непонятно каком споре) будет отсутствие каких-то биндингов в стандартной поставке?
T>>Тебе, может, и виднее как оно реализовано, например, на винде. В теории ввод-вывод это не параллельное выполнение. Потому что это вообще не выполнение. Ввод-вывод, по сути, это ожидание сигнала от устройства.
VD>Все верно. Но сигнал должен быть обработан каким-то потоком ОС.
Сигнал должен быть обработан ядром. Почему именно потоком? Есть же однопоточный DOS. Железо его прервало, он обработал сигнал: поставил флаг и как-то там сообщил активной программе. АВВ есть, потоков нет.
VD>Этот обработчик должен установить некоторый флаг в процессе который инициировал запрос на ввод/вывод. Ну, и естественно, языку должна быть доступна либа которая умеет инициировать асинхронный ВВ и умеет считывать этот флаг. Причем либа должна знать о реализации АВВ в разных ОС.
VD>Так вот если же такой библиотеки нет, то единственный способ написать АВВ на языке — использовать потоки которые тупо будут выполнять блокирующий ввод вывод и по его окончании сделают то, что делает системная библиотека.
Ну если так низко копать, то да, конечно, какая-то поддержка АВВ (как минимум, способ дёрнуть ядро) в языке должна быть. Ну так во всех и есть. К чему ты клонишь?
T>>В питоне eventlet реализует асинхронный ввод-вывод на кооперативных потоках и, в частности, select. T>>OS потоки для IO только вредны. Но только потому что тяжелы.
VD>Я не знаток Питона, но наслышан о его "многопоточности". Крайне неудачный пример.
Влад, просто жесть уже началась. Аналог: "В винде дорогие процессы, поэтому многозадачное программирование на винде — неудачный пример." Аргументация достойная кого?
Неудачный потому что демонстрирует возможность того, что ты опровергал выше?
T>>Спорить тут смысла нет, я просто поправил в чём смысл асинхронного IO. Фактически, придрался к словам; чего тут время терять.
VD>Я вообще-то о другом говорил. Тут меня почему-то уже двое или даже трое понять не могут (или не хотят).
Я думал, что мы вот это обсуждаем:
Не "почти" тут не катит. Смысл асинхроггого ИО в том, что оно именно что выполняется параллельно в другом потоке ОС, а программа в это время может выполнять другие действия.
и моя позиция (с доказательствами) в том, что смысл АВВ несколько более абстрактен: просто не блокироваться на IO. Кажется (я уже не уверен) мы спорим о том, обязательно ли тут нужны ОС потоки.
Можно представить, что он "выполняется в другом потоке ОС", если так проще понять АВВ. Я придрался к тому, что 1) ввод-вывод не выполняется, его ждут 2) ОС потоки для этого не нужны (даже если в каких-то ядрах АВВ реализован через потоки).
Re[13]: Стоит ли использовать erlang для такой задачи?
FR>>Для Ocamla и WinAPI есть и все готовое http://www.speakeasy.org/~hchomsky/ocaml-win32.html
VD>Тоже прибито гвоздями к ОС? VD>А почему было не сделать астрактную библиотеку которая на разных платформах использовала бы специфичный для них АПИ? VD>В дотнете и моно именно так и сделали.
Эта библиотека называется POSIX, ей много-много лет и select как раз оттуда.
Re[13]: Стоит ли использовать erlang для такой задачи?
Традиция
Все кроме fork и еще чего-то специфичного работает и в Windows.]
Просто Ocaml очень сильно никс ориентированный.
FR>>У них как и у OCaml'а есть FFI как минимум к си, так что все доступно.
VD>ОК. Тогда остается только один вопрос. Сделали такую библиотеку или нет.
Нет эта библиотека просто очень низкоуровневая, тот же модуль Unix уровнем повыше.
VD>А почему было не сделать астрактную библиотеку которая на разных платформах использовала бы специфичный для них АПИ?
Ты же спрашивал про низкоуровневый доступ.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали: VD>>>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. MC>>А эрланг — это тогда кто? VD>В Эрланге за переключением следит интерпретатор.
Но потоки-то от этого тяжелее не стали
VD>Асинхронный ввод-вывод может быть реализован и без потоков вообще, если задействованы библиотеки ОС. Только вот внутри себя там используются потоки ОС и прерывания процессоров. Так что легкие потоки тут никаким боком.
Мне кажется, в этой точке мы достигли терминологического коллапса. Мой изначальный тезис был, что асинхронный ВВ и легкие потоки — два взгляда на одну задачу использования минимума потоков ОС с максимумом профита.
VD>Тут более уместен другой вопрос. А есть ли библиотеки (написанные на С, по всей видимости) для Эрланга которые реализуют этот самый асинхронный ввод-вывод?
Внезапно, я совершенно себе не представляю, как работает ввод-вывод в эрланге. Для легких потоков ВВ блокирующий — это понятно. А вот как с ВВ поступает сам рантайм — я хз. Слышал краем уха, что в итоге всем ВВ в асинхронном режиме занимается отдельный (или ограниченное число отдельных) ОС-поток рантайма.
Re[9]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
DM>>Подозреваю, человек намекал на asynchronous workflows. В Немерле они есть?
VD>Нет. Зато в Немерле есть макросы на базе которых аналогичные решения прикручиваются без вмешательства в компилятор.
Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
VD>К тому же asynchronous workflows немного из другой оперы. Асинхронный ввод-вывод в дотнете делается на базе стандартных классов потоков. Они являются обычными объектами дотнета и работать с ними удобнее из языка для которого дотнет родная среда.
Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, D. Mon, Вы писали:
DM>>Подозреваю, человек намекал на asynchronous workflows. В Немерле они есть?
VD>Нет. Зато в Немерле есть макросы на базе которых аналогичные решения прикручиваются без вмешательства в компилятор.
asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions),
тоже без вмешательства в компилятор.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, achmed, Вы писали:
A>asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions), A>тоже без вмешательства в компилятор.
Противоречишь сам себе. Если есть поддержка чего либо, то без вмешательства в компилятор не обошлось.
В случае же макросов эту самую поддержку можно реализовать действительно без вмешательства в компилятор. Или можно обойтись без нее и реализовать конкретную задачу (вроде поддержки паттерна работы с многопоточностью) напрямую.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, D. Mon, Вы писали:
DM>Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
Где, "там"? И можно услышать твое определение понятия "аналогичный"?
От себя замечу, что макросам по фигу что на них будут реализовывать. Главное, что если в языке чего-то нет, то это можно сделать не обращаясь к разработчикам языка и не разводя бодягу.
DM>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Стоит ли использовать erlang для такой задачи?
Что "Пожалуйста" — это описание функции работы с сокетами. В Винде с файлами невозможно работать через АПИ сокетов.
T>И следущим аргументом (в уже непонятно каком споре) будет отсутствие каких-то биндингов в стандартной поставке?
Какой спор? Вопрос только в том есть ли в Эрланг возможность осуществления АВВ из коробки, и если нет, то сколь трудно создать такое решение.
T>Сигнал должен быть обработан ядром. Почему именно потоком?
Потому, что ядро это всего лишь область памяти доступная в некотором привилегированном кольце защиты. А выполнять код находящийся в этой памяти может только поток. По крайней мере в Винде это так.
T> Есть же однопоточный DOS. Железо его прервало, он обработал сигнал: поставил флаг и как-то там сообщил активной программе. АВВ есть, потоков нет.
В одноклеточном досе АВВ не было. Во время работы драйвера выполнение программы полностью останавливалось. На то это и называется прерывание.
T>Ну если так низко копать, то да, конечно, какая-то поддержка АВВ (как минимум, способ дёрнуть ядро) в языке должна быть. Ну так во всех и есть. К чему ты клонишь?
Ну, так пока что никто так и не указал есть ли в эрланге АВВ из коробки и если нет, то можно ли его реализовать учитывая, что потоки то кооперативные.
Обсуждений море, а четкого ответа нет. А это в сущности ответ на вопрос уместно ли применение эрланга в данной задаче, т.е. ответ на вопрос темы.
T>Влад, просто жесть уже началась. Аналог: "В винде дорогие процессы, поэтому многозадачное программирование на винде — неудачный пример." Аргументация достойная кого?
Я не могу гворить за симтему с корой знаком на уровне начинающего пользователя. Но от того же FR слышал, что в Питоне с параллелизмом труба.
T>Неудачный потому что демонстрирует возможность того, что ты опровергал выше?
А что я опровергал?
T>и моя позиция (с доказательствами) в том, что смысл АВВ несколько более абстрактен: просто не блокироваться на IO. Кажется (я уже не уверен) мы спорим о том, обязательно ли тут нужны ОС потоки.
А что толку с абстрактности когда ехать нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Стоит ли использовать erlang для такой задачи?
DM>>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
VD>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
на каких языках работать с асинхронными методами проще чем в F# ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[13]: Стоит ли использовать erlang для такой задачи?
T>>И следущим аргументом (в уже непонятно каком споре) будет отсутствие каких-то биндингов в стандартной поставке? VD>Какой спор? Вопрос только в том есть ли в Эрланг возможность осуществления АВВ из коробки, и если нет, то сколь трудно создать такое решение.
Сетевой — точно из коробки.
На freenode #erlang сказали, что файловый тоже асинхронный, либо через неблокирующиеся вызовы ядра, либо через отдельные ОС треды, в любом случае, для программиста это прозрачно.
То есть, технически, да (и это само собой разумеется), Erlang для этой задачи подходит. Другой вопрос, что ни от его АВВ, ни от параллелизма тут большого выигрыша не будет, скорее всего в скорость диска всё упрётся.
T>>Влад, просто жесть уже началась. Аналог: "В винде дорогие процессы, поэтому многозадачное программирование на винде — неудачный пример." Аргументация достойная кого? VD>Я не могу гворить за симтему с корой знаком на уровне начинающего пользователя. Но от того же FR слышал, что в Питоне с параллелизмом труба.
С параллелизмом в питоне и руби полный п-дец. А с АВВ и лёгкими потоками всё нормально.
T>>Неудачный потому что демонстрирует возможность того, что ты опровергал выше?
VD>А что я опровергал?
Ну, не опровергал, отрицал что-ли... утверждал невозможность.
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, cadet354, Вы писали:
VD>>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
C>на каких языках работать с асинхронными методами проще чем в F# ?
Долго искал связь между моими словами и данным вопросом. Потом долго пытался понять кто такие асинхронные методы и чем они отличаются от обычных. Ответов так и не наше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>Сетевой — точно из коробки.
Кто такой "Сетевой"? Вроде как речь шла о сравнении файлов.
T>На freenode #erlang сказали, что файловый тоже асинхронный, либо через неблокирующиеся вызовы ядра, либо через отдельные ОС треды, в любом случае, для программиста это прозрачно.
Обычно когда на вопрос могут ответить да или нет, то отвечают да или нет. И если на такой вопрос начинают давать развернутый ответ, то... .
T>То есть, технически, да (и это само собой разумеется), Erlang для этой задачи подходит. Другой вопрос, что ни от его АВВ, ни от параллелизма тут большого выигрыша не будет, скорее всего в скорость диска всё упрётся.
Вот это уже более конкретно.
T>Ну, не опровергал, отрицал что-ли... утверждал невозможность.
Да, ну?
Я всего лишь пытался людей подвигуть в конструктивное русло. Если нужные возможности есть, то хорош бы просто указать на них. Если нет, то описать как их достичь (хотя эту уже повод задуматься о том насколько инструмент подходит для решения задачи).
T>
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
T>Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
Да, ну? А может реализованы в библиотеке которая написана на низкоуровневом языке?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Стоит ли использовать erlang для такой задачи?
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
T>>Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
VD>Да, ну? А может реализованы в библиотеке которая написана на низкоуровневом языке?
При отсутствии более эффективных библиотек, eventlet прозрачно использует свой микрослой без низкоуровневых языков.
Откуда эта убеждённость, зачем спор? У тебя был неудачный опыт по повооду АВВ без Си что-ли?
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, achmed, Вы писали:
A>>asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions), A>>тоже без вмешательства в компилятор.
VD>Противоречишь сам себе. Если есть поддержка чего либо, то без вмешательства в компилятор не обошлось.
Computation Expressions это изначально часть языка F#
VD>В случае же макросов эту самую поддержку можно реализовать действительно без вмешательства в компилятор. Или можно обойтись без нее и реализовать конкретную задачу (вроде поддержки паттерна работы с многопоточностью) напрямую.
А на Nemerle можно сделать поддержку синтаксического сахара для монад, который в Haskell называется "do синтаксис"?
Re[13]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, cadet354, Вы писали:
VD>>>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
C>>на каких языках работать с асинхронными методами проще чем в F# ?
VD>Долго искал связь между моими словами и данным вопросом. Потом долго пытался понять кто такие асинхронные методы и чем они отличаются от обычных. Ответов так и не наше.
странно, когда это написал D.Mon ты понял о чем речь
DM>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
там ты просто ушел от ответа, т.к. в F# работать с APM (надеюсь этот акроним расшифровывать не надо) действительно очень, очень удобно:
open System
open System.Net
open Microsoft.FSharp.Control.WebExtensions
let http url =
async { let req = WebRequest.Create(Uri url)
use! resp = req.AsyncGetResponse()
use stream = resp.GetResponseStream()
use reader = new StreamReader(stream)
let contents = reader.ReadToEnd()
return contents }
let sites = ["http://www.bing.com";
"http://www.google.com";
"http://www.yahoo.com";
"http://www.search.com"]
let htmlOfSites =
Async.Parallel [for site in sites -> http site ]
|> Async.RunSynchronously
где в .NET удобнее?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, achmed, Вы писали:
A>Computation Expressions это изначально часть языка F#
Во как? А я их вроде бы в 2007 году не видел. Мне показалось?
А так да. Все что гвоздями прибито к компилятору становится частью языка.
A>А на Nemerle можно сделать поддержку синтаксического сахара для монад, который в Haskell называется "do синтаксис"?
Естественно, да. Только не очень нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Он не вдохновлен. Он и есть ОКамл с расширениями и адптацией.
Не только с расширениями, но и с сужениями
Не совсем понятно только, зачем разработчики F# так много выкинули, ведь адаптировать к NET наверняка можно было и обычный
OCaml, например порт OCaml'а на Java http://ocamljava.x9c.fr/index.html даже байт код генерированный ocamlc выполняет и кроме
того умеет компилировать в ява байт код.
Re[14]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
FR>Не только с расширениями, но и с сужениями FR>Не совсем понятно только, зачем разработчики F# так много выкинули, ведь адаптировать к NET наверняка можно было и обычный FR>OCaml, например порт OCaml'а на Java http://ocamljava.x9c.fr/index.html даже байт код генерированный ocamlc выполняет и кроме FR>того умеет компилировать в ява байт код.
Наверно были оснвоания. Препроцессор не работает потому что F# стал зависим от отступов, как я понимаю. А в остальном наверно — это следствие дотнетных дженериков.
Кстати, что из интересного выбросили?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Стоит ли использовать erlang для такой задачи?
Ну насколько я знаю основное это ML — модули и все что с ними связанно, потом OCaml объекты, препроцессор, полиморфные варианты и еще вроде что-то по мелочи.
Re[16]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, achmed, Вы писали:
A>>Computation Expressions это изначально часть языка F#
VD>Во как? А я их вроде бы в 2007 году не видел. Мне показалось?
Не в первой версии языка, но тем не менее, их добавили в версии 1.9.2 как обобщение sequense exressions.
Смысл в том, что для добавления async expression или чего то подобного сейчас не нужно менять компилятор F#.
Re[3]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Code Digger, Вы писали:
CD>Но вообще-то сомневаюсь, что подойдёт. У Эрланга блокирующие вызовы системных ф-ий, AFAIK, так что его треды Вас не спасут.
Когда Вы последний раз видели Erlang? Наверно, это был R10 или даже R9? На дворе давно R13.
CD> Треды нужны нативные. Так что и с Пёрлом вопрос. Берите Хаскель, одним словом. ;)
Вы точно читали его документацию? Ключик +A у команды erl видели?
The God is real, unless declared integer.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
VD>>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. Параллельного выполнения при этом быть не может. Точнее может только если для выполнения задействуются реальные потоки. FR>Параллельное выполнение не нужно, достаточно уметь усыплять когда поток доходит до любой операции ввода-вывода передать управление другому потоку и возвращать управление исходному потоку только после того как дождется (и дойдет очередь) асинхронной операции ввода-вывода.
Если ты говоришь про scheduler activations, то такой вид наблюдается только со стороны userland. В ядре (или в поддержке в userland) всё равно нужно уметь создавать нити для тех действий, которые не представляются в виде машины состояний.
С другой стороны, scheduler activations показали себя настолько сложными в реализации, что сейчас все от них и схемы M:N сбежали как от огня. Проще удешевить видимые ядру нити. Это грустный факт, но на сейчас неизбежный.
The God is real, unless declared integer.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, netch80, Вы писали:
N>Если ты говоришь про scheduler activations, то такой вид наблюдается только со стороны userland. В ядре (или в поддержке в userland) всё равно нужно уметь создавать нити для тех действий, которые не представляются в виде машины состояний.
N>С другой стороны, scheduler activations показали себя настолько сложными в реализации, что сейчас все от них и схемы M:N сбежали как от огня. Проще удешевить видимые ядру нити. Это грустный факт, но на сейчас неизбежный.
Я имел в виду не системные, а кооперативные легковесные потоки например http://ocsigen.org/lwt/
Re[14]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, D. Mon, Вы писали:
DM>Влад, ты бы на даты этих ссылок посмотрел, археолог ты наш. А лучше познакомься с языками, о которых пытаешься говорить. DM>По факту, если посмотреть на современный код на F#, он на окамл совсем не похож, там и синтаксис другой (по умолчанию с отступами), и система типов, и вообще почти все. А если взять любую программу на окамле побольше hello world'a, в ней точно будут функторы из стандартной библиотеки (хотя бы Map), и она уже F#-ом не скомпилится. Если по началу между F# и окамлом было что-то общее — базовый ML, то с переходом на новый синтаксис и этого не осталось.
Похоже я тоже кое-что проспал
С функторами да не перекомпилируешь, но вроде же по остальному есть ключики у F# для совместимости.
А вообще люди пишут так что компилируется и OCaml'ом и F#'ом http://coherentpdf.com/blog/?p=25
Re[15]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, FR, Вы писали:
FR>С функторами да не перекомпилируешь, но вроде же по остальному есть ключики у F# для совместимости.
Я больше про языки говорю, чем про возможность компилятора F# с нужными ключиками скомпилить немного базового МЛя. Наверняка и компилятор немерле с некоторыми ключиками (а точнее макросами) может компилировать базовый Паскаль.
Re[16]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, D. Mon, Вы писали:
DM>Я больше про языки говорю, чем про возможность компилятора F# с нужными ключиками скомпилить немного базового МЛя. Наверняка и компилятор немерле с некоторыми ключиками (а точнее макросами) может компилировать базовый Паскаль.
Здравствуйте, Mr.Cat, Вы писали:
MC>Так и легкие потоки в той же степи: пока один заблокирован, другие продолжают работать, и все это может выполняться в одном потоке ОС.
Не совсем. Ерланговские легкие потоки отображены на системные настоящие потоки, и этих настоящих потоков запускается по числу процессорных ядер в системе. Если один из них "закажет" операцию дискового ввода-вывода, он заблокируется до ее окончания (я немного утрирую, не учитывая работу кеша). Таким образом, вам не удастся "накидать" одновременно больше запросов ввода-вывода, чем есть ядер в системе. А вот если воспользоваться асинхронным вводом-выводом, вы можете накидать их, сколько хотите, и системный i/o scheduler сможет упорядочить их в оптимальном, с точки зрения диска, порядке (с учетом движения головки диска).
Re[14]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, achmed, Вы писали:
VD>>Во как? А я их вроде бы в 2007 году не видел. Мне показалось?
A>Не в первой версии языка, но тем не менее, их добавили в версии 1.9.2 как обобщение sequense exressions.
Значит не показалось?
A>Смысл в том, что для добавления async expression или чего то подобного сейчас не нужно менять компилятор F#.
Да нет в этом никакого смысла. Взяли и залепили в компилятор синтаксический сахар для одного решения. Для ругих не будет. Более того шаг влево, шаг в право — расстерел (ничего не сделаешь). Как, скажем, ограничить асинхонность некоторого участка кода ровно 3 потоками?
Когда есть макросы, таких проблем не существует, так как всегда можно написать свою версию библиотеки. Кроме того развитие библиотеки идет намного быстрее и безболезеннее нежели фичи языка. Так что если есть какие-то недоработки, их можно легко устранить и выпустить новую версию библиотеки которая будет работать с тем же самым языком и тем же самым компилятором.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, achmed, Вы писали:
VD>>>Во как? А я их вроде бы в 2007 году не видел. Мне показалось?
A>>Не в первой версии языка, но тем не менее, их добавили в версии 1.9.2 как обобщение sequense exressions.
VD>Значит не показалось?
Почему для одного, на монадах много чего можно сделать, например FParsec — A Parser Combinator Library for F#.
VD>Для ругих не будет. Более того шаг влево, шаг в право — расстерел (ничего не сделаешь). Как, скажем, ограничить асинхонность некоторого участка кода ровно 3 потоками?
Не понял, что имеется в виду и для чего это нужно?
VD>Когда есть макросы, таких проблем не существует, так как всегда можно написать свою версию библиотеки. Кроме того развитие библиотеки идет намного быстрее и безболезеннее нежели фичи языка. Так что если есть какие-то недоработки, их можно легко устранить и выпустить новую версию библиотеки которая будет работать с тем же самым языком и тем же самым компилятором.
Разве макрос не может зависеть от версии компилятора?
Re[2]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, <Аноним>, Вы писали:
А>Читая тему придумал параноидальный вариант для истинных джедаев — сделать враппер файловой системы через фьюз например, который бы следил за записями в каталоги и быстро выдавал бы состояние их идентичности. Правда реализовать это будет существенно сложней, но производительность обещает быть существенно больше при большой частоте операции.
как Тузик грелку. Если посчастливилось оказаться в Винде, то практически вся задача может свестись к FindFirstChangeNotification+FindNextChangeNotification или ReadDirectoryChangesW
P.S. Что только люди не придумают порой, ради самого факта программирования. Сами недавно собирались наколбасить мегатонны С++ кода, когда следовало просто взять другой язык.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Вирт был бы в шоке, если бы узнал об этом. 
