Andrei N.Sobchuck wrote: >> > C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не >> > C>может использоваться на nccNUMA). >> > То есть в .net вся память рассматривается как volatile (в java)? > C>Да, для x86 и ccNUMA это будет работать, так как гарантируется > C>когерентность кэшей. > Интересно, а что с mono?
Конкретные реализации вполне могут работать, но при этом они не будут
соответствовать спецификации на CLR.
Здравствуйте, FR, Вы писали:
FR>Так если не найдут способ увеличить частоту (хотя и это временная отсрочка, скорость света никто ни отменял ) распаралеливание неизбежно.
И толщину минимального диффузионного слоя в P-N переходе тоже никто не отменял, и скорость движения зарядов в полупроводниках тоже: никакой скоростью света там и не пахнет.
То что p-n переход исчерпал себя стало ясно 15 лет назад, когда впервые задумались о кешах, конвейерах, двух АЛУ и т.п., чтобы максимально использовать все транзисторы одновременно — это уже задачи распаралелливания и оптимизации.
Либо придет новая технология (5 поколение ЭВМ), и тогда проблема немного отодвинется, либо распараллеливание.
Здравствуйте, eugen1001, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>Так если не найдут способ увеличить частоту (хотя и это временная отсрочка, скорость света никто ни отменял ) распаралеливание неизбежно.
E>И толщину минимального диффузионного слоя в P-N переходе тоже никто не отменял, и скорость движения зарядов в полупроводниках тоже: никакой скоростью света там и не пахнет. E>То что p-n переход исчерпал себя стало ясно 15 лет назад, когда впервые задумались о кешах, конвейерах, двух АЛУ и т.п., чтобы максимально использовать все транзисторы одновременно — это уже задачи распаралелливания и оптимизации.
E>Либо придет новая технология (5 поколение ЭВМ), и тогда проблема немного отодвинется, либо распараллеливание.
Это все технологические, вполне разрешимые вопросы. А скорость света вещь фундаментальная ее не обойдешь. К тому же не так много уже и осталось, для кристала 1 см в поперечнике максимум всего 300Ггц, то есть запас всего в 100 раз
Здравствуйте, VladD2, Вы писали:
G>>Он в настоящий момент проходит государственные испытания,
VD>"Он" называется не Е2К, а Эльбрус <b>Е3М</b>.
VD>Ничего, ничего. Мне простительно. Я все же не работаю в конторе разнабатывающей чипы. А вот то что ты не знаешь название чипа о котором говоришь — это немного странно.
Ты перепутал вычислительный комплекс для военных, который делает МЦСТ, с микропроцессором. Ничего, это простительно — ты ведь и в самом деле не работаешь в конторе, разрабатывающей чипы. Многие "процессором" системый блок называют, это нормально.
Для тех, кто эту ветку читает, я дам ссылки на сайт производителя. Может кому интересно будет. Ты тоже взгляни.
Здравствуйте, Gaperton, Вы писали:
G>Ты перепутал вычислительный комплекс для военных, который делает МЦСТ, с микропроцессором.
И все же я тебя огорчу, так как я как раз ничего не перепутал. Просто в среде инженеров недостаточно информации и переизбыток желания задеть собеседника.
Вот и на этом сайте нашел один документик: http://www.mcst.ru/doc/1_grabezhnoy.doc
Почитай его. Он несколько интереснее чем те рекламные листки на которые ты давал ссылки.
Нашел я его только Гуглем. Видимо в нашей стране сайты обновляются чуть реже чем люди умудряются общаться с журналистами и писать отчеты.
Словом E2K процессор назывался много лет назад когда он был на бумаге и когда его разработкой занимался Бабаян. Я тогда лично присутсвовал на презентации бумажного процессора и даже в общем-то купился на обещания. Мы даже опубликовали статейку по этому поводу. Теперь Бабаян срыл в Интел, а разработку ведут без него. За это время они умудрились сделать чип (правда не сами, а где-то в Корее). То что заработало как раз и называется E3М. А Е2К так и остался бумажным процессором. А теперь они называют Е2К общей архитектурой.
G> Ничего, это простительно — ты ведь и в самом деле не работаешь в конторе, разрабатывающей чипы. Многие "процессором" системый блок называют, это нормально.
Ну, как видишь некоторые товарищи годящиеся званием инженера вместо того чтобы расширять свой кругозор упражняются в злословии. Видимо тем самым пытаются поддержать имидж инженера.
G>Ищи свой E3M в секции "вычислительные колмплексы", и смотри на него даташыт. G>http://www.mcst.ru/doc/8-9.zip
Ты почитал бы то на что ссылки даешь. Там говорится о «Эльбрус-3М1».
Ну, да продолжайте Инженер. Все равно вывернетесь, скажете, что апельины приносили.
G>А так же процессор "Эльбрус", который в среде инженеров известен как E2K. G>http://www.mcst.ru/doc/2-3.zip
Это вообще рекламный листок для инженеров... МО РФ.
ЗЫ
Если выключить ехидство, то ситуация когда кто-то ошибается в названиях или не знает что делает некий институт соврешенно нормальна. Коробит вся эта демагогия, желание зачмырить оппонента и надменно-менторский тон. Будь ближе и люди к тебе потянутся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Из-за этого в Java, вообще говоря, не может работать такой паттерн: > C>http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > Нда, очень в твоей манере. > Я просил объяснение чем же это архитектура Х не допускает реализации на > базе архитектуры У.
Потому что в спеке на CLR _явно_ прописано запрещение таких reorder'ов,
гарантируется что память будет гарантировано когерентна. В спеке на JVM
Memory Model такой гарантии не дается.
Соответственно, полностью соответствующая спеке реализация .NET CLR
невозможна на nccNUMA-системах.
Про .NET смотри: ECMA-335, Section 12
> Ты же мне приводишь какую-то информацию о проблемах конкретной реализации.
А ты в своей манене поверхностно прочитал, не пробуя вникнуть в проблему.
Здравствуйте, VladD2, Вы писали:
VD>Ты почитал бы то на что ссылки даешь. Там говорится о «Эльбрус-3М1». VD>Ну, да продолжайте Инженер. Все равно вывернетесь, скажете, что апельины приносили.
Продолжать? Вы думаете, я буду читать вашу писанину, Писатель? И вести глупые споры? Верно вы забыли, что я уже два года не отвечаю на ваши "письма", и почти не читаю их. Я знаю вас давно, и уже давно не чуствую себя обязаным перед вами "выворачиваться". Думайте себе что хотите, Писатель, на здоровье.
Здравствуйте, Gaperton, Вы писали:
G>Продолжать? Вы думаете, я буду читать вашу писанину, Писатель? И вести глупые споры? Верно вы забыли, что я уже два года не отвечаю на ваши "письма", и почти не читаю их. Я знаю вас давно, и уже давно не чуствую себя обязаным перед вами "выворачиваться". Думайте себе что хотите, Писатель, на здоровье.
похоже на детство. Не читаешь и не отвечаешь? так держись и не отвечай.
Здравствуйте, Gaperton, Вы писали:
G> Верно вы забыли, что я уже два года не отвечаю на ваши "письма", и почти не читаю их.
Да, уважаемый "инженер", почти забыл. Спасибо что Вы постоянно об этом напоминаете.
G> Я знаю вас давно, и уже давно не чуствую себя обязаным перед вами "выворачиваться".
Ну, что я говорил? Даже про апельсины вспоминать не пришлось.
G> Думайте себе что хотите, Писатель, на здоровье.
Вот за это отдельное спасибо! Всегда приятно когда тебе напоминают о твоем праве на свободу слова.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hello, Cyberax!
You wrote on Tue, 17 Oct 2006 08:33:46 GMT:
C>>> Если вкратце, то в nccNUMA за синхронностью кэша должны следить C>>> сами приложения, явно выставляя специальные барьерные C>>> инструкции для синхронизации с общей памятью (когда это C>>> необходимо). Это позволяет легко сделать "транзакционную C>>> память" (тут Курилка, кажется, об этом линк присылал), свести к C>>> минимуму простои из-за синхронизации и т.п. >> Объясни мне, разве не такая модель памяти и используется в java & >> .net? C> В .NET — нет, там более сильная модель (поэтому .NET, вообще C> говоря, не может использоваться на nccNUMA).
C> В Java сейчас модель памяти, совместимая с nccNUMA (поэтому там не C> работает Double-Check Locking).
Механизм double-сheck locking в Яве мог не работать до версии 1.4. С 1.4 в Java Memory Model были внесены изменения, решающие в том числе проблему с double-сheck locking.
Yuri Khomich wrote: > C> В Java сейчас модель памяти, совместимая с nccNUMA (поэтому там не > C> работает Double-Check Locking). > Механизм double-сheck locking в Яве мог не работать до версии 1.4. С 1.4 > в Java Memory Model были внесены изменения, решающие в том числе > проблему с double-сheck locking.
Модель не меняли, просто дополнили семантику volatile-объявлений. Старый
DCL как не работал, так и не будет. Нужно писать так:
public class Singleton
{
volatile Singleton theInstance;
Singleton getInstance()
{
if (theInstance==null)
{
synchronized(Singleton.class)
{
if (theInstance!=null) return theInstance;
theInstance=new Singleton();
}
}
return theInstance;
}
}
Hello, Cyberax!
You wrote on Tue, 24 Oct 2006 15:42:02 GMT:
C>>> В Java сейчас модель памяти, совместимая с nccNUMA (поэтому там C>>> не работает Double-Check Locking). >> Механизм double-сheck locking в Яве мог не работать до версии >> 1.4. С 1.4 в Java Memory Model были внесены изменения, решающие >> в том числе проблему с double-сheck locking. C> Модель не меняли, просто дополнили семантику volatile-объявлений. C> Старый DCL как не работал, так и не будет.
По-вашему, семантика выражений, работающих с памятью, не имеет прямого отношения к модели памяти?
Yuri Khomich wrote: >> > Механизм double-сheck locking в Яве мог не работать до версии >> > 1.4. С 1.4 в Java Memory Model были внесены изменения, решающие >> > в том числе проблему с double-сheck locking. > C> Модель не меняли, просто дополнили семантику volatile-объявлений. > C> Старый DCL как не работал, так и не будет. > По-вашему, семантика выражений, работающих с памятью, не имеет прямого > отношения к модели памяти?
Я имею в виду, что саму суть модели памяти не поменяли (то есть
возможность read/write reorder'а). Добавили просто дополнительную
функциональность туда, где ее раньше не было.
Hello, Cyberax!
You wrote on Tue, 24 Oct 2006 17:53:54 GMT:
>>>> Механизм double-сheck locking в Яве мог не работать до версии >>>> 1.4. С 1.4 в Java Memory Model были внесены изменения, решающие >>>> в том числе проблему с double-сheck locking. C>>> Модель не меняли, просто дополнили семантику C>>> volatile-объявлений. C>>> Старый DCL как не работал, так и не будет. >> По-вашему, семантика выражений, работающих с памятью, не имеет >> прямого отношения к модели памяти? C> Я имею в виду, что саму суть модели памяти не поменяли (то есть C> возможность read/write reorder'а). Добавили просто дополнительную C> функциональность туда, где ее раньше не было.
Именно что поменяли: в старой модели чтение/запись volatile переменной могли быть переупорядочены с чтением/записью nonvolatile пременной. Новая модель памяти это запрещает. Возможность reorder'a осталась только для nonvolatile переменных.
Yuri Khomich wrote: > C> Я имею в виду, что саму суть модели памяти не поменяли (то есть > C> возможность read/write reorder'а). Добавили просто дополнительную > C> функциональность туда, где ее раньше не было. > Именно что поменяли: в старой модели чтение/запись volatile переменной > могли быть переупорядочены с чтением/записью nonvolatile пременной. > Новая модель памяти это запрещает. Возможность reorder'a осталась только > для nonvolatile переменных.
Скорее по-другому: для non-volatile переменных запретили reorder. Ни
разу до этого не видел volatile (как и strictfp) в реальных программах
на Java.
Здравствуйте, Cyberax, Вы писали:
C>Скорее по-другому: для non-volatile переменных запретили reorder. Ни C>разу до этого не видел volatile (как и strictfp) в реальных программах C>на Java.
В том виде для них особого применения и не было. Да и сейчас, основная польза от этих изменений это то, что появился java.util.concurrent не пользующийся synchronized.
Hello, Cyberax!
You wrote on Wed, 25 Oct 2006 15:20:35 GMT:
C> Yuri Khomich wrote: C>>> Я имею в виду, что саму суть модели памяти не поменяли (то есть C>>> возможность read/write reorder'а). Добавили просто C>>> дополнительную функциональность туда, где ее раньше не было. >> Именно что поменяли: в старой модели чтение/запись volatile >> переменной могли быть переупорядочены с чтением/записью >> nonvolatile пременной. >> Новая модель памяти это запрещает. Возможность reorder'a осталась >> только для nonvolatile переменных. C> Скорее по-другому: для non-volatile переменных запретили reorder.
) распаралеливание неизбежно.
