Здравствуйте, Sinclair, Вы писали:
S>Давайте покажем какой-нибудь фреймворк для мегапараллелизма а-ля Erlang, или более удобный аналог BLToolkit, или фреймворк для построения WPF приложений, или еще для чего-нибудь такого, чтобы мировая общественность поняла: вот он, свет новых знаний.
Вот сделать бы выделенное, было бы реально круто! Только боюсь поверх .net это нереально реализовать Только если .net сам не вырастет до такого уровня.
Здравствуйте, yumi, Вы писали: Y>Вот сделать бы выделенное, было бы реально круто! Только боюсь поверх .net это нереально реализовать Только если .net сам не вырастет до такого уровня.
Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка, никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка, никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.
а что хочется от Erlang на .net ?
Лично мне не хватает actor model, и ОТP+Mnesia, и совсем не понятно чем может помочь мне в этом LCG.
Здравствуйте, Sinclair, Вы писали:
S>Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка, > никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.
Здравствуйте, Didro, Вы писали:
D>Мне тогда его аргуметы показались достаточно убительными, не думаю, что сейчас что-нибудь изменилось.
Я так понял, что описанные проблемы всего лишь не позволят сделать систему с performance-характеристиками настоящего эрланга.
Тем не менее, вполне можно получить приемлемо прикольную систему, в которой поддерживается высокий уровень параллелизма.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я так понял, что описанные проблемы всего лишь не позволят сделать систему с performance-характеристиками настоящего эрланга. S>Тем не менее, вполне можно получить приемлемо прикольную систему, в которой поддерживается высокий уровень параллелизма.
На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM. Соответственно в .NET легковесные потоки будут уже совсем другими нежели легковесные потоки Эрланга.
Здравствуйте, Didro, Вы писали: D>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM. Соответственно в .NET легковесные потоки будут уже совсем другими нежели легковесные потоки Эрланга.
Честно признаюсь, я в ерланге не великий гуру. И даже особенной потребности в нем на дотнете не испытываю. Я его привел только как пример того, куда можно было бы копнуть в рамках демонстрации мощи Nemerle по созданию фреймворков.
Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega. Или посмотрим на этот, как его, фреймворк параллелизации и асинхронного выполнения, который сейчас народ на втором вроде шарпе точит, и сделаем его с более человеческим лицом.
Чтобы я мог писать как бы синхронный код, а он превращался автоматически в асинхронный. То есть после окончания async operation продолжалось исполнение моего кода, так же как в случае blocking call, но его мог исполнять другой поток. Это бы позволило значительно хардкорнее оптимизировать работу с пулом потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Didro, Вы писали:
D>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.
Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega.
А макросы для параллелизма на join-calculus, как в Comega, в Nemerle есть. Я, правда, не знаю, насколько они пригодны для использования.
using Nemerle.IO;
using Nemerle.Concurrency;
namespace Test
{
class RendezVous
{
class Thunk
{
[ChordMember]
public Reply (j : int) : void;
public Wait () : int
chord {
| Reply => j
}
}
public f (i : int) : int
{
def t = Thunk ();
af (i, t);
t.Wait ()
}
[ChordMember]
private af (i : int, t : Thunk) : void;
public g (j : int) : int
chord {
| af =>
t.Reply (j);
i
}
}
module Main
{
Main () : void
{
def rv = RendezVous ();
async
{
def i = rv.f (3);
assert (i == 13)
}
async
{
def i = rv.g (13);
assert (i == 3)
}
}
}
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Didro, Вы писали:
D>>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.
AVK>Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.
О, полгода назад я искал зеленые потоки, помня твои сообщения. Поверил тебе, пнимаешь. И где она, эта реализация? Да нет ее. Весь мир ее ждет, чтоб наконец зажить по человечески и перестать думать о тредпулах и явных конечных автоматах. Можно — почему никто не напишет? То что есть сейчас, и удалось найти — зеленые потоки делаются хаком и работают на файберах. Говно полное, простите. На С++ проще писать, там хотя бы файберы без проблем оборачиваются.
А раз этого нет, то какая yf ghfrnbrt разница, что там в теории заложено в CLR?
<skipped/>
S>Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega. Или посмотрим на этот, как его, фреймворк параллелизации и асинхронного выполнения, который сейчас народ на втором вроде шарпе точит, и сделаем его с более человеческим лицом. S>Чтобы я мог писать как бы синхронный код, а он превращался автоматически в асинхронный. То есть после окончания async operation продолжалось исполнение моего кода, так же как в случае blocking call, но его мог исполнять другой поток. Это бы позволило значительно хардкорнее оптимизировать работу с пулом потоков.
let links_async (requestUriString:string) =
async {
let request = WebRequest.Create(requestUriString)
let! response = request.AsyncGetResponse()
let reader = new StreamReader(response.GetResponseStream())
let! html = reader.AsyncReadToEnd()
let links = get_links html
return requestUriString, links |> Seq.length
}
Func<string, Async<Tuple<string, int>>> links_async = requestUriString =>
from _ in AsyncExtensions.StartWorkflow
let request = WebRequest.Create(requestUriString)
from response in request.AsyncGetResponse()
let reader = new StreamReader(response.GetResponseStream())
from html in reader.AsyncReadToEnd()
let links = get_links(html)
select new Tuple<string, int>(requestUriString, links.Count());
Здравствуйте, VladD2, Вы писали:
G>>А раз этого нет, то какая yf ghfrnbrt разница, что там в теории заложено в CLR?
VD>Э... согласен со всеми рассуждениями, но вопрос один воникает... Ты что на дотнет перешел ?
Влад, я наемный менеджер, и делаю то, что требуется конкретной организации . Мне просто нельзя иметь предрассудки . Скажать, что я перешел на .NET — не вполне корректно . Подробнее:
Выбирали платформу для прикладного скриптинга. Желательно, чтобы из скрипта был хороший интероп, скажем, с COM. И надо было, чтобы скрипты выполнялись для тысяч потоков. .NET с грин тредами бы вполне прокатил, как лучший вариант. Однако он отпал, потому, что как оказалось, никаких грин тредов там на самом деле нет. Осталось — поднимать скриптовые машины из файберов из С++, как и хотели изначально. Из машин — spidermonkey, и старый добрый windows scripting host.
Вообще же, .NET весьма хороший вариант для миграции с С++ под вендой. Потому, что у него хороший интероп на венде, потому, что снимает очень много гемора в сравнении с С++, скажем, при разработке гуя, и потому, что можно смешивать с уже написанным С++ и COM, не выбрасывая старого кода, а мигрируя постепенно.
И потому, что хорошего С++ программиста стало очень сложно найти. Все реже и реже хотят хорошие программисты ковыряться с С++. Да и начинающие предпочитают более свежий C#, потому что модно. Рожу кривят. А рынок руда сейчас сам знаешь какой. Ну, до кризиса был.
D>Func<string, Async<Tuple<string, int>>> links_async = requestUriString =>
D> from _ in AsyncExtensions.StartWorkflow
D> let request = WebRequest.Create(requestUriString)
D> from response in request.AsyncGetResponse()
D> let reader = new StreamReader(response.GetResponseStream())
D> from html in reader.AsyncReadToEnd()
D> let links = get_links(html)
D> select new Tuple<string, int>(requestUriString, links.Count());
D>
но даже эти умельцы признают, что не все так хорошо:
For example, there are several things that cannot be done through LINQ expressions such as the following:
* if/then/else
* while loops
* try/catch/finally
* methods that return void
These above constructs don't have a 1 to 1 mapping with LINQ. As a result, our code may have to look significantly different than the F# code that we'd write.
P.S. Вот почему на "птичем" языке это возможно (я про F#), а в майнстриме C# нет,
какую-ту хрень типа dynamics добавляют.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Didro, Вы писали:
D>>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.
AVK>Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.
Что такое "зелёные потоки"? Мне гугел в основном про катаклизмы пишет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Здравствуйте, Gaperton, Вы писали:
G>О, полгода назад я искал зеленые потоки, помня твои сообщения. Поверил тебе, пнимаешь. И где она, эта реализация?
А я никогда готовой реализации и не обещал. Я всего лишь говорил о том, что возможность эта предусмотрена как со стороны CLR Host (создание потоков абстрагировано), так и со стороны FCL (класс Thread начиная с 1.1 не завязан на ID аппаратного потока).
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department.