Здравствуйте, IT, Вы писали:
IT>Давай на примерах. Допустим у нас есть простая форма с двумя TextBoxes и одной кнопкой. По кнопке запускается длительный процесс, который в качестве параметра берёт текст из первого бокса, а результат помещает во второй.
Просвятите пожалуйста про Invoke(): метод AfterLongProcess() выполнится в потоке UI (там где button1_Click2 отработал) или в вызванном потоке? Наверное всё-таки в UI иначе зачем огород городить. Почему нельзя здесь же кинуть MessageBox об исключении? Или это просто для сигнализации о том что в _result невалидная информация? IT>
Совковая лопата опущена
IT>А теперь пофантазируем, что мог быть сделать катарпиллер. Допустим, у нас имелась бы возможность сказать компилятору, например, с помощью атрибутов, что доступ к объектам наследникам класса Control может осуществлятся только из потока UI. Предположим также, что у нас есть некая языковая конструкция, которая указывает компилятору, что определённая часть кода должна выполняться в новом потоке. Вот как мог бы выглядеть гипотетический код:
IT>
textBox2.Text = LongProcess(textBox1.Text); — это в каком потоке выполняется? А если в это время из основного потока что-нить сюда запишут? Ах да, "доступ к объектам наследникам класса Control может осуществлятся только из потока UI", а тогда что-за поток мы создали в newthread ? В этом же новом потоке мы легко закрываем waitForm. А что тогда мешало нам сделать это в LongProcessThread() ? И сообщение об исключении там же кинуть.
Кстати newthread вызывается до waitForm.ShowDialog() ? А если он и отработает раньше и waitForm.Close() вызовет раньше ?
В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется. Возможно для более высокоуровнего программирования это и найдёт своё применение, а так —
А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.
VladD2 wrote: > C>Во-первых, никто не мешает запустить ДВЕ копии интерпретатора Эрланга, > C>на разных процессорах и связать их как угодно (в том числе копии могут > C>быть на других машинах). Это УЖЕ работает. > Толку то? Еще раз, последний, сама ОС не повзволят использовать 80 > процессоров одновременно. Больше я на подобные вопрсы не отвечаю.
Слив засчитан.
SGI Altix 4700 incorporates the shared-memory NUMAflex™ architecture,
which simplifies software development, workload management and system
administration. It supports up to 512 processors under one instance
of Linux and as much as 128TB of globally shared memory. Supporting
these powerful capabilities is the NUMAlink™ interconnect, which leads
the industry in bandwidth and latency for superior performance on
cluster applications. The SGI Altix 4700 represents a versatile solution
for shared or distributed memory applications of any scale.
Sun Niagara вполне себе неплохо живет с 32 ядрами.
Здравствуйте, Mazay, Вы писали:
M>Просвятите пожалуйста про Invoke():
Invoke выглядит примерно так:
public delegate void InvokeDelegate();
public void Invoke(InvokeDelegate call)
{
if (InvokeRequired)
base.Invoke(call);
else
call();
}
M>метод AfterLongProcess() выполнится в потоке UI (там где button1_Click2 отработал) или в вызванном потоке? Наверное всё-таки в UI иначе зачем огород городить.
Точно.
M>Почему нельзя здесь же кинуть MessageBox об исключении?
Потому что MessageBox — это тоже UI.
M>Совковая лопата опущена
Ы?
M>textBox2.Text = LongProcess(textBox1.Text); — это в каком потоке выполняется? А если в это время из основного потока что-нить сюда запишут? Ах да, "доступ к объектам наследникам класса Control может осуществлятся только из потока UI",
Мне нравится как ты сам себе задаёшь вопросы и сам же на них отвечаешь
M>а тогда что-за поток мы создали в newthread ?
New thread.
M>В этом же новом потоке мы легко закрываем waitForm.
Внимательно почитай моё сообщение. Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".
M>В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется.
Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.
M> Возможно для более высокоуровнего программирования это и найдёт своё применение, а так —
M> А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.
Мьютексы то тут причём?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
M>>Почему нельзя здесь же кинуть MessageBox об исключении? IT>Потому что MessageBox — это тоже UI.
А в последнем "гипотетичеком" варианте этот самый UI вызывается вовсе не в UI'шном потоке.
M>>Совковая лопата опущена IT>Ы?
Это я про вариант с замыканиями.
IT>Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".
Я хочу сказать что очень сомневаюсь в полезности этих гипотетических возможностей компилятора:
Допустим, у нас имелась бы возможность сказать компилятору, например, с помощью атрибутов, что доступ к объектам наследникам класса Control может осуществлятся только из потока UI. Предположим также, что у нас есть некая языковая конструкция, которая указывает компилятору, что определённая часть кода должна выполняться в новом потоке.
Если уж фантазировать, до давайте делать это пореалистичнее. А то пример совсем неубедительный получился.
M>>В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется.
IT>Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.
Я имел ввиду вот это:
В функциональном программировании переменные – это просто псевдонимы для выражений (так что нам необязательно записывать всё в одну строчку). Они (переменные) не могут быть изменены. Все переменные могут принимать значения только один раз.
(это из статьи "Функциональное программирование для всех")
,а Влад выше писал:
Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.
M>> А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.
IT>Мьютексы то тут причём?
При том, что ими можно проблемы, которые в гипотетическом коде предлагалось решать с помощью атрибутов.
Здравствуйте, Mazay, Вы писали:
M>А в последнем "гипотетичеком" варианте этот самый UI вызывается вовсе не в UI'шном потоке.
Так почитай внимательно первый же абзац после этого примера. А то создаётся впечатление, что ты только картинки посмотрел.
IT>>Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".
M> Если уж фантазировать, до давайте делать это пореалистичнее. А то пример совсем неубедительный получился.
Видишь ли, я не предлагал законченного решения, которое уже можно было бы начинать обсуждать. Я лишь указал направление. Если хочешь пофантазировать, то начинай фантазировать, а не критиковать то, чего пока ещё не существует.
IT>>Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.
M>Я имел ввиду вот это: M>
M>В функциональном программировании переменные – это просто псевдонимы для выражений (так что нам необязательно записывать всё в одну строчку). Они (переменные) не могут быть изменены. Все переменные могут принимать значения только один раз.
(это из статьи "Функциональное программирование для всех")
Это и есть догмы.
M>,а Влад выше писал: M>
M>Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.
И что здесь не так?
IT>>Мьютексы то тут причём?
M>При том, что ими можно проблемы, которые в гипотетическом коде предлагалось решать с помощью атрибутов.
В гипотетическом коде предлагается совсем другое. А именно — приведение многопоточного алгоритма к линейному виду.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> C>SMP для 80 ядер вряд ли будет возможен — так как доступ к памяти станет >> C>больным местом. Значит как-то надо эти ядра делить на кластеры, которые >> C>будут взаимодействовать только через каналы связи. >> Ну, внутри все будет так, как ты говоришь. А снаружи, с точки зрения >> софта, это скорее всего будет выглядеть как SMP. >> Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в >> рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут >> через HyperThreading. И ничего — все равно это выглядит для софта как >> SMP, потому как это проще программить. И ничего. C>Понимаешь, для двух процессоров это прокатит — так как достаточно редкие C>обращения к общей памяти не будут делать погоды. А вот для 80 C>процессоров — уже не уверен, нужно уже что-то другое.
Cyberax, все уже украдено до нас. Я тебе уже письма три как объясняю, что SMP не подразумевает наличия физически общей памяти. Что общая память — это удобная абстракция, которая выражается через message-passing. Могу только добавить, что в рамках модели общей памяти уже сейчас работает софт на суперкомпьютерных кластерах с тысячами узлов, связанных средой Merynet или Infiniband (у которых с латентностью не ахти — внутри кристалла будет существенно лучше).
О проблеме, о которой ты говоришь, все давно уже подумали. В очередной раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform memory access), на алгоритм синхронизации кэшей в рамках которого уже даже стандарт IEEE принят.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Эта мода (VLIW, в случае Itanium) — уже в прошлом. У такой архитектуры есть ряд недостатков, один из которых связан, например, с тем, что широкий VLIW плохо кладется на кристалл — у него широкие шины. Это раздувает кристалл, делая его дороже, и снижает тактовые частоты из-за длинных связей. Например, пресловутый E2K, о котором много говорили, работает на практике (а не на бумаге) на частоте 300 МГц.
VD>Нет в природе никакого E2K.
Он в настоящий момент проходит государственные испытания, и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал. Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .
Gaperton wrote: > Cyberax, все уже украдено до нас. Я тебе уже письма три как объясняю, > что SMP не подразумевает наличия физически общей памяти. Что общая > память — это удобная абстракция, которая выражается через > message-passing. Могу только добавить, что в рамках модели общей памяти > уже сейчас работает софт на суперкомпьютерных кластерах с тысячами > узлов, связанных средой Merynet или Infiniband (у которых с латентностью > не ахти — внутри кристалла будет существенно лучше).
Я знаю про это. Мне интересно как это можно более эффективно сделать.
> О проблеме, о которой ты говоришь, все давно уже подумали. В очередной > раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform > memory access), на алгоритм синхронизации кэшей в рамках которого уже > даже стандарт IEEE принят.
Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна,
выражается в виде возможности указать для страниц памяти их "удаленность".
Здравствуйте, Cyberax, Вы писали:
>> О проблеме, о которой ты говоришь, все давно уже подумали. В очередной >> раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform >> memory access), на алгоритм синхронизации кэшей в рамках которого уже >> даже стандарт IEEE принят. C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна, C>выражается в виде возможности указать для страниц памяти их "удаленность".
Я тебе уже писал. Это делается в железе. В Оптеронах это сделано на уровне протокола Hypertransport. Никакой особой поддержки в линуксе для этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем .
Gaperton wrote: > C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна, > C>выражается в виде возможности указать для страниц памяти их "удаленность". > Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на > уровне протокола Hypertransport. Никакой особой поддержки в линуксе для > этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем .
А теперь ты прочитай про nccNUMA
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна, >> C>выражается в виде возможности указать для страниц памяти их "удаленность". >> Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на >> уровне протокола Hypertransport. Никакой особой поддержки в линуксе для >> этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем . C>А теперь ты прочитай про nccNUMA
Gaperton wrote: >> > Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на >> > уровне протокола Hypertransport. Никакой особой поддержки в линуксе для >> > этого не нужно. Так что вам, программерам, беспокоиться особенно не о > чем . > C>А теперь ты прочитай про nccNUMA > http://en.wikipedia.org/wiki/CcNUMA > А теперь ты мне дай сцылку на nccNUMA . С удовольствием почитаю.
Вот найти бы их еще, я читал про них в бумажных журналах и статьях на ACM.
Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами
приложения, явно выставляя специальные барьерные инструкции для
синхронизации с общей памятью (когда это необходимо). Это позволяет
легко сделать "транзакционную память" (тут Курилка, кажется, об этом
линк присылал), свести к минимуму простои из-за синхронизации и т.п.
Самой известной из таких систем, пожалуй, является Cray T3E, в который
втыкалось примерно 2000 процессорных элементов (с двумя процессорами в
каждом).
Такие архитектуры пока не имеют распространения из-за сложности
программирования, но наверняка станут более популярными с ростом числа
процессоров.
Здравствуйте, Cyberax, Вы писали:
C>Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами C>приложения, явно выставляя специальные барьерные инструкции для C>синхронизации с общей памятью (когда это необходимо). Это позволяет C>легко сделать "транзакционную память" (тут Курилка, кажется, об этом C>линк присылал), свести к минимуму простои из-за синхронизации и т.п.
Объясни мне, разве не такая модель памяти и используется в java & .net?
Andrei N.Sobchuck wrote: > C>Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами > C>приложения, явно выставляя специальные барьерные инструкции для > C>синхронизации с общей памятью (когда это необходимо). Это позволяет > C>легко сделать "транзакционную память" (тут Курилка, кажется, об этом > C>линк присылал), свести к минимуму простои из-за синхронизации и т.п. > Объясни мне, разве не такая модель памяти и используется в java & .net?
В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не
может использоваться на nccNUMA).
В Java сейчас модель памяти, совместимая с nccNUMA (поэтому там не
работает Double-Check Locking).
Andrei N.Sobchuck wrote: > C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не > C>может использоваться на nccNUMA). > То есть в .net вся память рассматривается как volatile (в java)?
Да, для x86 и ccNUMA это будет работать, так как гарантируется
когерентность кэшей.
Здравствуйте, Gaperton, Вы писали:
G>Он в настоящий момент проходит государственные испытания,
"Он" называется не Е2К, а Эльбрус <b>Е3М</b>.
G> и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал.
Ничего, ничего. Мне простительно. Я все же не работаю в конторе разнабатывающей чипы. А вот то что ты не знаешь название чипа о котором говоришь — это немного странно.
G> Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .
Начал в себе скромность воспитывать? Это похвально.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не >> C>может использоваться на nccNUMA). >> То есть в .net вся память рассматривается как volatile (в java)? C>Да, для x86 и ccNUMA это будет работать, так как гарантируется C>когерентность кэшей.