Re[14]: Язык для CELL - Философия программирования

Здравствуйте, Cyberax, Вы писали:

C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это неприемлимо.
Это очень сильно зависит от алгоритма и от оптамизатора.

C>Управляемых ОС быть не должно.
Не согласен.
C>Нефиг в софте переделывать то, что прекрасно делается в железе

В том то и дело что плохо оно делается... в железе можно эффективно добится изоляции только довольно крупных кусков памяти иначе будет тАкой оверхед что мама не горюй.
А вот в управляемых средах можно изолировать хоть каждый байт и при наличии нормального оптимизатора можно выкинуть подавляющие большинство проверок просто статическим анализом.
Причем эта изоляция совсем не лишняя... ибо убирает очень большое колличество уязвимостей... да хотябы тоже переполнение буфера.
А самое смешное что программная изоляция получается эффективней аппаратной...
C>(тем более, что тенденция сейчас совсем обратная).
Ага... Жаба и .НЕТ захватывают рынок... Делаются Жаба процессоры... Новый софт начинают писать на С++ все реже и реже...

C>Первое преимущество для SPU не так важно,
Кроме SPU есть еще куча других архитектур... на них софт тоже должен работать...
C>второе — на любителя (аппаратная поддержка же есть).
То-то программы постоянно взламывают через переполнение буфера... Да и просто падение программы на ровном месте ничего хорошего не дает. Вот только не говори что это лечится прямыми руками... у кого эти прямые руки есть? Правильно у очень небольшой части программистов. Короче это не на любителя это просто необходимый фактор. Таковы реалии сегодняшней жизни... сроки уменьшаются, сложность и объем программ постоянно растет, а вот программистов с прямыми руками больше не становится... Да и при наличии прямых рук гораздо приятнее и быстрее работать если знаешь что в случае мелкой ошибки по не внимательности среда тебя сразу ткнет носом, а не устроет феерическое шоу наведенок.
C>В теории, третее преимущество позволит управляемой среде разбивать программу на куски и скармливать их в SPU.
И над этими теориями сейчас работают куча ученых. И что-то мне подсказывает что этот алгоритм вполне возможен.

C>Но текущая модель памяти CLR (однородной и бесконечной) этому как-то не способствует.
Да причем тут CLR? Что ты зациклился на CLR? Кто вобще говорит о CLR? Я уже раз 10 сказал что CLR не лучшая основа для управляемой ОС.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Andrei N.Sobchuck wrote:
> C>Ничего кроме простенького mark&sweep в такие рамки положить не
> C>получится, а от него мало толку будет.
> Ладно ладно. Спорить не буду. А у тебя есть, что сказать про compile
> time GC (O'Caml)?
Region inference — он часто дает слишком пессимистичные результаты.

Posted via RSDN NNTP Server 2.0

Дарней wrote:
> C>А еще функции должны работать только с ограниченым по размеру
> C>окружением.
> это уже забота ВМ
А как ты будешь убеждаться, что твой код не требует больше 256Кб памяти?

> C>И без всякого GC — он в 256Кб не поместится.
> как насчет region inference?
Пессимистично слишком.

> C>Так что С++ все же в более выгодном положении.
> Делать все вручную?
Да, и для этого есть необходимые инструменты (умные указатели, механизм
деструкторов и т.п.). Еще необходимо добавить прагмы для обозначения
кода для SPU и соответствующую поддержку компилятора.

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это
> неприемлимо.
> Это очень сильно зависит от алгоритма и от оптамизатора.
Нет, к сожалению.

> C>Нефиг в софте переделывать то, что прекрасно делается в железе
> В том то и дело что плохо оно делается... в железе можно эффективно
> добится изоляции только довольно крупных кусков памяти иначе будет тАкой
> оверхед что мама не горюй.
Ага, а тут у нас этот оверхед будет в софте. _Сегодняшнее_ _х86-железо_
действительно ориентировано на процессы, однако ничего не мешает сделать
более эффективную аппратную изоляцию.

> А вот в управляемых средах можно изолировать хоть каждый байт и при
> наличии нормального оптимизатора можно выкинуть подавляющие большинство
> проверок просто статическим анализом.
При этом теряя возможность использовать _любой_ небезопасный код в принципе.

> Причем эта изоляция совсем не лишняя... ибо убирает очень большое
> колличество уязвимостей... да хотябы тоже переполнение буфера.
Переполнение буффера решается с помощью элементарной аппаратной защиты.

> C>(тем более, что тенденция сейчас совсем обратная).
> Ага... Жаба и .НЕТ захватывают рынок... Делаются Жаба процессоры...
> Новый софт начинают писать на С++ все реже и реже...
...деревня Нью Васюки становится центром шахматного мира...

Ну не вижу я захвата рынков. Ява где была 5 лет назад — там и осталась.
То есть на серверах и в корпоративных приложениях. Как и .NET.

> C>Первое преимущество для SPU не так важно,
> Кроме SPU есть еще куча других архитектур... на них софт тоже должен
> работать...
На многих архитектурах работает Windows XP? А RSDN@Home?

> C>второе — на любителя (аппаратная поддержка же есть).
> То-то программы постоянно взламывают через переполнение буфера... Да и
> просто падение программы на ровном месте ничего хорошего не дает. Вот
> только не говори что это лечится прямыми руками... у кого эти прямые
> руки есть? Правильно у *очень небольшой *части программистов.
Пусть остальные программисты пишут на .NET — я не против. Другое дело,
что управляемые ОС _лишают_ возможности писать на неуправляемых языках.

> а не устроет феерическое шоу наведенок.
В последний раз наведенную ошибку в своем коде искал год назад.

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

> Да причем тут CLR? Что ты зациклился на CLR? Кто вобще говорит о CLR? Я
> уже раз 10 сказал что CLR не лучшая основа для управляемой ОС.
Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

>> Это очень сильно зависит от алгоритма и от оптамизатора.
C>Нет, к сожалению.
Те ты хочешь сказать что любой алгорит записанный в функциональном стиле будет очень сильно мусорить?

C>Ага, а тут у нас этот оверхед будет в софте.
Практика Сингулярити и простите ОберонОС показывают что этот оверхед ничтожен по сравнению с аппаратным который работает на уровне процессов... А что будет если железо будет контролировать каждый байт? Короче это будет называтся тушите свет.
C>_Сегодняшнее_ _х86-железо_ действительно ориентировано на процессы, однако ничего не мешает сделать более эффективную аппратную изоляцию.
Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
А теперь сравни с программной изоляцией... во время компиляции можно сделать очень большое колличество проверок статически те устранить их или вынести за придела цикла...
Вобщем если делать все в железе то придется впаять большую кучу транзистеров на обеспечение безопасности. В то время как если делать программную изоляцию мы можем в место защиты которую может обеспечить софт сделать еще одно ядро которое можно задействовать для полезной работы.
Те мы теряем несколько процентов на проверках но выигрываем в два раза на том что у нас появляется еще одно ядро.

C>При этом теряя возможность использовать _любой_ небезопасный код в принципе.
А зачем он нужен? Что ты собрался делать такое что необходим не безопасный код?
Такой код как прекрасно показала Сингулярити нужен ТОЛЬКО в маленькой части ядра ОС. Ну и пусть он там будет. Ибо его очень мало и его пишут заведомо очень квалифицированные программисты.
А все что выходит за приделы микро ядра вполне может быть управляемым.

C>Переполнение буффера решается с помощью элементарной аппаратной защиты.

Где решается? Не вижу.

C>На многих архитектурах работает Windows XP?
По крайней мере на x86, x86-64, Intel Itanium. Это то о чем я знаю.
C>А RSDN@Home?
Он работает тамже где и WinXP. Единственное возможно придется пересобрать интероп.

А знаешь почему так мало архитектур? Нет не по тому что МС не модет портировать WinXP, а по тому что десятки тысяч других программ завязаны на x86. И их портирование практичеки не возможно ибо их писали кулхацкеры используя низкоуровневый небезопасный код.

C>Пусть остальные программисты пишут на .NET — я не против. Другое дело, что управляемые ОС _лишают_ возможности писать на неуправляемых языках.
ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?

C>В последний раз наведенную ошибку в своем коде искал год назад.
Я тоже очень давно их не видел... даже когда писал на С++.
К томуже ты уверен что в твоих программах нет таких ошибок? Они ведь могут спать до поры до времени... Причем они могут быть не только в твоем коде но и в сторонней библиотеке... А могут появится при изменении версии библиотеки...
А в управляемых средах таких ошибок нет. Просто по тому что им неоткуда взятся...

C>И что-то мне подсказывает, что управляемость окажется не нужной.
Моя практика показывает что управляемость очень даже нужна...

C>Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".
Те ты просто взял плохой частный случай и обопщил его на все управляемый ОС? Это называется демагогия.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
>> > Это очень сильно зависит от алгоритма и от оптамизатора.
> C>Нет, к сожалению.
> Те ты хочешь сказать что любой алгорит записанный в функциональном стиле
> будет очень сильно мусорить?
Почти весь.

> А что будет если железо будет контролировать каждый байт?
Счастье.

> C>_Сегодняшнее_ _х86-железо_ действительно ориентировано на процессы,
> однако ничего не мешает сделать более эффективную аппратную изоляцию.
> Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты
> понимаешь что железу придется иметь дело с кучей метаинформации, и тупо
> проверять каждое действие с памятью?
А что он сейчас делает, по-твоему, при работе со страничной памятью?

Фактически, для более fine-grained контроля нужно чтобы попытка
привиллегированой операции вызывало исключение. Это не так сложно —
механизмы линейных ACL давно перенесены в железо.

> Вобщем если делать все в железе то придется впаять большую кучу
> транзистеров на обеспечение безопасности.
Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086

> Те мы теряем несколько процентов на проверках но выигрываем в два раза
> на том что у нас появляется еще одно ядро.
Нет, я даже могу набросать приблизительную схему такой защиты.

> C>При этом теряя возможность использовать _любой_ небезопасный код в
> принципе.
> А зачем он нужен? Что ты собрался делать такое что необходим не
> безопасный код?
Да. Мне необходим. Еще вопросы?

> C>Переполнение буффера решается с помощью элементарной аппаратной защиты.
> Где решается? Не вижу.
В старых добрых мейнфреймах

Были процессоры, где на стек можно было
карту доступа ставить. Побайтную (точнее, пословную). Запись указателя
тоже была привиллегированой операцией.

> C>На многих архитектурах работает Windows XP?
> По крайней мере на x86, x86-64, Intel Itanium. Это то о чем я знаю.
И все они x86. За исключением Itanium, который все равно не сильно
отличается.

> А знаешь почему так мало архитектур? Нет не по тому что МС не модет
> портировать WinXP, а по тому что десятки тысяч других программ завязаны
> на x86. И их портирование практичеки не возможно ибо их писали
> кулхацкеры используя низкоуровневый небезопасный код.
Ага, а программы на .NET завтра магически смогут заработать на Alpha со
слабой архитектурой памяти.

> C>Пусть остальные программисты пишут на .NET — я не против. Другое дело,
> что управляемые ОС _лишают_ возможности писать на неуправляемых языках.
> ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
А ну быстро писать на Oberon! Зачем тебе остальные языки???

> C>В последний раз наведенную ошибку в своем коде искал год назад.
> Я тоже очень давно их не видел... даже когда писал на С++.
> К томуже ты уверен что в твоих программах нет таких ошибок? Они ведь
> могут спать до поры до времени... Причем они могут быть не только в
> твоем коде но и в сторонней библиотеке... А могут появится при изменении
> версии библиотеки...
Ну это уже параноя

Мои программы обычно тестируются на тех
конфигурациях, где они будут использоваться.

> А в управляемых средах таких ошибок нет. Просто по тому что им неоткуда
> взятся...
Ага, там есть другие ошибки...

> C>Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".
> Те ты просто взял плохой частный случай и обопщил его на все управляемый
> ОС? Это называется демагогия.
А еще какие управляемые среды вы можете привести в пример (кроме Java)?
Я вот знаю еще Parrot VM — но там нет верификатора (точнее не было,
когда я в последний раз смотрел).

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

WH>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.

afaik AS400 так работает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
ANS>afaik AS400 так работает.
Те проводит статический анализ кода и устраняет не нужные проверки?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Фактически, для более fine-grained контроля нужно чтобы попытка привиллегированой операции вызывало исключение. Это не так сложно — механизмы линейных ACL давно перенесены в железо.
Зачем это делать в железе если это можно сделать в софте? Причем в софте можно выкинуть большую часть проверок.

C>Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086

Ага изменение набора комманд... те переписывание всего софта.

C>Нет, я даже могу набросать приблизительную схему такой защиты.
Давай. И за одно объясни как это будет работать для такого кода

void memcpy(void* dest, void const* src, int n)
{
    char* d = (char*)dest;
    char const* s = (char const*)src;
    char const* e = s + n;
    while(s != e)
        *d++ = *s++;
}

C>Да. Мне необходим. Еще вопросы?
Я не спрашивал тебя нужен тебе небезопасный код или нет. Я спрашивал зачем он тебе нужен.

C>В старых добрых мейнфреймах

Были процессоры, где на стек можно было карту доступа ставить. Побайтную (точнее, пословную). Запись указателя тоже была привиллегированой операцией.
Те софт создавал карты доступа, а потом железо по этим картам работало? Так?

C>Ага, а программы на .NET завтра магически смогут заработать на Alpha со слабой архитектурой памяти.
А в чем проблема?

C>А ну быстро писать на Oberon! Зачем тебе остальные языки???
Сколько языков существует под .NET? А под жабу?
Причем тут вобще языки? Мы говорим об управляемых средах, а языки какбы дело десятое.

C>Ну это уже параноя

Мои программы обычно тестируются на тех конфигурациях, где они будут использоваться.
Это не параноя. Это печальный опыт... Порой проблемы берутся просто изнеоткуда. Я в свое время занимался АСУТП и писал OPC серверы. Так вот была одна скада которая работала с другими серверами но при попытке подключится к моему она падала. Причем мой сервер проходил валидацию без замечаний и прекрасно работал со всеми другими скадами... Вобщем состыковать их так и не получилось. Хотя я долго и упорно пытался понять какже изменить мой сервер чтобы эта дура не падала...

C>Ага, там есть другие ошибки...
Какие? Только не говори про кодогенератор... Это всеравно что сказать что ошибки могут быть в железе... и они там действительно бывают... и чем сложнее железо тем болие вероятна ошибка... причем в отличии от софта который можно очень легко обновить с железом так поступить уже намного сложнее.

C>А еще какие управляемые среды вы можете привести в пример (кроме Java)?
А зачем? Му тут филосовствуем или где? Мы рассуждаем о том что лучше навороченая железка которая занимается всякой ерундой типа контроля кто куда пишет или простая железка которая ничего не проверяет но весть софт который на ней крутится проверен до запуска, а там где статика не дает ответа вставлены проверки.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> WH>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь
> ты понимаешь что железу придется иметь дело с кучей метаинформации, и
> тупо проверять каждое действие с памятью? Причем никакие оптимизации не
> возможны в принципе.
> ANS>afaik AS400 так работает.
> Те проводит *статический* анализ кода и устраняет не нужные проверки?
А зачем? У нас же быстрая аппаратная поддержка, с механизмом кэширования
вмонтированым в предсказатель переходов.

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Фактически, для более fine-grained контроля нужно чтобы попытка
> привиллегированой операции вызывало исключение. Это не так сложно —
> механизмы линейных ACL давно перенесены в железо.
> Зачем это делать в железе если это можно сделать в софте? Причем в софте
> можно выкинуть большую часть проверок.
Затем, что это не позволит писать софт ни на чем, кроме этого VM-языков.

> C>Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086
> Ага изменение набора комманд... те переписывание всего софта.
А тут нам помогут технологии виртуализации — можно будет запустить тот
же софт в эмуляторе с JIT-транслятором x86. Вон у Apple'овцев вообще код
из PowerPC в x86 на лету транслируется всего с 50% потерей скорости в
Unreal Tournament 2004. Для этого эмулятора можно будет сделать
выделенный sandbox.

> C>Нет, я даже могу набросать приблизительную схему такой защиты.
> Давай. И за одно объясни как это будет работать для такого кода
> void memcpy(void* dest, void const* src, int n)
> {
> char* d = (char*)dest;
> char const* s = (char const*)src;
> char const* e = s + n;
> while(s != e)
> *d++ = *s++;
> }
При натыкании на указатель (слово с установленым старшим битом) — ошибка
защиты, выполнение микрокода, который проверяет может ли код с данным
значением IP делать модификацию указателей. И т.д.

Естественно, установка старшего бита (незначащего) тоже контролируется.
Эта технология давно используется в мейнфреймах.

Получается такой managed-assembler

> C>Да. Мне необходим. Еще вопросы?
> Я не спрашивал тебя нужен тебе небезопасный код или нет. Я спрашивал
> зачем он тебе нужен.
1. Скорость.
2. Гибкость.
3. А чем я хуже MS??

> Те *софт *создавал карты доступа, а потом железо по этим картам
> работало? Так?
Да. От переполнений буффера это спасает замечательно.

> C>Ага, а программы на .NET завтра магически смогут заработать на Alpha
> со слабой архитектурой памяти.
> А в чем проблема?
В слабой (weak) модели памяти. Сейчас ncNuma (non-cache-coherenet
Non-Uniform Memory Access) системы редки, но в будущем их ждет
распространие. Cell — это первый звонок.

> C>А ну быстро писать на Oberon! Зачем тебе остальные языки???
> Сколько языков существует под .NET? А под жабу?
> Причем тут вобще языки? Мы говорим об управляемых средах, а языки какбы
> дело десятое.
Ну да. У меня есть выбор:
1. VB.
2. C#.
3. Nemerle.

А где мой любимый C++ и Assembler (который не для MSIL)???

> Это не параноя. Это печальный опыт... Порой проблемы берутся просто
> изнеоткуда. Я в свое время занимался АСУТП и писал OPC серверы. Так вот
> была одна скада которая работала с другими серверами но при попытке
> подключится к моему она падала. Причем мой сервер проходил валидацию без
> замечаний и прекрасно работал со всеми другими скадами... Вобщем
> состыковать их так и не получилось. Хотя я долго и упорно пытался понять
> какже изменить мой сервер чтобы эта дура не падала...
А давайте я такую же слезливую историю расскажу про BEA Weblogic и
JBoss? Что характерно, оба на Java.

> C>Ага, там есть другие ошибки...
> Какие?
Молчаливое игнорирование исключений с разрушением логической структуры,
например. Скажешь редко бывает? Ну так и наведенные ошибки тоже редки.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

WH>>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
ANS>>afaik AS400 так работает.
WH>Те проводит статический анализ кода и устраняет не нужные проверки?

Простите за двусмысленность. Там железная пообъектная защита. afaik

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Дарней,

> C>Будут рулить вещи типа cell-архитектур для которых C# не подходит абсолютно и полностью. С++ тоже плохо подходит, правда.
>
> подозреваю, что как раз там будут рулить ФЯ

Может, и нет..

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Затем, что это не позволит писать софт ни на чем, кроме этого VM-языков.
А в чем проблема то? У меня складывается впечатление что баба Яга против! Тебя ведь не напрягает что тебе приходится писать только на языках компиляторы которых есть под данный процессор? Так в чем же тут проблема?

C>А тут нам помогут технологии виртуализации — можно будет запустить тот же софт в эмуляторе с JIT-транслятором x86. Вон у Apple'овцев вообще код из PowerPC в x86 на лету транслируется всего с 50% потерей скорости в Unreal Tournament 2004. Для этого эмулятора можно будет сделать выделенный sandbox.
Те предлагаешь сделать таки виртуальную машину... А почему бы не посадить все на одну виртуальную машину которая занимается тотальными проверками всего что можно?
Причем эта машина за счет оптимизатором сможет генерировать код который не в 2 раза медленней, а на несколько процентов.

C>При натыкании на указатель (слово с установленым старшим битом) — ошибка защиты, выполнение микрокода, который проверяет может ли код с данным значением IP делать модификацию указателей. И т.д.
Те на каждый чих у нас начинает работать микро код которому нужны таблици чего и кому можно... ты усложняешь железо и всеравно очень многое зависит от софта...

C>Получается такой managed-assembler

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

C>1. Скорость.
C>2. Гибкость.
C>3. А чем я хуже MS??
Хватит разводить демагогию. Ты на вопрос ответь: Какую задачу ты собираешься этим решать?

C>Да. От переполнений буффера это спасает замечательно.
А смысл? Если всеравно все держится на том что софт правильно заполнит таблици?

C>В слабой (weak) модели памяти. Сейчас ncNuma (non-cache-coherenet Non-Uniform Memory Access) системы редки, но в будущем их ждет распространие. Cell — это первый звонок.
Еще раз какие проблемы будут у управляемых сред с такими архитектурами? И почему ты думаешь что у С++ получится с ними лучше?

C>А где мой любимый C++ и
Блин ну напиши компилятор который будет генерировать код данной виртуальной машины если тебе так хочется попрограммировать на этом антиквариате. Вот тольк зачем если тотже немерле рвет С++ как тузик грелку?
C>Assembler (который не для MSIL)???
Это по определению не переносимо.

C>Молчаливое игнорирование исключений с разрушением логической структуры, например. Скажешь редко бывает? Ну так и наведенные ошибки тоже редки.
Вот только заглушенные исключения ловить намного проще чем чем порчу памяти 5-ого порядка.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>afaik AS400 так работает.
WH>>Те проводит статический анализ кода и устраняет не нужные проверки?
ANS>Простите за двусмысленность. Там железная пообъектная защита. afaik
Вот я не могу понять зачем нужна железная защита?
Cyberax похоже ушол в глухую демагогию

может ты мне объяснишь чем проверки в железе лучше проверок в виртуальной машине? Ведь если не делать проверки в железе те вобще выбросить все транзисторы которые этим занимаются, а в место них просто добавить вычислительной мощьности то мы потеряем на проверках которые не смог устранить компилятор проценты но получим увеличиную мощь процессора. Плюс как я уже говорил чем сложнее процессор тем выше вероятность допустить ошибку в железе, а сменить железо гораздо труднее чем сменить софт.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

C>>Переполнение буффера решается с помощью элементарной аппаратной защиты.
WH> Где решается? Не вижу.
NX bit (AKA DEP)

WH>ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
Господа, после этой фразы вообще разговаривать дальше не о чем... Вы нас просто не можете понять.

Давайте завершим эту бесполезную дискуссию... Cyberax, сделай телевизор... погромче...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

WH>>ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
CC>Господа, после этой фразы вообще разговаривать дальше не о чем... Вы нас просто не можете понять.
Я вижу только два места где умесны неуправляемые языки:
1)Ядро ОС. Причем очень не большая его часть.
2)Микрокод.
А вот теперь назови мне хоть одну причину по которой нужно использовать неуправляемые языке во всех остальных областях.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH> может ты мне объяснишь чем проверки в железе лучше проверок в виртуальной машине?

их нельзя обойти раз они достаточно низкоуровневые — два.
Что касается безопасности ВМ, то тебе Алексей уже говорил — технологии оптимизации, построенные на динамической генерации кода в эту модель не влазят.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>их нельзя обойти раз
Если ОС полностью управляемая и не грузит ничего что не может проверить то эту защиту тоже нельзя обойти.
К томуже даже аппаратной защите нужна метаинформация которую кто-то должен предоставить. Так что я не вижу каких либо преймуществ у аппаратного решения.
ANS>они достаточно низкоуровневые — два.
Не вижу смысла. Если код прошол валидацию ВМ которой извесно о коде все то зачем нам низкий уровень?
ANS>Что касается безопасности ВМ, то тебе Алексей уже говорил — технологии оптимизации, построенные на динамической генерации кода в эту модель не влазят.
Почему? Ведь код генерирует ВМ со всеми проверками.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> Cyberax похоже ушол в глухую демагогию может ты мне объяснишь чем
> проверки в железе лучше проверок в виртуальной машине?
Железо — оно _быстрее_, во-первых. Сколько тактов бы занял бы ручной
lookup указателя в memory map table, и сколько занимает его lookup для
железа процессора?

Во-вторых, железная защита позволяет продолжать использовать
unmanaged-приложения.

В-третьих, мы еще и получаем CAS (Code Access Security) в железе.

> Плюс как я уже говорил чем сложнее
> процессор тем выше вероятность допустить ошибку в железе, а сменить
> железо гораздо труднее чем сменить софт.
Тут такая штука: MMU все равно останется нужным. Защита памяти (или ее
аналог) тоже, скорее всего, останется нужной для работы GC (для пометки
грязных страниц). То есть с переходом на программную реализацию защиты
памяти мы выиграем совсем немного транзисторов.

Posted via RSDN NNTP Server 2.0

CreatorCray wrote:
> C>>Переполнение буффера решается с помощью элементарной аппаратной защиты.
> WH> Где решается? Не вижу.
> NX bit (AKA DEP)
Не совсем. Еще остается трюк jump-to-library, но уже достаточно близко.
Чтобы побороть j2l нужна защита указателей, в AS/400 сделано так:
1. Указатели отмечены специальным битом.
2. Для push'а адреса возврата используется специальная инструкция.
3. В стек кладется указатель со взведенным битом.
4. При попытке его изменения (кроме инструкции retn) — ошибка защиты.

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> А вот теперь назови мне хоть одну причину по которой нужно использовать
> неуправляемые языке во всех остальных областях.
Для меня эти причины есть. Хотя бы потому, что нормальные
реализации .NET есть не везде.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

ANS>>Что касается безопасности ВМ, то тебе Алексей уже говорил — технологии оптимизации, построенные на динамической генерации кода в эту модель не влазят.
WH>Почему? Ведь код генерирует ВМ со всеми проверками.

Эта, на сколько я помню генерация кода ран-таймом запрещена. Так?
И, кстати, что с плагинами будем делать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, IT, Вы писали:

IT>Ничего особенного. Наращивание мощности путём добавления дешёвых элементов. Например, замена одного современного Windows сервера двумяста PII с линуксом. Проблема только в том, что 50% полученных ресурсов уходит на управление взаимодействием этого стада.

Как говорится в анегдоте, "один еврейский мальчик таки сумел". Это я про гугл. Я слыхал, ихние базы ни фига не на майнфреймах работают. И как бы даже не очень-то под Виндовс...

Здравствуйте, Cyberax, Вы писали:

C>Железо — оно _быстрее_, во-первых. Сколько тактов бы занял бы ручной lookup указателя в memory map table,
В том то и дело что в подавляющем колличестве случаев нисколько. Во первых в управляемых средах используются несколько иные абстракции. Те у нас небудет никаких указателей вобще. У нас будут типизированные регионы памяти.
Те тот код будет выглядеть так

void Copy<T>(region<T> dest, const region<T> src, int n)
{
    for(int i = 0; i < n; ++i)
        dest[i] = src[i];
}

Как не трудно заметить проверку можно легко вынести за приделы цикла. А сам цикл превратить в тот memcpy который я приводил рание.
Далие если использовать design-by-contract

void Copy<T>(region<T> dest, const region<T> src, int n)
    required n < dest.Length && n < src.Length
    otherwise throw new OutOfRangeException()
{
    for(int i = 0; i < n; ++i)
        dest[i] = src[i];
}

теперь мы вобще вынесли проверку за приделы функции. Те в таком коде даже без инлайна этой проверки не будет

void Foo(T[] array, int n)
    required n > 0 && array != null
    otherwise throw new InvalideArgumentException()
{
    Copy(array[5, 5 + n], array[25, 25 + n], n);
}

Проверки будут выполнены при создании регионов, а функция будет вызвана без каких либо проверок ибо они будут выполнены статическим анализом. Кстати при создании этих двух регионов будет выполнена только одна проверка... Опять таки статический анализ без труда заметит что нужно проверить только 25 + n < array.Length.
C>и сколько занимает его lookup для железа процессора?
Это завасит от реализации процессора. Кстати, а какой размер будет у этой таблици если мониторить всю память с точностью до байта?

C>Во-вторых, железная защита позволяет продолжать использовать unmanaged-приложения.
Зачем? Единственная причина которую я вижу это старые приложения. На мы же сменили архитектуру...

C>В-третьих, мы еще и получаем CAS (Code Access Security) в железе.
Например в сингулярити нет никакого CAS... там прова раздаются процессу. Болие того все права проверяются при старте этого процесса... Те во время работы на CAS вобще никто не отвлекается.

C>Тут такая штука: MMU все равно останется нужным. Защита памяти (или ее аналог) тоже, скорее всего, останется нужной для работы GC (для пометки грязных страниц). То есть с переходом на программную реализацию защиты памяти мы выиграем совсем немного транзисторов.
Да MMU нужен. А вот защита памяти врядли.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Для меня эти причины есть. Хотя бы потому, что нормальные реализации .NET есть не везде.
Те тебя не устраивают существующие реализации. Я от них тоже не в восторге... могли бы и лучше сделать. Но это лишь вопрос времени.
А к самим принципам управляемых систем у тебя какие притензии?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH>А к самим принципам управляемых систем у тебя какие притензии?

По крайней мере у меня, к принципам не претенции, а наоборот

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Эта, на сколько я помню генерация кода ран-таймом запрещена. Так?
Если ты говоришь о Сингулярити то там запрещено изменять код уже запущенного процесса. А сгенерировать код и запустить новый процесс тебе никто не мешает. Если конечно у процесса на это прав хватит.
ANS>И, кстати, что с плагинами будем делать?
Поднимаем новый процесс, открываем канал и вперед...

Но если говорить не о Сингулярити, а об управляемых ОС вобще то кодогенерация внутри работающего процесса вполне возможна.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Железо — оно _быстрее_, во-первых. Сколько тактов бы занял бы ручной
> lookup указателя в memory map table,
> В том то и дело что в подавляющем колличестве случаев нисколько. Во
> первых в управляемых средах используются несколько иные абстракции. Те у
> нас небудет никаких указателей вобще. У нас будут типизированные регионы
> памяти.
Объясняю: контроллер памяти в современном железе _всегда_ работает на
уровне страниц памяти (обычно 4Кб блоков). Это аппаратное ограничение,
которое никто снимать не собирается.

Значит нужно как-то отображать последовательный набор страниц в блоках
памяти в логическое адресное пространство. Этим занимается MMU (Memory
Mapping Unit). Так что обращение по любому указателю (а ссылка — это
тоже указатель!) вызывает _аппратный_ lookup в адресной таблице.

Занимает он один такт и замечательно pipeline'ится. Программная имитация
работала бы в десятки раз медленнее.

И самое интересное — для защиты памяти при наличии MMU нужно совсем
немного. Надо всего лишь переключать таблицы mapping'а при переключении
процесса, а это всего лишь пара записей в регистры. Ну и еще немного
транзисторов для проверки битов доступа страницы.

> теперь мы вобще вынесли проверку за приделы функции. Те в таком коде
> даже без инлайна этой проверки не будет
А lookup в MMU все равно будет на каждое обращение по ссылке.

> C>и сколько занимает его lookup для железа процессора?
> Это завасит от реализации процессора. Кстати, а какой размер будет у
> этой таблици если мониторить всю память с точностью до байта?
А зачем нам до байта? Нам нужны только записывать политики работы с
указателями. Это будет занимать не сильно больше текущего каталога страниц.

> C>Во-вторых, железная защита позволяет продолжать использовать
> unmanaged-приложения.
> Зачем? Единственная причина которую я вижу это старые приложения. На мы
> же сменили архитектуру...
Unmanaged!="старые" !!!

> C>В-третьих, мы еще и получаем CAS (Code Access Security) в железе.
> Например в сингулярити нет никакого CAS... там прова раздаются процессу.
> Болие того все права проверяются при старте этого процесса... Те во
> время работы на CAS вобще никто не отвлекается.
Минус для Singularity. Например (вы?) кто-то приводил пример, что можно
будет недоверяемым приложениям разрешить доступ к файловой системе, но
только через "Open File Dialog".

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Для *меня* эти причины есть. Хотя бы потому, что нормальные реализации
> .NET есть не везде.
> Те тебя не устраивают *существующие* реализации. Я от них тоже не в
> восторге... могли бы и лучше сделать. Но это лишь вопрос времени.
> А к самим принципам управляемых систем у тебя какие притензии?
Есть. Мне не нужна система, которая заставляет писать на языках с
обязательным GC, без арифметики указателей и возможности спуститься на
уровень ассемблера.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

WH>>>ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
CC>>Господа, после этой фразы вообще разговаривать дальше не о чем... Вы нас просто не можете понять.
WH>Я вижу только два места где умесны неуправляемые языки:
WH>1)Ядро ОС. Причем очень не большая его часть.
WH>2)Микрокод.

Я не вижу причин по которым всем надо переходить на управляемые языки.
Ровно точно также как я не понимаю почему например талибы хотят сделать ислам мировой религией.

На данный момент на практике неуправляемые языки имеют над управляемыми следующие преимущества (естественно при написании проги ровными руками):
1) скорость запуска и исполнения
2) потребляемая память (хотя это проблема не языка а GC)
3) бОльшая гибкость
К примеру: в той области где я на данный момент работаю (геймдев) 1 и 2 — критичные параметры.
Также я буду считать неразумным человеком того, кто возьмется писать системные сервисы на манагед. Виста? Появится релиз — посмотрим...

Все это справедливо к связке ASM vs C++. Вот примерно так же как сейчас обстоит с дело с ними будет обстоять ситуация с С++ vs managed.
Для асма все равно есть ниша. И будет пока процы выполняют машинный код. Точно так же native код будет жить и его кому то надо будет писать...

Не надо рассказывать про то, что на С# якобы вероятность сделать ошибку меньше — по мне так дело не в языке а в программере — пусть учится отвечать за свои очепятки и ошибки.
Не надо рассказывать что "будет аппаратная поддержка", "будет оптимизация" — давайте говорить про сейчас. Будет широко распространено — обсудим. "JIT все пересоберет" — выполнение JIT это ведь тоже потребление ресурсов. Меня бесит периодическая задумчивость 2003-й студии при открытии разного рода диалогов. Кста, стабильной ее назвать трудно — регулярно виснуть стала... Вот те и managed.

"портирование софта путем портирования рантайма и JIT" — где оно есть сейчас в полноценном объеме чтобы можно было что то реально переносить на разные платформы? Будет — тогда поговорим об этом.

WH>А вот теперь назови мне хоть одну причину по которой нужно использовать неуправляемые языке во всех остальных областях.
А вот теперь назови мне хоть одну причину по которой нужно использовать управляемые языке во всех остальных областях.
Их МОЖНО использовать, платя за это определенную цену. Получая определенное упрощение в процессе разработки. Но можно и не использовать.

Я вообще за то чтобы каждый язык использовать правильно и строго там, где он наиболее уместен. А не "во всех остальных областях".

Вообще по мне, так нас время рассудит. Пишите на чем угодно и под что угодно, но только не надо делать высокомерные заявления а ля "С++ больше ни на что не годен". Потому как звучит смешно. А заявление что на С++ проще сделать ошибку — так пардон, кто виноват в ошибке? Не тот ли кто ее сделал? А подумать нельзя было перед тем как начать писать?
Меня удивляет желание прогеров обложить себя ватой и стремление к тому, чтоб неаккуратность и непродуманность кода на лету исправлялась компилером или средствами языка...

впрочем хватит... развивать эту тему я не намерен. Все равно каждый останется при своем мнении.

Мир дружба жвачка. Хорош флудить, давайте лучше

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cyberax, Вы писали:

>> А к самим принципам управляемых систем у тебя какие притензии?
C>Есть. Мне не нужна система, которая заставляет писать на языках с
C>обязательным GC, без арифметики указателей и возможности спуститься на
C>уровень ассемблера.

Присоединяюсь. Ключевое слово "заставляет". Я за свободу выбора. Пусть бы существовали совместно но такое принудилово вызывает негатив.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cyberax, Вы писали:

C>Есть. Мне не нужна система, которая заставляет писать на языках с обязательным GC,

Singularity’s architecture permits SIPs to host completely different run-time systems, which allows a runtime to be customized for each process. For example, SIPs running sequential code may not need the support for thread synchronization required by SIPs with multiple threads. SIPs without objects requiring finalization (or having finalizers that do not access data shared among threads) may not need a separate finalizer to observe the required language semantics for finalizers. SIPs with certain allocation strategies may be able to pre-allocate or stack-allocate memory for all used objects, obviating the need for a garbage collector in the SIPs runtime.

Ы?
C>без арифметики указателей и возможности спуститься на уровень ассемблера.
А зачем тебе это надо я так и не понял. Объясни пожалуйста.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, CreatorCray, Вы писали:

CC>Я не вижу причин по которым всем надо переходить на управляемые языки.
А я вижу. Мне надоели программы которые постоянно падают на ровном месте. Например у меня на машине "Vampire Masquerade — Bloodlines" просто падает при старте, а на другой работала... Причем винда свеже поставленная.
CC>Ровно точно также как я не понимаю почему например талибы хотят сделать ислам мировой религией.
Одно дело тупые фанатики которые себе что-то вбили в голову. Другое дело я. Я не фанатик, а самый настоящий скептик. И мне понадобилось не мало времени понять почему управляемые среды рулят.

CC>На данный момент на практике неуправляемые языки имеют над управляемыми следующие преимущества (естественно при написании проги ровными руками):
CC>1) скорость запуска
Это просто не серьезно.
CC>и исполнения
Да не так уж и сильно оно отстает.
CC>2) потребляемая память (хотя это проблема не языка а GC)
ГЦ штука такая что будет жрать память пока дают. Те если у тебя много памяти то ГЦ сожрет много памяти, а если мало то мало. Хотя некоторый перерасход всеравно есть но он много меньше чем многим кажется.
CC>3) бОльшая гибкость
А вот это вобще не правда. Это я тебе говорю как человек очень хорошо знающий и С++ и .NET.

CC>К примеру: в той области где я на данный момент работаю (геймдев) 1 и 2 — критичные параметры.
Вот только не надо при мне говорить слово геймдев. Я не по наслишке знаю что это такое... Кстати The Next Mainstream Programming Language читал?
CC>Также я буду считать неразумным человеком того, кто возьмется писать системные сервисы на манагед.
О Singularity слышал? Там на манаджед написано большая часть ядра и все без исключения драйверы..., а ты говоришь системные сервисы...
CC>Виста? Появится релиз — посмотрим...
Виста к управляемым ОС не имеет никакого отношения. Это очередная ОС в линейке NT и не болие того. Да там много чего будет написано на .NET но это не делает эту ОС управляемой.

CC>Все это справедливо к связке ASM vs C++. Вот примерно так же как сейчас обстоит с дело с ними будет обстоять ситуация с С++ vs managed.
CC>Для асма все равно есть ниша. И будет пока процы выполняют машинный код. Точно так же native код будет жить и его кому то надо будет писать...
Конечно будет. Я с этим даже не спорю... я даже ниши назвал в которых будет...

CC>Не надо рассказывать про то, что на С# якобы вероятность сделать ошибку меньше — по мне так дело не в языке а в программере — пусть учится отвечать за свои очепятки и ошибки.
Учитывая что определенный класс ошибок там просто не возможен то...
CC>Не надо рассказывать что "будет аппаратная поддержка",
Аппаратная поддержка управляемым ОС не нужна. На оборот им от железа нужно меньше чем традиционным ОС.
CC>"будет оптимизация" — давайте говорить про сейчас.
Дык .NET и сейчас работает очень прилично... особенно второй.
CC>Будет широко распространено — обсудим.
Дык RSDN не нем родимом написан... да и та программа которой ты пользуешься для того чтобы читать RSDN по большей части тоже... Кстати ее несколько раз пытались переписать на неуправляемых языках... не вышло...
CC>"JIT все пересоберет" — выполнение JIT это ведь тоже потребление ресурсов.
Скажем в Сингулярити нет JIT'а. Там машинный код получается при инсталяции программы. А во время инсталяции пользователь може подождать секунд 5-10 пока системы все проверит и откомпилирует используя очень агрессивный оптимизатор.
CC>Меня бесит периодическая задумчивость 2003-й студии при открытии разного рода диалогов. Кста, стабильной ее назвать трудно — регулярно виснуть стала... Вот те и managed.

Подаляющая часть студии анменеджед. Это я тебе говорю как человек который писал расширения к студии.
CC>"портирование софта путем портирования рантайма и JIT" — где оно есть сейчас в полноценном объеме чтобы можно было что то реально переносить на разные платформы? Будет — тогда поговорим об этом.
Java куда только не портирована... Да и .NET прекрасно работает на разном железе... Проблемы при портировании возникают не с JIT'ом, а с библиотеками.

CC>А вот теперь назови мне хоть одну причину по которой нужно использовать управляемые языке во всех остальных областях.
Надежность. Я считаю что натив должен быть только так муде менеджед не реально затолкнуть.
CC>Их МОЖНО использовать, платя за это определенную цену. Получая определенное упрощение в процессе разработки. Но можно и не использовать.
На данный мемент приходится платить памятью и производительностью. Если с памятью врядли что-то можно координально решить (хотя и тут работы ведутся) то вот с производительностью...
Я не удивлюсь если через некоторое время C# сравняется с С++, а на некоторых тестах и обгонит его... А вот на реальных приложения C# легко делает С++ хотябы по тому что такие вещи на С++ писались бы намного дольше... И дело ту не только и не столько в том что там везде подушки разложены но и рантайме который позволяет применять совершенно другие архитектурные решения.

CC>Вообще по мне, так нас время рассудит. Пишите на чем угодно и под что угодно, но только не надо делать высокомерные заявления а ля "С++ больше ни на что не годен". Потому как звучит смешно. А заявление что на С++ проще сделать ошибку — так пардон, кто виноват в ошибке? Не тот ли кто ее сделал? А подумать нельзя было перед тем как начать писать?
CC>Меня удивляет желание прогеров обложить себя ватой и стремление к тому, чтоб неаккуратность и непродуманность кода на лету исправлялась компилером или средствами языка...
Я сам раньше писал на С++ и дела это очень не плохо. Вот только мне надоело постоянно думать о том где UB есть, а где нет. Лично я предпочитаю колбасить код с крейсерской скоростью 1 комплит в секунду и понимать что если друг я гдето что-то забыл то я получу по голове исключением с полным стеком я быстро пойму и испралю что не так. Это просто совершенно иной стиль работы. Пока не попробуешь не поймешь. Да да это своего рода наркотик.

CC>впрочем хватит... развивать эту тему я не намерен. Все равно каждый останется при своем мнении.
А я еще пофлеймю...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Объясняю: контроллер памяти в современном железе _всегда_ работает на уровне страниц памяти (обычно 4Кб блоков). Это аппаратное ограничение, которое никто снимать не собирается.
Я в курсе.
C>Значит нужно как-то отображать последовательный набор страниц в блоках памяти в логическое адресное пространство. Этим занимается MMU (Memory Mapping Unit). Так что обращение по любому указателю (а ссылка — это тоже указатель!) вызывает _аппратный_ lookup в адресной таблице.
C>Занимает он один такт и замечательно pipeline'ится. Программная имитация работала бы в десятки раз медленнее.
Как интересно это я тоже знаю... Вот только я не уверен что скорость обработки метаданных будет такойже. Там всетки работы побольше будет...
C>И самое интересное — для защиты памяти при наличии MMU нужно совсем немного. Надо всего лишь переключать таблицы mapping'а при переключении процесса, а это всего лишь пара записей в регистры. Ну и еще немного транзисторов для проверки битов доступа страницы.
И это как ни странно понимаю.

C>А зачем нам до байта? Нам нужны только записывать политики работы с указателями. Это будет занимать не сильно больше текущего каталога страниц.
Какойнибудь черт обязательно заведет огромный массив указателей...
Кстати а откуда вобще берутся эти волшебные таблици.

C>Unmanaged!="старые" !!!
Я тупой. Я не понимаю зачем тебе новые? Что таково в unengaged? Ну не понимаю я.

C>Минус для Singularity. Например (вы?) кто-то приводил пример, что можно будет недоверяемым приложениям разрешить доступ к файловой системе, но только через "Open File Dialog".
А может таки почитаешь про эту ОС? В данном случае не доверяемому процессу фаил может передать доверенный процесс. Причем может передать через цепочку процессов произвольной длинны.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, CreatorCray, Вы писали:

CC>Присоединяюсь. Ключевое слово "заставляет". Я за свободу выбора. Пусть бы существовали совместно но такое принудилово вызывает негатив.
А чем это отличается от работы с x86'ым процессором? Ведь тебя же тоже заставляет под него подстраиватся...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, IT, Вы писали:

IT>>Ничего особенного. Наращивание мощности путём добавления дешёвых элементов. Например, замена одного современного Windows сервера двумяста PII с линуксом. Проблема только в том, что 50% полученных ресурсов уходит на управление взаимодействием этого стада.

MS>Как говорится в анегдоте, "один еврейский мальчик таки сумел". Это я про гугл. Я слыхал, ихние базы ни фига не на майнфреймах работают. И как бы даже не очень-то под Виндовс...
Вроде Линь\Обычный Писюк. На днях на 3dnews.ru проскакивала фотография первых их компьютеров

--
Now play: Ю.Г. — Остаюсь таким же

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Может, и нет..

Скорее все же "да". Но анализ хорош. Действительно паралелизм проще достигнуть там где присуствуют высокоуровневые абстракции вроде Map/Fold. И действительно их без проблем можно использовать в ИЯ или гибридных языках. Но и в ФЯ тоже.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, slavdon, Вы писали:

Цитируй, только то на что отвечашь, плиз.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

WH>ГЦ штука такая что будет жрать память пока дают. Те если у тебя много памяти то ГЦ сожрет много памяти, а если мало то мало.

А если процессов с GC много, то как они память между собой делят?

Здравствуйте, VladD2, Вы писали:

ПК>>Может, и нет..

VD>Скорее все же "да".

Аргументация последует?

VD>Но анализ хорош. Действительно паралелизм проще достигнуть там где присуствуют высокоуровневые абстракции вроде Map/Fold. И действительно их без проблем можно использовать в ИЯ или гибридных языках. Но и в ФЯ тоже.

Там есть конкретные указания на проблемы с функциональными языками: не тот уровень гранулярности, наличие побочных эффектов в большинстве из них, слабая производительность остальных.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, CreatorCray, Вы писали:

CC>>Я не вижу причин по которым всем надо переходить на управляемые языки.
WH>А я вижу. Мне надоели программы которые постоянно падают на ровном месте. Например у меня на машине "Vampire Masquerade — Bloodlines" просто падает при старте, а на другой работала... Причем винда свеже поставленная.
А в чем тут вина неуправляемых языков? Попав молотком по пальцу ты ж молоток не винишь. Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??

CC>>Ровно точно также как я не понимаю почему например талибы хотят сделать ислам мировой религией.
WH>Одно дело тупые фанатики которые себе что-то вбили в голову. Другое дело я.
О да...

Это я пошутил, на всяк случай... звучит смешно...
WH>Я не фанатик, а самый настоящий скептик. И мне понадобилось не мало времени понять почему управляемые среды рулят.
И несешь теперь ты слово как истину. И наставляешь ты агнцев неразумных на путь истинный огнем и мечем...
Пардон муа, но со стороны это выглядит как фанатизм. Да, есть у манагед преимущества над более ранней технологией. Так зачем спорить об этом до хрипоты? Развивайся, совершенствуйся, делись знанием с тем, кому оно надо... Те, кому не надо — его не примут. А если придут эволюционно к тому же что и ты сейчас — так и хорошо. Я к примеру осознаю что рано или поздно мне придется пользовать и манагед, хотя эта концепция мне сильно не нравится в текущем ее состоянии на данный момент.

CC>>1) скорость запуска
WH>Это просто не серьезно.
Отнюдь.

CC>>и исполнения
WH>Да не так уж и сильно оно отстает.
Смотря в чем. Иногда разница в 5% уже критична...

CC>>2) потребляемая память (хотя это проблема не языка а GC)
WH>ГЦ штука такая что будет жрать память пока дают. Те если у тебя много памяти то ГЦ сожрет много памяти, а если мало то мало. Хотя некоторый перерасход всеравно есть но он много меньше чем многим кажется.
А если памяти мало даже для unmanaged? Возьми современные игры например.

CC>>3) бОльшая гибкость
WH>А вот это вобще не правда. Это я тебе говорю как человек очень хорошо знающий и С++ и .NET.
дискуссию развивать пожалуй не будем, ок? потому как это будет еще на постов 20 уже обсосанного тут флуда...

CC>>К примеру: в той области где я на данный момент работаю (геймдев) 1 и 2 — критичные параметры.
WH>Вот только не надо при мне говорить слово геймдев. Я не по наслишке знаю что это такое...
В таком случае коллега, может поделитесь своим видением managed в ресурсоемкой FPS игре?

WH>Кстати The Next Mainstream Programming Language читал?
Ща почитаю...

CC>>Также я буду считать неразумным человеком того, кто возьмется писать системные сервисы на манагед.
WH>О Singularity слышал? Там на манаджед написано большая часть ядра и все без исключения драйверы..., а ты говоришь системные сервисы...
я про широко распространенные ОС, а не про не так давно появившиеся.

CC>>Виста? Появится релиз — посмотрим...
WH>Виста к управляемым ОС не имеет никакого отношения. Это очередная ОС в линейке NT и не болие того. Да там много чего будет написано на .NET но это не делает эту ОС управляемой.
До выхода еще почти год. Что там микрософт наворотит еще не известно... грозились же весь АПИ на .нет перевести...

CC>>Все это справедливо к связке ASM vs C++. Вот примерно так же как сейчас обстоит с дело с ними будет обстоять ситуация с С++ vs managed.
CC>>Для асма все равно есть ниша. И будет пока процы выполняют машинный код. Точно так же native код будет жить и его кому то надо будет писать...
WH>Конечно будет. Я с этим даже не спорю... я даже ниши назвал в которых будет...
Основное возмущение народа вызвала как раз неточность и категоричность твоих оценок касательно ниш.

CC>>Не надо рассказывать про то, что на С# якобы вероятность сделать ошибку меньше — по мне так дело не в языке а в программере — пусть учится отвечать за свои очепятки и ошибки.
WH>Учитывая что определенный класс ошибок там просто не возможен то...
... криворукость прощать не стоит а потворствовать вообще нельзя... Но согласись, если какой то человек не способен писать на языке без ошибок а другие совершают эти ошибки на порядок меньше на том же языке то это не значит что язык плохой.

CC>>Будет широко распространено — обсудим.
WH>Дык RSDN не нем родимом написан... да и та программа которой ты пользуешься для того чтобы читать RSDN по большей части тоже...
знаю... единственная программа (кроме игр) у меня на домашнем компе которая медленнее всего работает и больше всего ест памяти. но это к слову...

WH>Кстати ее несколько раз пытались переписать на неуправляемых языках... не вышло...
кста, не вижу широкого распространения "аппаратной поддержки" к которой собственно и относилась фраза про широкое распространение... отнесем это на не совсем верное формулирование мной мысли...

CC>>"JIT все пересоберет" — выполнение JIT это ведь тоже потребление ресурсов.
WH>Скажем в Сингулярити нет JIT'а. Там машинный код получается при инсталяции программы. А во время инсталяции пользователь може подождать секунд 5-10 пока системы все проверит и откомпилирует используя очень агрессивный оптимизатор.
Гм... Не знал что настоящее название виндов — сингулярити...

Давай говорить про промышленные ОС. Про те, которые на данный момент наиболее распространены.

CC>>Меня бесит периодическая задумчивость 2003-й студии при открытии разного рода диалогов. Кста, стабильной ее назвать трудно — регулярно виснуть стала... Вот те и managed.

WH>Подаляющая часть студии анменеджед. Это я тебе говорю как человек который писал расширения к студии.
это я тоже знаю... но AFAIK гуй там на манагед. вот гуй как раз и тормозит...

CC>>"портирование софта путем портирования рантайма и JIT" — где оно есть сейчас в полноценном объеме чтобы можно было что то реально переносить на разные платформы? Будет — тогда поговорим об этом.
WH>.NET прекрасно работает на разном железе...
имелось в виду — портировано на 100% и полностью функционально и уже промышленно используется. в смысле не пример и не тест а реальный солидный рабочий продукт

CC>>А вот теперь назови мне хоть одну причину по которой нужно использовать управляемые языке во всех остальных областях.
WH>Надежность. Я считаю что натив должен быть только так муде менеджед не реально затолкнуть.
надежность в чем? в работе с памятью? и все?

CC>>Их МОЖНО использовать, платя за это определенную цену. Получая определенное упрощение в процессе разработки. Но можно и не использовать.
WH>На данный мемент приходится платить памятью и производительностью. Если с памятью врядли что-то можно координально решить (хотя и тут работы ведутся) то вот с производительностью...
WH>Я не удивлюсь если через некоторое время C# сравняется с С++, а на некоторых тестах и обгонит его...
Вообще то если подумать, то оба языка выполняют машинный код на одном и том же процессоре. В результате все вырождается в соревнование компиляторов: кто сгенерит более эффективный код. А это уже не сравнение языков а сравнение реализаций компилятора. В чистом сравнении языков будет побеждать тот, кто сгенерит меньшее колво инструкций. Это грубо говоря, т.к. в современных CPU если учесть спаривание, prefetch и проч заморочки то по колву команд сравнить нельзя... И победит в скорости тот, кто лучше с языка C++/C# оттранслирует в асм... Поэтому по скорости сравняться могут. Обогнать — лишь в случае лучшей реализации компилера, что согласись, на качество самого языка не влияет...

WH>А вот на реальных приложения C# легко делает С++ хотябы по тому что такие вещи на С++ писались бы намного дольше...
Эээ.. Мы вроде производительность результата обсуждаем а не время разработки. На дельфях народ к базам данных на готовых контролах тоже быстро проги лепил, и что?

WH>И дело ту не только и не столько в том что там везде подушки разложены но и рантайме который позволяет применять совершенно другие архитектурные решения.
Т.е. там просто к языку идет стандартная библиотека с кучей полезняшек и заготовок. И если такую библу присобачить к C++.....

WH>Я сам раньше писал на С++ и дела это очень не плохо. Вот только мне надоело постоянно думать о том где UB есть, а где нет. Лично я предпочитаю колбасить код с крейсерской скоростью 1 комплит в секунду и понимать что если друг я гдето что-то забыл то я получу по голове исключением с полным стеком я быстро пойму и испралю что не так. Это просто совершенно иной стиль работы. Пока не попробуешь не поймешь.
Смотри, мозг жиром заплывет без тренировки

Я ж про то, что кесарю — кесарево, а слесарю — слесарево... Каждому свое... со временем...

Кста, приходилось писать на жаббе... Свалил через некоторое время бо платили хреново... Не очень приятные воспоминания... Впрочем в основном благодаря менеджменту.

WH>Да да это своего рода наркотик.
"Drugs are bad, M-kay?"

CC>>впрочем хватит... развивать эту тему я не намерен. Все равно каждый останется при своем мнении.
WH>А я еще пофлеймю...
тогда не обижайся на отвечающих тебе...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

The Next Mainstream Programming Language читал?
а... читал...
использовать ЧАСТЬ двигла как скриптовый язык — разумна. Но не весь же движок на шарпе писать!

К слову, анрыловский движок всегда отличался неуемной прожорливостью... Мне ближе идеи и стиль Кармака...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>>Может, и нет..

VD>>Скорее все же "да".

ПК>Аргументация последует?

Паш, ты меня умиляшь. Может ты начнешь с себя? Я лично не увидил в твоей ссылке доказательства того что "нет".

VD>>Но анализ хорош. Действительно паралелизм проще достигнуть там где присуствуют высокоуровневые абстракции вроде Map/Fold. И действительно их без проблем можно использовать в ИЯ или гибридных языках. Но и в ФЯ тоже.

ПК>Там есть конкретные указания на проблемы с функциональными языками: не тот уровень гранулярности, наличие побочных эффектов в большинстве из них, слабая производительность остальных.

Это не указания на проблемы ФЯ. Это просто указания на возможные пробелмы. Такие проблемы есть везде. А вот указания на конкретные бенефит от выскоуровневости там точно есть. Ты просто как всегда пыташся выудить из информации только ту ее честь которая тебя устраивает. Уж твои ссылки на наличие побочных эффектов в ФЯ просто смехотворны. Они конечно где-то может и есть, но это не соизмеримо с тем количеством побочных эффектов которые есть в ИЯ.

В общем, прочитай свою ссылку еще раз по внимательнее. Особенно ту часть которая касается рассуждений о высокоуровневом стиле программирования присущем ФС.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

CC>>Присоединяюсь. Ключевое слово "заставляет". Я за свободу выбора. Пусть бы существовали совместно но такое принудилово вызывает негатив.
WH>А чем это отличается от работы с x86'ым процессором? Ведь тебя же тоже заставляет под него подстраиватся...

У x86 уже GC выискался? Я что-то пропустил?

Здравствуйте, CreatorCray, Вы писали:

CC>а... читал...
CC>использовать ЧАСТЬ двигла как скриптовый язык — разумна. Но не весь же движок на шарпе писать!

Почему нет?

Темболее, что там скорее по описанию Nemerle подходит, а не Шарп. Шарп там как альтернатива совсем уж устаревшему С++ используется и то половине требуований не удовлетворяет. Хотя часть требований там откровенно нереальна. Статическая сежфункциональная проверка индексов в компайл-тайме — это знаете ли без травы не прокатит.

Но если устранить нереальные требования, то то Nemerle с доработкой напильником (читай маросами) проходит на ура.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, McSeem2, Вы писали:

IT>>Ничего особенного. Наращивание мощности путём добавления дешёвых элементов. Например, замена одного современного Windows сервера двумяста PII с линуксом. Проблема только в том, что 50% полученных ресурсов уходит на управление взаимодействием этого стада.

MS>Как говорится в анегдоте, "один еврейский мальчик таки сумел". Это я про гугл. Я слыхал, ихние базы ни фига не на майнфреймах работают. И как бы даже не очень-то под Виндовс...

Ну вот выдет в свет ГуглОС, тогда и посмотрим что это такое

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, VladD2, Вы писали:

ПК>>>>Может, и нет..

VD>>>Скорее все же "да".

ПК>>Аргументация последует?

VD>Паш, ты меня умиляшь. Может ты начнешь с себя? Я лично не увидил в твоей ссылке доказательства того что "нет".

Читай внимательнее:

The common belief is that functional languages, such as Scheme, ML, or Haskell, could eliminate this difficulty because they are naturally suited to concurrency. Programs written in these languages manipulate immutable object instances, which pose no concurrency hazards. Moreover, without side effects, programs seem to have fewer constraints on execution order.

In practice, however, functional languages are not necessarily conducive to concurrency. The parallelism exposed in functional programs is typically at the level of procedure calls, which is impractically fine-grained for conventional parallel processors. Moreover, most functional languages allow some side effects to mutable state, and code that uses these features is difficult to parallelize automatically.

These languages reintroduce mutable state for reasons of expressibility and efficiency. In a purely functional language, aggregate data structures, such as arrays or trees, are updated by producing a copy containing a modified value. This technique is semantically attractive but can be terrible for performance (linear algorithms easily become quadratic). In addition, functional updates do nothing to discourage the writing of a strictly sequential algorithm, in which each operation waits until the previous operation updates the program’s state.

VD>>>Но анализ хорош. Действительно паралелизм проще достигнуть там где присуствуют высокоуровневые абстракции вроде Map/Fold. И действительно их без проблем можно использовать в ИЯ или гибридных языках. Но и в ФЯ тоже.

ПК>>Там есть конкретные указания на проблемы с функциональными языками: не тот уровень гранулярности, наличие побочных эффектов в большинстве из них, слабая производительность остальных.

VD>Это не указания на проблемы ФЯ.

См. выше. Эту статью Саттер упомянул в контексте обсуждения своего проекта Concur (в открытых источниках доступна эта презентация). И упомянул именно как резюме анализа того, что функциональные языки не решают проблем распараллеливания вычислений.

VD> Это просто указания на возможные пробелмы. Такие проблемы есть везде.

Не везде. Предлагаемый Саттером Concur, похоже, позволит распараллелиливать вычисления более успешно.

VD> твои ссылки на наличие побочных эффектов в ФЯ просто смехотворны. Они конечно где-то может и есть, но это не соизмеримо с тем количеством побочных эффектов которые есть в ИЯ.

Тут дело не в количестве побочных эффектов, а в их наличии. Статья обращает внимание на принципиальную проблему: если нет побочных эффектов, то ряд алгоритмов принципиально замедляется (линейные превращаются в квадратичные и т.п.), если побочные эффекты есть, то автоматическое распараллеливание не работает.

VD>В общем, прочитай свою ссылку еще раз по внимательнее. Особенно ту часть которая касается рассуждений о высокоуровневом стиле программирования присущем ФС.

The real contribution of functional languages to concurrency comes in the higher-level programming style commonly employed in these languages, in which operations such as map or map-reduce apply computations to all elements of an aggregate data structure. These higher-level operations are rich sources of concurrency. This style of programming, fortunately, is not inherently tied to functional languages, but is valuable in imperative programs.

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

Может, хватит в политику играть? Concur планируется сделать доступным и из C# в том числе.

Здравствуйте, Cyberax, Вы писали:

C>Пессимистично слишком.

в каком смысле?

C>Да, и для этого есть необходимые инструменты (умные указатели, механизм
C>деструкторов и т.п.). Еще необходимо добавить прагмы для обозначения
C>кода для SPU и соответствующую поддержку компилятора.

Не представляю, каким образом это поможет распараллеливать задачу

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Cyberax, Вы писали:
>> А что будет если железо будет контролировать каждый байт?
C>Счастье.
Никакого счастья в этом нет. Если рассуждать глобально, то вся прелесть софта — в его софтности. Железяка вынуждена действовать по заранее заданному плану.
Давай рассмотрим вымышленный пример: нам нужен арифметический процессор.
Мы можем либо встроить проверку делителя на ноль в каждую инструкцию деления, либо сделать инструкцию непроверяемой — просто в результат попадет мусор.
При этом хочется иметь гарантию корректности программ. Ты предлагаешь встроить таки проверку, и напираешь на то, что ее можно сделать зело эффективной.
Но эта проверка ценой в 0.08 такта — лишняя! Потому, что на самом деле ноль в делитель приходит очень редко.
Управляемый подход состоит в том, что проверки на ноль втыкает джит. Но! В отличие от железки, он может проследить путь каждого значения, и выкинуть проверки там, где статический анализ показал нужные гарантии. В итоге мы на елке, и попа не оцарапана — /0 не прошел, и эффективность не пострадала!
А ведь проверка безопасности операций далеко не всегда так проста, как сравнение с нулем.

1.1.4 stable rev. 510

Sinclair wrote:
>> > А что будет если железо будет контролировать каждый байт?
> C>Счастье.
> Никакого счастья в этом нет. Если рассуждать глобально, то вся прелесть
> софта — в его софтности. Железяка вынуждена действовать по заранее
> заданному плану.
Мне вот гибкости MMU вполне хватает. А механизм trap'ов позволяет
сделать виртуальную память такой гибкой, как я хочу.

> При этом хочется иметь гарантию корректности программ. Ты предлагаешь
> встроить таки проверку, и напираешь на то, что ее можно сделать зело
> эффективной.
> Но эта проверка ценой в 0.08 такта — лишняя! Потому, что /на самом деле/
> ноль в делитель приходит очень редко.
Дело в том, что если у тебя все-таки ноль появится, то рухнет _вся_
система. В моем случае упадет один процесс.

> В отличие от железки, он может проследить путь каждого значения, и
> выкинуть проверки там, где статический анализ показал нужные гарантии. В
> итоге мы на елке, и попа не оцарапана — /0 не прошел, и эффективность не
> пострадала!
Кстати-кстати. А кто мешает микрокоду анализировать машинный код?? Оно
уже, собственно, это делает для предсказания переходов.

Posted via RSDN NNTP Server 2.0

Дарней wrote:
> C>Пессимистично слишком.
> в каком смысле?
Мусор может жить долгое время после того, как он стал мусором. Механизм
region inference'а достаточно прост — мы смотрим куда может передаваться
указатель и статически продлеваем его время жизни до самого крайнего
случая.

> C>Да, и для этого есть необходимые инструменты (умные указатели, механизм
> C>деструкторов и т.п.). Еще необходимо добавить прагмы для обозначения
> C>кода для SPU и соответствующую поддержку компилятора.
> Не представляю, каким образом это поможет распараллеливать задачу
Не поможет, но позволит создавать ограниченные куски функциональности
(еще одно условие).

Posted via RSDN NNTP Server 2.0

Здравствуйте, VladD2, Вы писали:

CC>>а... читал...
CC>>использовать ЧАСТЬ двигла как скриптовый язык — разумна. Но не весь же движок на шарпе писать!
VD>Почему нет?
VD>Темболее, что там скорее по описанию Nemerle подходит, а не Шарп. Шарп там как альтернатива совсем уж устаревшему С++ используется и то половине требуований не удовлетворяет. Хотя часть требований там откровенно нереальна. Статическая сежфункциональная проверка индексов в компайл-тайме — это знаете ли без травы не прокатит.
Бездоказательно, дорогой Ватсон, бездоказательно...

В статье, такого вывода сделано не было. Т.е. вы мне сейчас опять лепите сферического коня по принципу "можно сделать".
А из статьи выходит что:

Three Kinds of Code: Revisited
Game Numeric Shading
Simulation Computation
Languages C++, Scripting C++ CG, HLSL
CPU Budget 10% 90% n/a
Lines of Code 250,000 250,000 10,000
FPU Usage 0.5 GFLOPS 5 GFLOPS 500 GFLOPS
Parallelism Software Implicit Implicit Data
Transactiona Thread Parallelism
l Memory Parallelism

полностью переходить тот же Свини не предлагает и вообще не рассматривает.

Да и вообще вся статья смахивает на размышлизмы "что будет когда будет":
CPU’s with:
– 20+ cores
– 80+ hardware threads
– >1 TFLOP of computing power

VD>Но если устранить нереальные требования, то то Nemerle с доработкой напильником (читай маросами) проходит на ура.
И наверное совсем уж "нереальным" требованием является "Performance – Language Implications: The Java/C# “exceptions everywhere” model should be wholly abandoned"?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Дарней, Вы писали:

C>>Да, и для этого есть необходимые инструменты (умные указатели, механизм
C>>деструкторов и т.п.). Еще необходимо добавить прагмы для обозначения
C>>кода для SPU и соответствующую поддержку компилятора.
Д>Не представляю, каким образом это поможет распараллеливать задачу

Кста, Intel C++ 9 уже сам умеет распараллеливать участки кода на многопоточность. Если ему разрешить это опцией...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

C>>> Еще необходимо добавить прагмы для обозначения кода для SPU и соответствующую поддержку компилятора.

Д>> Не представляю, каким образом это поможет распараллеливать задачу

CC> Кста, Intel C++ 9 уже сам умеет распараллеливать участки кода на многопоточность. Если ему разрешить это опцией...

Плюс и Intel, и VC++ (начиная с версий 7 и 8 соответственно) поддерживают OpenMP.

WolfHound wrote:
> C>Затем, что это не позволит писать софт ни на чем, кроме этого VM-языков.
> А в чем проблема то? У меня складывается впечатление что баба Яга
> против! Тебя ведь не напрягает что тебе приходится писать только на
> языках компиляторы которых есть под данный процессор? Так в чем же тут
> проблема?
Тем что процессор не заставляет меня использовать GC или не использовать
адресную арифметику.

> C>А тут нам помогут технологии виртуализации — можно будет запустить тот
> же софт в эмуляторе с JIT-транслятором x86. Вон у Apple'овцев вообще код
> из PowerPC в x86 на лету транслируется всего с 50% потерей скорости в
> Unreal Tournament 2004. Для этого эмулятора можно будет сделать
> выделенный sandbox.
> Те предлагаешь сделать таки виртуальную машину... А почему бы не
> посадить все на одну виртуальную машину которая занимается тотальными
> проверками всего что можно?
Медленно будет.

> Причем эта машина за счет оптимизатором сможет генерировать код который
> не в 2 раза медленней, а на несколько процентов.
Ну да, конечно. Эта VM будет работать на уровне VMWare, что неприемлимо
для game-development'а, например.

> C>При натыкании на указатель (слово с установленым старшим битом) —
> ошибка защиты, выполнение микрокода, который проверяет может ли код с
> данным значением IP делать модификацию указателей. И т.д.
> Те на каждый чих у нас начинает работать микро код которому нужны
> таблици чего и кому можно... ты усложняешь железо и всеравно очень
> многое зависит от софта...
Сейчас примерно такая же схема работает для MMU — и что-то никто не
жалуется, что оно работает медленно (lookup занимает один такт).

> C>Получается такой managed-assembler
> Дык чем тебе нормальный управляемый ассемблер не нравится?
Тем что это не ассемблер железа.

> C>1. Скорость.
> C>2. Гибкость.
> C>3. А чем я хуже MS??
> Хватит разводить демагогию. Ты на вопрос ответь: Какую задачу ты
> собираешься этим решать?
Пункты 1) и 2).

> C>Да. От переполнений буффера это спасает замечательно.
> А смысл? Если всеравно все держится на том что софт правильно заполнит
> таблици?
И эти люди запрещают мне копаться в носу...

Защитой стека занимается системный код, который можно проверить на
корректность (при желании).

> C>В слабой (weak) модели памяти. Сейчас ncNuma (non-cache-coherenet
> Non-Uniform Memory Access) системы редки, но в будущем их ждет
> распространие. Cell — это первый звонок.
> Еще раз какие проблемы будут у управляемых сред с такими архитектурами?
> И почему ты думаешь что у С++ получится с ними лучше?
В С# сейчас сильная модель памяти, так что Double-Lock Checking
работает. В слабой модели памяти он работать не будет, и появится еще
куча крайне интересных threading-багов.

> C>А где мой любимый C++ и
> Блин ну напиши компилятор который будет генерировать код данной
> виртуальной машины если тебе так хочется попрограммировать на этом
> антиквариате. Вот тольк зачем если тотже немерле рвет С++ как тузик грелку?
Где в Nemerle мои любимые деструкторы с нормальной семантикой?

А С++ помешает написать невозможность адресной арифметики.

> C>Assembler (который не для MSIL)???
> Это по определению не переносимо.
И что? Windows тоже по определению не переносим.

> C>Молчаливое игнорирование исключений с разрушением логической
> структуры, например. Скажешь редко бывает? Ну так и наведенные ошибки
> тоже редки.
> Вот только заглушенные исключения ловить намного проще чем чем порчу
> памяти 5-ого порядка.
Ага, конечно. А игнорирование (у нас ведь все managed и в принципе
сломаться не может!) приводит к еще более тонким ошибкам:
http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Мне вот гибкости MMU вполне хватает. А механизм trap'ов позволяет
C>сделать виртуальную память такой гибкой, как я хочу.
Вопрос, конечно, интересный. Жалко, он за пределами моей компетености.
C>Дело в том, что если у тебя все-таки ноль появится, то рухнет _вся_
C>система. В моем случае упадет один процесс.
Ну, можно конечно дуть и на воду... Но надежность верификации кода более чем высока.
>> В отличие от железки, он может проследить путь каждого значения, и
>> выкинуть проверки там, где статический анализ показал нужные гарантии. В
>> итоге мы на елке, и попа не оцарапана — /0 не прошел, и эффективность не
>> пострадала!
C>Кстати-кстати. А кто мешает микрокоду анализировать машинный код?? Оно
C>уже, собственно, это делает для предсказания переходов.
У него замочная скважина слишком узкая. Предсказывалка переходов хорошо работает только на циклах. Диспетчеризацию виртуальных методов она вряд ли предскажет.
А если сделать все по умному, то как раз окажется, что наш "машинный код" — просто еще один MSIL, т.е. аннотированный язык; джит засунут прямо в CPU, вот только размер у него маленький. Там, где сингулярити предлагает перемолоть весь процесс в сверхэффективный исполняемый код при запуске, CPU будет вынужден ограничиться размером своего внутреннего кэша, и переджитить остальное по мере поступления.
Фактически, управляемый подход смещает границы на шаг назад: то, что было бинарным кодом в памяти, становится MIL на диске, то, что было микропрограммой в CPU, стало программой в памяти. Звучит более-менее разумно; мы постепенно упираемся в ограничения физической производительности. Сколько ватт тратит P4 на дешифровку команд, их переупорядочивание, и все такое? Если мы будем подольше сохранять результаты этого процесса — вынесем их за пределы CPU, то сможем наиграть еще на маахонькую лампочку

1.1.4 stable rev. 510

Sinclair wrote:
> C>Кстати-кстати. А кто мешает микрокоду анализировать машинный код?? Оно
> C>уже, собственно, это делает для предсказания переходов.
> У него замочная скважина слишком узкая. Предсказывалка переходов хорошо
> работает только на циклах. Диспетчеризацию виртуальных методов она вряд
> ли предскажет.
Я бы не был так уверен:
http://www.cs.ucsb.edu/~urs/oocsb/papers/TRCS97-10.pdf

И это для 97 года. Сейчас еще новые техники появились.

> А если сделать все по умному, то как раз окажется, что наш "машинный
> код" — просто еще один MSIL, т.е. аннотированный язык; джит засунут
> прямо в CPU, вот только размер у него маленький.
JIT уже давно существует внутри x86-процессоров.

> Там, где сингулярити
> предлагает перемолоть /весь/ процесс в сверхэффективный исполняемый код
> при запуске, CPU будет вынужден ограничиться размером своего внутреннего
> кэша, и переджитить остальное по мере поступления.
У меня на слово "сверхэффективный" — аллергия.

> Сколько ватт тратит P4 на дешифровку команд, их
> переупорядочивание, и все такое? Если мы будем подольше сохранять
> результаты этого процесса — вынесем их за пределы CPU, то сможем
> наиграть еще на маахонькую лампочку
Точно так думали создатели Itanium'а — подсказать чем все закончилось?

Posted via RSDN NNTP Server 2.0

Здравствуйте, McSeem2, Вы писали:

MS>Как говорится в анегдоте, "один еврейский мальчик таки сумел". Это я про гугл. Я слыхал, ихние базы ни фига не на майнфреймах работают. И как бы даже не очень-то под Виндовс...

http://www.3dnews.ru/editorial/google-2006/

--
Now play: Ю.Г. — Выбей зубы на хуй

Здравствуйте, Cyberax, Вы писали:

C>Точно так думали создатели Itanium'а — подсказать чем все закончилось?

Вот здесь ты не совсем прав. Кроме провального Itanium а есть ведь ещё вполне успешная 6000 серия TMS ов.

Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, Cyberax, Вы писали:

C>>Точно так думали создатели Itanium'а — подсказать чем все закончилось?

Ш>Вот здесь ты не совсем прав. Кроме провального Itanium а есть ведь ещё вполне успешная 6000 серия TMS ов.

Плюс Интел и ХП в этом году 10 миллиардов в ракскрутку его планируют вложить, так что может что и изменится

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Шахтер, Вы писали:

Ш>>Здравствуйте, Cyberax, Вы писали:

C>>>Точно так думали создатели Itanium'а — подсказать чем все закончилось?

Ш>>Вот здесь ты не совсем прав. Кроме провального Itanium а есть ведь ещё вполне успешная 6000 серия TMS ов.

К>Плюс Интел и ХП в этом году 10 миллиардов в ракскрутку его планируют вложить, так что может что и изменится

Всё может быть. Может, для десктопов время такого сорта процессоров ещё просто не пришло.
Я бы не ставил окончательный крест на этом направлении.
Тут правда есть опасность не вписаться в time-frame. Т.е. появятся новые процессорные архитектуры, которые обесценят текущие. То же Cell От IBM или собственные Интеловские многоголовки.

Здравствуйте, Cyberax, Вы писали:

C>В С# сейчас сильная модель памяти, так что Double-Lock Checking
C>работает. В слабой модели памяти он работать не будет, и появится еще
C>куча крайне интересных threading-багов.

если он сейчас и работает, то это просто случайность. Документация настоятельно рекомендует не использовать DCLP.

C>Где в Nemerle мои любимые деструкторы с нормальной семантикой?

макрос напиши.

... << RSDN@Home 1.1.4 stable rev. 510>>

Павел Кузнецов,

ПК>

In practice, however, functional languages are not necessarily conducive to concurrency. The parallelism exposed in functional programs is typically at the level of procedure calls, which is impractically fine-grained for conventional parallel processors. Moreover, most functional languages allow some side effects to mutable state, and code that uses these features is difficult to parallelize automatically.

Товарищ Саттер утверждает, что разделение по вызовам сильно гранулировано? А в чём проблема? Подозреваю в следующем: у нас есть 2 процесса, и есть вызов:

f(g(), h())

g выполняется быстро, а h — медленно. Однако если разложить h на более мелкие составляющие, то окажется, что она состоит из других элементарных операций — например, вызова других функций (которые тоже раскладываются), манипуляций со списками/туплами, сравнений, арифметических операций и BIF-ов. Так что грануляция довольно-таки fine. Трудности возникнут, когда скажем

h() ->
  A1 = fn(1),
  A2 = fn(A1),
  ...
  A100 = fn(A99).

Но в таких случаях и ИЯ не помогут. Нужен другой алгоритм.

These languages reintroduce mutable state for reasons of expressibility and efficiency. In a purely functional language, aggregate data structures, such as arrays or trees, are updated by producing a copy containing a modified value. This technique is semantically attractive but can be terrible for performance (linear algorithms easily become quadratic).

Однако не забываем, что анализ — штука важная, и во многих случаях будет тот же mutable state, только за шторками. Поясню:

A1 = modify(A0).

Если A0 ниже нигде не используется, то многие современные ФЯ (если не все) просто делают модификацию A0.
Если используется и A0, и A1, то можно предложить целую кучу путей:

1. Хранить и A0, и A1, для ссылки A0 использовать A0, для A1 -> A1
2. Хранить A0, и diff(A0,A1), для ссылки A0 использовать A0, для A1 - вычисление A0 + diff
3. То же самое, что и 2, только хранить A1.
4. Хранить некий промежуточный A_, diff(A0, A_), diff(A1, A_);
    A0 -> A_ + diff(A0, A_), A1 -> A_ + diff(A1, A_)

Так что с эффективностью не всё так просто: теоретических проблем для оптимизации нет, нужны только практические воплощения идей.

Кроме того не стоит забывать, что введение mutable state хоть и сохранит O(n^m), но может подавить возможность параллелизации. (Возможно обратное тоже верно, но я как-то пример не могу вообразить сходу).

In addition, functional updates do nothing to discourage the writing of a strictly sequential algorithm, in which each operation waits until the previous operation updates the program’s state.

Да, конечно, (я говорил об этом выше). Что вообще предлагается делать в этом случае (ИЯ, ФЯ — неважно)?

ПК>Не везде. Предлагаемый Саттером Concur, похоже, позволит распараллелиливать вычисления более успешно.
Ну чтож:

* define higher-level abstractions (above "threads and locks")
* for today’s imperative languages (examples are in C++)
* that evenly support the range of concurrency granularities
* to let developers write correct and efficient concurrent applications
* with lots of latent parallelism (and not lots of latent bugs)
* that can be efficiently mapped to the user’s hardware to reenable the free lunch.

Пока ничего конкретного.

Здравствуйте, Дарней, Вы писали:

Д>подозреваю, что как раз там будут рулить ФЯ

Не будут. Не умеют они рулить.

Рулить там будет или Оккам или его ближайший потомок.

Д>по крайней мере, функции без сторонних эффектов и лямбда-функции вполне этому способствуют

Особо сильно они способствуют высокой производительности!
Самому не смешно, а?

Здравствуйте, Cyberax, Вы писали:

C>WolfHound wrote:
>> C>А еще функции должны работать только с ограниченым по размеру
>> окружением. И без всякого GC — он в 256Кб не поместится.
>> Функциональные вычисления очень хорошо поддаются автоматическому
>> разбиению на части если это вобще возможно для выбранного алгоритма.
C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это
C>неприемлимо.

Это не так. Весь memory management может делаться на этапе компиляции. Кажется
MLTon это умеет.

Здравствуйте, CreatorCray, Вы писали:

VD>>Темболее, что там скорее по описанию Nemerle подходит, а не Шарп. Шарп там как альтернатива совсем уж устаревшему С++ используется и то половине требуований не удовлетворяет. Хотя часть требований там откровенно нереальна. Статическая сежфункциональная проверка индексов в компайл-тайме — это знаете ли без травы не прокатит.
CC>Бездоказательно, дорогой Ватсон, бездоказательно...

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

Я спросил:

Почему нет?

И ответа не получил. Вместо этого плучил рассуждения о бездакозательности чего-то.

CC>В статье, такого вывода сделано не было.

В презентахе вообще небыло выводов. В презентахе было мнение о том, что ее автор хочет видеть в некоем гипотетическом идеальном для него языке.

CC> Т.е. вы мне сейчас опять лепите сферического коня по принципу "можно сделать".

Кто такие мы? Я здесь один.

И не надо этих эпититов "лепите". Учись переживать когда чужое мнение не совпадает с твоим.

CC>А из статьи выходит что:
CC>

CC>Three Kinds of Code: Revisited
CC> Game Numeric Shading
CC> Simulation Computation
CC>Languages C++, Scripting C++ CG, HLSL
CC>CPU Budget 10% 90% n/a
CC>Lines of Code 250,000 250,000 10,000
CC>FPU Usage 0.5 GFLOPS 5 GFLOPS 500 GFLOPS
CC>Parallelism Software Implicit Implicit Data
CC> Transactiona Thread Parallelism
CC> l Memory Parallelism

CC>полностью переходить тот же Свини не предлагает и вообще не рассматривает.

Хм. Процитировал первый попашийся абзац и сделал далеко идущие выводы. Ты жту призентаху посмотри внимательнее. Тогда заметишь, что она посвящена рассуждениям о том, что нужен новый язык и что в этом языке должно быть. С++ в качестве прототипа такого языка принципиально не рассматривается, так как уже не удовлетворяет большинству критериев.

В статье реально упомянуты два языка — C# как варинт типобезопасного языка решающего 50% стояхищ проблем, и Хаскель как язык содержащий решение, по мнению автора, для остальных 50%.

CC>Да и вообще вся статья смахивает на размышлизмы "что будет когда будет":
CC>CPU’s with:
CC>– 20+ cores
CC>– 80+ hardware threads
CC>– >1 TFLOP of computing power

Вообще-то статья посвящена размышлениям о том какой язык нужен в будущем. А цифры — это предпологаемые мощьности процессоров в этом самом ближайшем будущем. По крайней мере я это так понял.

VD>>Но если устранить нереальные требования, то то Nemerle с доработкой напильником (читай маросами) проходит на ура.
CC>И наверное совсем уж "нереальным" требованием является "Performance – Language Implications: The Java/C# “exceptions everywhere” model should be wholly abandoned"?

Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции. Хотя конечно отказ от исключений тоже нереален. Как минимум потому, что если нельзя контролировать вызод за еределы массивов в компайлтайме, то прийдется генерировать исключения в случае чего. Ну, и деление на 0 тоже никто не отменял. Его тоже полностью исключить нельзя.

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

В любом случае Nemerle удовлетворяет (или позволяет удовлетворить) большинству критериев перечисленных в презентахе. Языков удовлетворяющих в большей степени я попросту не знаю. У того же Хаскеля сам автор назвал кучу проблемных мест.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WinniePoh, Вы писали:

WP> Особо сильно они способствуют высокой производительности!
WP> Самому не смешно, а?

отличная иллюстрация к соседней теме, где обуждается невежество менеджмента

... << RSDN@Home 1.1.4 stable rev. 510>>

WinniePoh wrote:
> C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это
> C>неприемлимо.
> Это не так. Весь memory management может делаться на этапе компиляции.
> Кажется MLTon это умеет.
Ага, конечно. Почитайте про region inference.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, WinniePoh, Вы писали:

WP>> Особо сильно они способствуют высокой производительности!
WP>> Самому не смешно, а?

Д>отличная иллюстрация к соседней теме, где обуждается невежество менеджмента

Да стебусь я, стебусь. Про Clean знаю, и про MLTon.
Только все равно лямбда это вовсе не тот уровнеь абстракции который нужен в том классе задач под
которые заточен CELL.

А нужно тут вот что (лямбда ему — всего лишь частный случай):
http://en.wikipedia.org/wiki/Pi_calculus

Здравствуйте, VladD2, Вы писали:

VD>Я спросил:
VD>

Почему нет?

VD>И ответа не получил.
А получил фактически встречный вопрос: почему да? и зачем?

VD>Вместо этого плучил рассуждения о бездакозательности чего-то.
Итак:
CC>>Но не весь же движок на шарпе писать!
VD>Почему нет?
CC>>Бездоказательно...
По мне так ежу понятно что в вопросах производительности на данный момент при сравнении с C++ у шарпа не все в шоколаде. Поэтому все же интересно, как VD собирается аргументировать смысл переписывания всего движка игры,причем Unreal3, о котором шла речь у Свини, с его прожорливостью к ресурсам, с C++ на С#.
Переписать часть — можно и возможно даже нужно. Но переписывать всё... без комментариев.

VD>В презентахе вообще небыло выводов. В презентахе было мнение о том, что ее автор хочет видеть в некоем гипотетическом идеальном для него языке.
И для чего именно этот язык он собирался применять?

CC>> Т.е. вы мне сейчас опять лепите сферического коня по принципу "можно сделать".
VD>Кто такие мы? Я здесь один.

хорошо — ты.
VD>И не надо этих эпититов "лепите". Учись переживать когда чужое мнение не совпадает с твоим.
без комментариев

VD>Хм. Процитировал первый попашийся абзац и сделал далеко идущие выводы. Ты жту призентаху посмотри внимательнее. Тогда заметишь, что она посвящена рассуждениям о том, что нужен новый язык и что в этом языке должно быть. С++ в качестве прототипа такого языка принципиально не рассматривается, так как уже не удовлетворяет большинству критериев.
VD>Вообще-то статья посвящена размышлениям о том какой язык нужен в будущем. А цифры — это предпологаемые мощьности процессоров в этом самом ближайшем будущем. По крайней мере я это так понял.
А как я понял так этот новый язык и не рассматривался как основной а скорее как замена той части, что написана у Свини на скриптовом. Те самые 10% Simulation.
Допускаю что мог ошибиться. В таком случае прошу указать из чего в статье можно судить о планах глобального применения этого языка.

CC>>И наверное совсем уж "нереальным" требованием является "Performance – Language Implications: The Java/C# “exceptions everywhere” model should be wholly abandoned"?
VD>Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции. Хотя конечно отказ от исключений тоже нереален. Как минимум потому, что если нельзя контролировать вызод за еределы массивов в компайлтайме, то прийдется генерировать исключения в случае чего. Ну, и деление на 0 тоже никто не отменял. Его тоже полностью исключить нельзя.
Речь шла конкретно об "exceptions everywhere". Ситуации где без исключений совсем не обойтись в это не входят.

Короче твоя моя не поняла...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Читай внимательнее:...

И тебе того же:

The real contribution of functional languages to concurrency comes in the higher-level programming style commonly employed in these languages, in which operations such as map or map-reduce apply computations to all elements of an aggregate data structure. These higher-level operations are rich sources of concurrency. This style of programming, fortunately, is not inherently tied to functional languages, but is valuable in imperative programs.

ПК>См. выше. Эту статью Саттер упомянул в контексте обсуждения своего проекта Concur

Дык надо же ему обосновать приемущество своих идей над чужими?

Это банальный пиар. Вот когда он сделает реальное решение и большая часть людей признает его лучшим, то и поговорим на счет врености подобных утверждений.

Характерно то, что даже его утверждения как бы косвенно подтверждают, что таки ФЯ имет большой задел в области паралеллизма.
Это я слышал от многих людей занимающихся параллелизмом. В том числе и Фаеновым из МС.

VD>> Это просто указания на возможные пробелмы. Такие проблемы есть везде.

ПК>Не везде. Предлагаемый Саттером Concur, похоже, позволит распараллелиливать вычисления более успешно.

"похоже..." это не аргумент. Не он один работает над данными проблемами, и не факт, что его решение будет лучше других.

В конце концов в области параллелизма есть не так много идей. Я бы сказал три:
1. Избавиться от побочных эффектов в вычисленихя и распараллеливать их.
2. Привязывать объекты или другие сущьности к одному потоку и организовывать общение между такими объектами по средствам сериализованных сообщений.
3. Жить по старинке на блокировках и ручном распараллеливании.

Очевидно, что исследования будут идти только в первых областях.

VD>> твои ссылки на наличие побочных эффектов в ФЯ просто смехотворны. Они конечно где-то может и есть, но это не соизмеримо с тем количеством побочных эффектов которые есть в ИЯ.

ПК>Тут дело не в количестве побочных эффектов, а в их наличии. Статья обращает внимание на принципиальную проблему: если нет побочных эффектов, то ряд алгоритмов принципиально замедляется (линейные превращаются в квадратичные и т.п.), если побочные эффекты есть, то автоматическое распараллеливание не работает.

Ну, это вообще проблема ФЯ. Однако многие задачи решаются в функциональном стиле довольно эффективно. В общем, это философия. Реальные решения скорее всего будут неким компромисом. Там где эффективно вычислительное распараллеливание будет применяться оно. Там где выгодно выделять отдельные логические блоки живущие независимо будут применяться идеи активных объектов/микропроцессов.

Ну, а где-то будут по старинке использоваться блокировки.

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

ПК>Может, хватит в политику играть? Concur планируется сделать доступным и из C# в том числе.

Какая политика? Мне плевать кто куда что пытается встроить. В Nemerle уже встроена поддержка параллелизма аналогичная СиОмеговской. И что?

Я обсуждаю высказвания идей. Выделяю при этом здравые мысли и слова говорящиеся под влиянием корысных интересов. Только и всего.

Мне млевать кто их говорит. Мне важна суть. Я отчасти согласен с Саттером, а от части нет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>У x86 уже GC выискался? Я что-то пропустил?

А в управеляемой ОС обязательно должен быть ГЦ? Или я что-то пропустил?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Павел Кузнецов, Вы писали:

WH>>ГЦ штука такая что будет жрать память пока дают. Те если у тебя много памяти то ГЦ сожрет много памяти, а если мало то мало.
ПК>А если процессов с GC много, то как они память между собой делят?
Точные механизмы как это происходит сейчас я не знаю. Но мы эксперементировали запустив довольно навороченный сервер приложений и смартклиент в виртуальной машине с 64М памяти и отключеным свопом... оно конечно тормозило но работало. Причем в таскменеджере было видно как память перетекает от сервера приложений к смартклиенту и обратно в зависимости от того кто работает.
И это происходило в WinXP. А в управляемой ОС можно сделать координацию мусорщиков на всю катушку. Так что я тут вобще не вижу проблем.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, CreatorCray, Вы писали:

Давайте рассатвим все точки над Ё. Мы находимся в форуме "Философия программирования" и философствуем от программирование. Мне в данный момент не интересно что происходит сейчас. Мне интересно что будет дальше. Как и почему это может выглядить. По этому я не буду ограничивать себя распространенными промышленными системами.

Кстати раз ты начал приводить аналогии и разводить демагогию то чтож... кто не спрятался я не виноват...

CC>А в чем тут вина неуправляемых языков? Попав молотком по пальцу ты ж молоток не винишь.
А зачем не использовать простой молоток если я могу взять пневматический и получить прирост производительности забивания гвоздей и гарантию того что не отобью себе пальци?
CC>Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??
Уж не намекаешь ли ты на то что у меня руки из ж растут? Ты конечно можешь считать как угодно но например brainbench считает что я знаю С++ лучше чем 99.9% проходивших этот тест...

CC>И несешь теперь ты слово как истину. И наставляешь ты агнцев неразумных на путь истинный огнем и мечем...
Куда несу? Я обсуждаю и прошу своих апонентов изложить свою точку зрения и аргументировать необходимость нативных языков в место этого я получаю обвинения в фанатизме, буйство демагогии и полное отсутствие технических агрументов

WH>>Это просто не серьезно.
CC>Отнюдь.
Если программа стартует пару минут (а это с играми случается) то пара лишних секунд на разогорев ВМ ничего не решат.

CC>Смотря в чем. Иногда разница в 5% уже критична...
Например я бы предпочем чтобы "Vampire Masquerade — Bloodlines" работал в два раза медленней но РАБОТАЛ.

CC>А если памяти мало даже для unmanaged? Возьми современные игры например.
А что современные игры? Если бы разработчики болие тщательно подходили к архитектуре то они бы и работали быстрее и памяти ели меньше. Болие того они бы просто работали...

CC>дискуссию развивать пожалуй не будем, ок? потому как это будет еще на постов 20 уже обсосанного тут флуда...
Это конечно твое право но в твоих сообщениях прослеживается явное не знание тогоже .NET'а.

CC>В таком случае коллега, может поделитесь своим видением managed в ресурсоемкой FPS игре?
А какие собственно проблемы?

CC>До выхода еще почти год. Что там микрософт наворотит еще не известно... грозились же весь АПИ на .нет перевести...
Да ничего там не будет. NT она и в африке NT.

CC>Основное возмущение народа вызвала как раз неточность и категоричность твоих оценок касательно ниш.
Возмущение, демагогия, обвинения во всех смертных грехах были, а вот аргументов почему я не прав небыло.

CC>... криворукость прощать не стоит а потворствовать вообще нельзя... Но согласись, если какой то человек не способен писать на языке без ошибок а другие совершают эти ошибки на порядок меньше на том же языке то это не значит что язык плохой.
Хватит называть меня криворуким. Надоело уже.
Когда я писал на С++ я постоянно думал о том где тут может быть UB, как избежать циклических ссылок и тп
На C# с ReSharper'ом я пишу в совершенно другой манере. Я все свои мозговые ресурсы сосредотачиваю на архитектуре, а не на коде. Код за меня пишет ReSharper, а я только показываю ему направление движения. Сосредоточившись на архитектуре и раставив в критических местах проверки я уверен что если я что-то забуду то тут же вылетит исключение и я это исправлю. Причем до тестеров ошибки практически не доходят, а если и доходят то в подавляющем большинстве их ноги растут из того что я непонял ТЗ или ТЗ было не точным.

CC>знаю... единственная программа (кроме игр) у меня на домашнем компе которая медленнее всего работает и больше всего ест памяти. но это к слову...
А ты знаешь что там тормозит и жрет память? Вот когда узнешь тогда и делай выводы...
hint:В Янусе использованы JET и IE...

CC>кста, не вижу широкого распространения "аппаратной поддержки" к которой собственно и относилась фраза про широкое распространение... отнесем это на не совсем верное формулирование мной мысли...
Еще раз аппаратная поддержка управляемым ОС нужна гораздо меньше чем современным.

CC>имелось в виду — портировано на 100% и полностью функционально и уже промышленно используется. в смысле не пример и не тест а реальный солидный рабочий продукт
Что значит на 100%? Рантайм портирован на 100%. Библиотеки портированны не все. Но дело в том что некоторые библиотеки платформозависимои и их просто нельзя портировать тк они используют WinAPI и тп...

CC>надежность в чем? в работе с памятью? и все?
Дык основные проблемы какраз с памятью и возникают. К томуже в управляемых средах частично можно проверять логику программы.

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

WH>>А вот на реальных приложения C# легко делает С++ хотябы по тому что такие вещи на С++ писались бы намного дольше...
CC>Эээ.. Мы вроде производительность результата обсуждаем а не время разработки. На дельфях народ к базам данных на готовых контролах тоже быстро проги лепил, и что?
Э нет братан. Если приложение не написано то его производительность не играет роли тк ее (производительности) вобще нет.

WH>>И дело ту не только и не столько в том что там везде подушки разложены но и рантайме который позволяет применять совершенно другие архитектурные решения.
CC>Т.е. там просто к языку идет стандартная библиотека с кучей полезняшек и заготовок. И если такую библу присобачить к C++.....

Это конечно тоже не маловажно но у .NET эсть еще и очень мощьная среда испольнения.
И благодоря этой среде можно использовать архитектурные решения на которые при разработки на С++ я бы просто не решился ибо без поддержки среды данные решения даже еслибы и были реализованны какимто чудом то былибы очень не стабильны и подвержены большому колличеству ручной работы и как следствие ошибкам.

CC>Смотри, мозг жиром заплывет без тренировки

Не боись не заплывут. Просто я думаю не о мелких деталях типа "если написать так то будет UB", а об архитектуре программы.

CC>Кста, приходилось писать на жаббе... Свалил через некоторое время бо платили хреново... Не очень приятные воспоминания... Впрочем в основном благодаря менеджменту.
Те неприятные воспоминания о менеджере ты распространяешь на все управляемые среды? Сдорово

CC>тогда не обижайся на отвечающих тебе...
Если ты думаешь что можешь меня обидеть... то ты глубоко ошибаешься.
Если ты конечно начнешь ругатся матом то я как модератор буду просто обязан тебя забанить и как минимум вырезать мат из твоих сообщений.
Но обижатся я не стану. Я выше этого.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> ГВ>У x86 уже GC выискался? Я что-то пропустил?
> А в управеляемой ОС обязательно должен быть ГЦ? Или я что-то пропустил?
Да, GC быть _обязан_. Причем любые неGC-механизмы управления памятью —
невозможны (точнее возможны, но с потенциалом порушить всю систему).

Только GC может гарантировать отсутствие "висячих указателей".

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Тем что процессор не заставляет меня использовать GC
А что управляемая ОС заставляет использовать ГЦ? Например в сингулярити можно для конкретного процесса отключить ГЦ.
C>или не использовать адресную арифметику.
Зачем тебе адресная арифметика?

>> Те предлагаешь сделать таки виртуальную машину... А почему бы не посадить все на одну виртуальную машину которая занимается тотальными проверками всего что можно?
C>Медленно будет.
Правда? А почему тогда сингулярити на многих тестах рвет и винду и линух? Она же по определению медленная?

C>Ну да, конечно. Эта VM будет работать на уровне VMWare, что неприемлимо для game-development'а, например.
Нет. Она будет работать как минимун на уровне .NET. А если учесть что раблты по разработке оптимизаторов ведутся постоянно то...

C>Сейчас примерно такая же схема работает для MMU — и что-то никто не жалуется, что оно работает медленно (lookup занимает один такт).

в MMU используются тривиальные таблици. Тут же придется использовать гораздо болие сложные сущьности. И даже если это какимто чудом удатся свести к одному такту в чем я очень сильно сомневаюсь то это будет стоить прорву транзисторов.

C>Тем что это не ассемблер железа.
А зачем тебе ассеблер железа?

>> C>1. Скорость.
>> C>2. Гибкость.
C>Пункты 1) и 2).
Ты можешь назвать задачу которую ты этим решаешь?

C>Защитой стека занимается системный код, который можно проверить на корректность (при желании).
О! Код! Те таки софт! Так зачем нам еще железо если код и без железа может проверить все?

C>В С# сейчас сильная модель памяти, так что Double-Lock Checking работает. В слабой модели памяти он работать не будет, и появится еще куча крайне интересных threading-багов.
Угу... хреново он работает.
Кстати как это отностися к управляемым средам? Не понимаю.

C>Где в Nemerle мои любимые деструкторы с нормальной семантикой?
На нахрен не нужны эти деструкторы. Я сам долго плевался по поводу их отсутствия но потом понял что можно работать и без них ничего не теряя.

C>А С++ помешает написать невозможность адресной арифметики.
Ее можно эмулировать.

C>И что? Windows тоже по определению не переносим.
Эты ты мелкософтам скажи...
Например смотри фаил atlstdthunk.h

C>Ага, конечно. А игнорирование (у нас ведь все managed и в принципе сломаться не может!) приводит к еще более тонким ошибкам: http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1
Игнорирование чего? Там какойто умник создал кривую архитектуру и в этом виновата жаба?
Дело в том что на С++ можно сделать такуюже ошибку, а вот записать в чужую память в жабе нельзя.
К томуже как я уже говорил эту ошибку ловить гораздо легче ведь у нас есть последовательность действий для ее воспроизведения и нам нужно просмотреть только те места которые отвечают непосредственно за сериализацию.
А вот если бы дело было при разработке на С++ то память могло бы попортить например то кокшко с сообщением об ошибке... или вобще что-то никак не связаное с сериализацией.
Те масштабы поиска ошибки совсем иные.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Да, GC быть _обязан_. Причем любые неGC-механизмы управления памятью — невозможны (точнее возможны, но с потенциалом порушить всю систему).
C>Только GC может гарантировать отсутствие "висячих указателей".
Раскажи это авторам сингулярити.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, VladD2, Вы писали:

VD>Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции.
Реально. Например так

void TwiceRange(int[] array, int begin, int length)
    required array != null && begin > 0 && length > 0 && begin + length < array.Length
    otherwise compile error
{
    for (int i = begin; i < begin + length; ++i)
        array[i] = array[i] * 2;
}

теперь если написать так

void DoSome(int[] array, int begin)
{
    TwiceRange(array, begin, 5);
}

То будет ошибка компиляции по тому что значения параметров TwiceRange не проверены
А если написать например так

void DoSome(int[] array, int begin)
    required array != null && begin > 0
    otherwise compile error
{
    if (begin + 5 < array.Length)
        TwiceRange(array, begin, 5);
}

То все скомпилируется ибо статический анализ вполне сможет все проверить.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Тем что процессор не заставляет меня использовать GC
> А что управляемая ОС заставляет использовать ГЦ? Например в сингулярити
> можно для конкретного процесса отключить ГЦ.
Ну да, и наслаждаться только статически распределенной памятью. Или как
варинат распределить память ровно 1 раз (освобождать некому).

Сам подумай: что будет с OS без защиты памяти, если я сделаю ручной
delete для объкта, затру это место другими данными, а потом попробую
обратиться по висячему указателю?

> C>или не использовать адресную арифметику.
> Зачем тебе адресная арифметика?
А просто так. Для скорости, например.

> C>Медленно будет.
> Правда? А почему тогда сингулярити на многих тестах рвет и винду и
> линух? Она же по определению медленная?
Оно рвет Винду так как целиком работает в нулевом кольце аппаратной защиты.

У меня вот есть программа, которая в DOS (мы тоже на нулевом кольце)
рвет свою версию для Windowsов и Linuxов как тузик грелку. Так что,
теперь у нас DOS — будущее софтостроения?

> C>Сейчас примерно такая же схема работает для MMU — и что-то никто не
> жалуется, что оно работает медленно (lookup занимает один такт).
> в MMU используются тривиальные таблици. Тут же придется использовать
> гораздо болие сложные сущьности. И даже если это какимто чудом удатся
> свести к одному такту в чем я очень сильно сомневаюсь то это будет
> стоить прорву транзисторов.
Нам нужен lookup не в одной, а в двух таблицах (по источнику и цели).
Таблицы тоже можно сделать достаточно простыми.

> C>Тем что это не ассемблер железа.
> А зачем тебе ассеблер железа?.
Скорость.

> C>Пункты 1) и 2).
> Ты можешь назвать задачу которую ты этим решаешь?
Разработку конкуррентных приложений. Нафиг заказчику мой крутой софт,
если соседняя фирма производит софт, работающий быстрее? И при этом
подобный по функциональности.

> C>Защитой стека занимается системный код, который можно проверить на
> корректность (при желании).
> О! Код! Те таки софт! Так зачем нам еще железо если код и без железа
> может проверить все?
Потому что _нельзя_ проверить все без драконовских ограничений.

> C>В С# сейчас сильная модель памяти, так что Double-Lock Checking
> работает. В слабой модели памяти он работать не будет, и появится еще
> куча крайне интересных threading-багов.
> Угу... хреново он работает.
> Кстати как это отностися к управляемым средам? Не понимаю.
Это я про портабельность. Этот аспект портабельности известен давно, что
не помешало MS наступить на грабли. А что будет с новыми ncNUMA-системами?

> C>И что? Windows тоже по определению не переносим.
> Эты ты мелкософтам скажи...
> Например смотри фаил atlstdthunk.h
А у нас Windows под Linux работает? И не в Wine/VMWare?

> C>Ага, конечно. А игнорирование (у нас ведь все managed и в принципе
> сломаться не может!) приводит к еще более тонким ошибкам:
> http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1
> <http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1>
> Игнорирование чего? Там какойто умник создал кривую архитектуру и в этом
> виновата жаба?
Нет, это к чему приводит пресловутая устойчивость (вот в С++ у нас бы
уже все давно упало, а тут жмем "Ignore exception" и работаем дальше!).

> К томуже как я уже говорил эту ошибку ловить гораздо легче ведь у нас
> есть последовательность действий для ее воспроизведения и нам нужно
> просмотреть только те места которые отвечают непосредственно за
> сериализацию.
Агащаз. У вас есть поврежденные файлы.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Павел Кузнецов, Вы писали:

CC>> Кста, Intel C++ 9 уже сам умеет распараллеливать участки кода на многопоточность. Если ему разрешить это опцией...
ПК>Плюс и Intel, и VC++ (начиная с версий 7 и 8 соответственно) поддерживают OpenMP.
А теперь обьясните какие проблемы сделать тоже самое в управляемой среде?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Да, GC быть _обязан_. Причем любые неGC-механизмы управления памятью —
> невозможны (точнее возможны, но с потенциалом порушить всю систему).
> C>Только GC может гарантировать отсутствие "висячих указателей".
> Раскажи это авторам сингулярити.
А где это написано в TR?

В статически-анализируемом безопасном софте GC отключать нельзя.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Ну да, и наслаждаться только статически распределенной памятью. Или как варинат распределить память ровно 1 раз (освобождать некому).
Для какогонибудь драйвера это вполне оправдано.

C>Сам подумай: что будет с OS без защиты памяти, если я сделаю ручной delete для объкта, затру это место другими данными, а потом попробую обратиться по висячему указателю?
Да ничего не будет. Просто по тому что ОС тебе не даст удалять память. В место этого тебе придется сделать менеджер памяти самому что-то типа

struct Foo
{
    public static Foo* New()
    {
        return MemoryManager<Foo>.Create();
    }
}
class MemoryManager<T>
{
    const int ThunkSize = 128;
    class Thunk
    {
        public Thunk* Next = null;
        public bool[ThunkSize] Free = {true ..};
        public Foo[ThunkSize] Mem = {Default(t) ..};
    }
    ...
    public static T* Create()
    {
        Thunk* t = GetFreeThunk();
        for(int i = 0; i < ThunkSize; ++i)
            if (t.Free[i])
                return &t.Mem[i];
    }
    public static void Delete(T* obj)
    {
        ...
    }
}

Дальше писать лень но ты понял...
Короче физически висящих указателей не будет. Будут логически висящие... Но мы же не ищем легких путей? Правда?

C>Оно рвет Винду так как целиком работает в нулевом кольце аппаратной защиты.
Вот именно. Она не использует такую мегакрутую и быструю аппаратную защиту... А ты предлагаешь еще навернуть защиту чтобы она работала еще меодленней. Ведь ничего в это мире бесплатно не бывает.

C>У меня вот есть программа, которая в DOS (мы тоже на нулевом кольце) рвет свою версию для Windowsов и Linuxов как тузик грелку. Так что, теперь у нас DOS — будущее софтостроения?
А вот это уже демагогия.

C>Нам нужен lookup не в одной, а в двух таблицах (по источнику и цели).
C>Таблицы тоже можно сделать достаточно простыми.
О уже две таблици... Короче огоромное колличество логики в ядре.

C>Разработку конкуррентных приложений. Нафиг заказчику мой крутой софт, если соседняя фирма производит софт, работающий быстрее? И при этом подобный по функциональности.
Корость это не проблема. Ни с теоритической ни с практической точки зрения (см сингулярити).
Так что я могу заключить что у тебя нет аргументов в пользу того что нужно использовать нативный код.

C>Потому что _нельзя_ проверить все без драконовских ограничений.
Да какая разница где эти ограничения будут в железе или в софте?

C>Это я про портабельность. Этот аспект портабельности известен давно, что не помешало MS наступить на грабли. А что будет с новыми ncNUMA-системами?
А какое это отношение имеет к управляемым ОС?

C>А у нас Windows под Linux работает? И не в Wine/VMWare?
Ох и любиш же ты разговор в сторону уводить

Причем тут виндовс под линух? Мы же вроде о железе говорим. Так вот ассемблер (если не использовать функции ОС) прекрасно портируется между разными ОС работающими на одном железе.

C>Нет, это к чему приводит пресловутая устойчивость (вот в С++ у нас бы уже все давно упало, а тут жмем "Ignore exception" и работаем дальше!).
А вот я не уверен что все бы упало! Я практика показывает что довольно часто не падает...

C>Агащаз. У вас есть поврежденные файлы.

У меня была такая ситуация: программа (на Java) читает архив с сериализованными классами (через свой десериализатор), в процессе десериализации одного из классов в некоторых случаях происходил глюк, в результате которого портилась статическая (точнее thread local) переменная и кидалось NullPointerException. Программа это исключение вылавливала ("catch(Throwable t)") и выводила красивое окошко с ошибкой о поврежденном файле.

Ну блин... самже все написал...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>А где это написано в TR?

3.6 Customized Run-time Systems
Singularity’s architecture permits SIPs to host completely different run-time systems, which allows a runtime to be customized for each process. For example, SIPs running sequential code may not need the support for thread synchronization required by SIPs with multiple threads. SIPs without objects requiring finalization (or having finalizers that do not access data shared among threads) may not need a separate finalizer to observe the required language semantics for finalizers. SIPs with certain allocation strategies may be able to pre-allocate or stack-allocate memory for all used objects, obviating the need for a garbage collector in the SIPs runtime.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> finalizers. *SIPs with certain allocation strategies may be able to
> pre-allocate or stack-allocate memory for all used objects, obviating
> the need for a garbage collector in the SIPs runtime.*
Это не означает работу без GC и полноценное ручное управление памятью.
Это всего лишь означает неиспользование GC.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Это не означает работу без GC и полноценное ручное управление памятью.
C>Это всего лишь означает неиспользование GC.
Те убирания кода ГЦ из процессе не означает не использование ГЦ? Очень интересно.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, CreatorCray, Вы писали:

VD>>И ответа не получил.
CC>А получил фактически встречный вопрос: почему да? и зачем?

Именно. А подобные страдиции мне не нарвятся. По этому отвечать на встречные вопросы не хочу.

CC>По мне так ежу понятно что в вопросах производительности на данный момент при сравнении с C++ у шарпа не все в шоколаде.

Это только по-тоему. И это "по-твоему" основано на фобиях. Как видишь в указанной презентахи люди даже не думают об этом. Их интересуют возможности языка в области повышения надежности кода.

CC> Поэтому все же интересно, как VD собирается аргументировать смысл переписывания всего движка игры,причем Unreal3, о котором шла речь у Свини, с его прожорливостью к ресурсам, с C++ на С#.

Отвечать на выводы основанные ни на чем не интересно.
Замечу лишь, что переписывать никто ничего не собирался.
Unreal3 находится в стадии близкой к стадии готовности. Переписывать его никто не будет.
В презентации речь идет о будещем. Том что будет за Unreal3. О проектах которые надо сдавать через несколько лет. И для которых сейчас нужно задуматься о выборе подходящего инструмента.

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

Заметь, никаких фанатств в отношении какого-то конкретного языка в презинтации нет. Там гворится о потребностях.

CC>Переписать часть — можно и возможно даже нужно. Но переписывать всё... без комментариев.

Преписать? Зачем? И на чем? Ты не заметил, что автор не видит готового языка?
Ты хоть внимательно прочел развание презентации?

The Next Mainstream
Programming Language:
A Game Developer’s Perspective

VD>>В презентахе вообще небыло выводов. В презентахе было мнение о том, что ее автор хочет видеть в некоем гипотетическом идеальном для него языке.
CC>И для чего именно этот язык он собирался применять?

Ты вообще призентацию читал? Вообще забавный у нас разговор получается. Такое ощущение, что ты так и не вникнул в суть призентации.

CC>А как я понял так этот новый язык и не рассматривался как основной а скорее как замена той части, что написана у Свини на скриптовом. Те самые 10% Simulation.

Из чего ты это вывел?

До страницы "What are the hard problems?" там идет описание того, что есть. Далее поднимается вопрос о том, что нехватает и в конце начинются мечты о том, что хотелось бы иметь. Про переписывание там ни слова. Вот на стадии обсуждения проблем появляются примеры на C# и сразу же указывается, на то что хотя контроль за выходом индексов за еределы массвы есть, но он осуществляется в рантайме, а им бы хотелось в компайлтайме.

CC>Допускаю что мог ошибиться. В таком случае прошу указать из чего в статье можно судить о планах глобального применения этого языка.

В статье вообще нет планов уазывающих на конкретный язык. Там есть рассуждения о потребностях. C# оценивается там как язык покрывающий около 50% этих потребностей. Что как ты понимашь лучшем чем 0, но хуже чем 100. То есть лучше, чем было, но хуже чем нужно.

CC>Речь шла конкретно об "exceptions everywhere". Ситуации где без исключений совсем не обойтись в это не входят.

Речь шла о том, что автору хотелось бы получить контроль над исключениями. Я как бы согласен с тем, что чем больше можно статически описать, тем лучше. Но его надежд на то, что можно все привести к компайлатайм-проверкам я не разделяю. Так что исключения прийдется терпеть в самых супер современных системах. А его рассуждения на эту тему скорее всего так и останутся незбыточными мечтами. Ссылки на Хаскель несколько натянуты, так как в Хаскеле приципиально не работают с массивами.

Вот что пишет автор:

All dereference and array accesses must be statically
verifyable, rather than causing sequenced exceptions

Но это низбыточная мечта. Если отследить null-ссылки еще можно, то статически контролировать доступ к индексам массива по-моему не реально. Зато эту проблему можно обойти введением грамотных абстракций разного рода проверок.

Например, макросами Нэмерла можно обеспечить ту самую проверку корректности индексов в компайлтайме если описывать ограничения в виде атрибутов. К сожалению, если данные прийдется создавать динамически, то и контролировать их прйдется тоже динамически. Но если они задаются статически, то на макросах вполне можно реализовать их статический контроль.

Немерл позволяет банально создать специальный тип-контенер и статически отследить чтобы значения помещаемые в этот контейнер были в пределах некоторого диапазона.

CC>Короче твоя моя не поняла...

Мне кажется, что в первую очередь ты не понял о чем говорит автор. Ты вообще знаком с Хаскелем и фнуциональным подходом? Ведь именно на него налегает автор.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

WH>Реально. Например так...

Не реально, так как в общем случае данные могут появляться динамически и прийдется их контролировать в рантайме. При этом прийдетя вводить нечто воде небезопасных приведений типов.

А вообще, тот же Нэмерел позволяет создать статический конроль подобный описанному тобой, но вот только работать он будет до тех пор пока все данные появляются на этапе компиляции. Думаю, ты понимашь, что это не всегда вожможно.

В обещем, решение подобной проблемы я вижу себе так. Нужно создать контейнер который как это не печально, будет динамически проверять диапазон хранимых значений. Это убдет тип в котором заранее задан этот самый диапазон. Далее не составит труда написать макрсоы статически выводящие помещаемые значени и заменяющий в таких случаях методы с динамическим контролем, на методы со статическим контролем (для скорости).

Это не 100%-ое решение, но оно позволит значительно повысить надежность приложения.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Cyberax, Вы писали:

C>JIT уже давно существует внутри x86-процессоров.
Вот уже и JIT в процессоре который постоянно что то JIT'ит. А ведь это все можно вынести из процессора. Зачем нужно что-то постоянно вычислять если это можно вычислить один раз?

C>Точно так думали создатели Itanium'а — подсказать чем все закончилось?
Итаниу провалился по тому что есть огромная куча x86'ого софта который использует всякие низкоуровнивые хаки и прочие гадости... Да да именно такие люди как ты (убежденные в том что натив необходим везде) провалили Итаниум.
А вот еслибы все было в управляемом коде то после портирования ОС (микроядра и компилятора байткода в машинные коды) Итаниум бы начали раскупать только шум бы стоял ибо весь софт на нем продолжал бы работать как ни в чем не бывало.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Ну PS3 и Xbox2 переводит Cell'ы в ранг реальных продуктов.

В Xbox 360 (его ты под XBox 2 имел ввиду?) не Cell.

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

WolfHound wrote:
> C>JIT уже давно существует внутри x86-процессоров.
> Вот уже и JIT в процессоре который постоянно что то JIT'ит. А ведь это
> все можно вынести из процессора. Зачем нужно что-то постоянно вычислять
> если это можно вычислить один раз?
Эта проблема легко решается сменой архитектуры и компиляторов. В текущей
x86 никакой JIT все равно во внутреннее представление процессора
компилировать не может. А если менять архитекутуру — то нет смысла
повторять идиотства x86.

> C>Точно так думали создатели Itanium'а — подсказать чем все закончилось?
> Итаниу провалился по тому что есть огромная куча x86'ого софта который
> использует всякие низкоуровнивые хаки и прочие гадости... Да да именно
> такие люди как ты (убежденные в том что натив необходим везде) провалили
> Итаниум.
Нет. Итаниум провалили компиляторы — даже сам Intel не смог в итоге
сделать приемлимый компилятор. Ну и сложность процессора зашкаливала.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

WH> А ведь это все можно вынести из процессора.

У Transmeta с этим что-то не срослось

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

WolfHound wrote:
> C>Это не означает работу без GC и полноценное ручное управление памятью.
> C>Это всего лишь означает неиспользование GC.
> Те убирания кода ГЦ из процессе не означает не использование ГЦ? Очень
> интересно.
Работа без GC — это ручная работа с памятью и возможность ее
динамического распределения. А тут я вижу только работу без GC (и без
ручного управления).

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Сам подумай: что будет с OS без защиты памяти, если я сделаю ручной
> delete для объкта, затру это место другими данными, а потом попробую
> обратиться по висячему указателю?
> Да ничего не будет. Просто по тому что ОС тебе не даст удалять память. В
> место этого тебе придется сделать менеджер памяти самому что-то типа
Называется pooled allocator и подходит даааалеко не всегда. И создавать
по пулу (который еще и нельзя сокращать) на каждый _тип_ объектов — это
уже извращение.

> Вот именно. Она не использует такую мегакрутую и быструю аппаратную
> защиту... А ты предлагаешь еще навернуть защиту чтобы она работала еще
> меодленней. Ведь ничего в это мире бесплатно не бывает.
Кто сказал "медленнее"??? Оно медленно работает из-за архитектуры x86 —
ничто не мешает сделать систему (они уже есть!), где переключение
контекста намного более быстрая операция. И все преимущества Singularity
для таких архитектур сойдут на "нет".

> C>Нам нужен lookup не в одной, а в двух таблицах (по источнику и цели).
> C>Таблицы тоже можно сделать достаточно простыми.
> О уже две таблици... Короче огоромное колличество логики в ядре.
Можно и одной обойтись, но переключать ее вместе с контекстом (так
сейчас с MMT делается).

> Корость это не проблема. Ни с теоритической ни с практической точки
> зрения (см сингулярити).
В Сингулярити _нет_ фундаментально новых мест оптимизации кроме дешового
переключения контекста. И мои вычислительные алгоритмы ускорить оно не
сможет. А вот из-за запрещения ассемблера — потери скорости будут
значительны.

> C>Потому что _нельзя_ проверить все без драконовских ограничений.
> Да какая разница где эти ограничения будут в железе или в софте?
Железо, в отличие от софта позволяет организовать аппаратные кольца
защиты вокруг недоверяемого софта. При этом _не_ требуется драконовских
проверок.

> C>Это я про портабельность. Этот аспект портабельности известен давно,
> что не помешало MS наступить на грабли. А что будет с новыми
> ncNUMA-системами? А какое это отношение имеет к управляемым ОС?
Я к тому, что придумать IL-код для работы сразу на всех будущих
архитектурах — не получится.

> C>Нет, это к чему приводит пресловутая устойчивость (вот в С++ у нас бы
> уже все давно упало, а тут жмем "Ignore exception" и работаем дальше!).
> А вот я не уверен что все бы упало! Я практика показывает что довольно
> часто не падает...
С хорошим стилем — падает.

> Ну блин... самже все написал...
Ну да, а что у нас пользователи жмут в ответ на непонятное окно? И
вспомнят ли они потом о нем вообще?

Posted via RSDN NNTP Server 2.0

AndrewVK wrote:
> C>Ну PS3 и Xbox2 переводит Cell'ы в ранг реальных продуктов.
> В Xbox 360 (его ты под XBox 2 имел ввиду?) не Cell.
Да, проглючил. В XBox 360 просто 3 процессора в SMP.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Называется pooled allocator и подходит даааалеко не всегда. И создавать по пулу (который еще и нельзя сокращать) на каждый _тип_ объектов — это уже извращение.
Извращение или не извращение не суть важно. Важно только то что можно.
К томуже ты так и не сказал зачем тебе все это надо?

C>Кто сказал "медленнее"??? Оно медленно работает из-за архитектуры x86 — ничто не мешает сделать систему (они уже есть!), где переключение контекста намного более быстрая операция. И все преимущества Singularity для таких архитектур сойдут на "нет".
А эти системы производят тотальный контроль работы с памятью?

C>Можно и одной обойтись, но переключать ее вместе с контекстом (так сейчас с MMT делается).
В любом случае я не вижу причин реализовывать в железе то что прекрасно работает без железа.

C>В Сингулярити _нет_ фундаментально новых мест оптимизации кроме дешового переключения контекста. И мои вычислительные алгоритмы ускорить оно не сможет. А вот из-за запрещения ассемблера — потери скорости будут значительны.
Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
Я конечно не знаю на сколько ты хорошо пишешь на асме но у меня почемуто тоже чувство относительно тебя.
Такчто причин существенного падения производительности я не вижу.

C>Железо, в отличие от софта позволяет организовать аппаратные кольца защиты вокруг недоверяемого софта. При этом _не_ требуется драконовских проверок.
Каких таких драконовских проверок?

C>Я к тому, что придумать IL-код для работы сразу на всех будущих архитектурах — не получится.
А чем ncNUMA отличается от cell?

C>С хорошим стилем — падает.
Вот только у подавляющего большенства с хорошем стилем проблемы...

C>Ну да, а что у нас пользователи жмут в ответ на непонятное окно? И вспомнят ли они потом о нем вообще?
А логи вам на что?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Эта проблема легко решается сменой архитектуры и компиляторов. В текущей x86 никакой JIT все равно во внутреннее представление процессора компилировать не может. А если менять архитекутуру — то нет смысла повторять идиотства x86.
Во-во зачем повторять все эти идиотства если можно сделать управляемую ОС расчитаную на слабую модель памяти и сделать под нее простой как три копейки процессор который только и може что считать да из виртуальной памяти в кешь SPU и обратно копировать.
К томуже если ВМ расчитана на слабую модель памяти то запустить ее на томже x86 проблем не составит.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Называется pooled allocator и подходит даааалеко не всегда. И
> создавать по пулу (который еще и нельзя сокращать) на каждый _тип_
> объектов — это уже извращение.
> Извращение или не извращение не суть важно. Важно только то что можно.
> К томуже ты так и не сказал зачем тебе все это надо?
Я к тому, что pooled allocator применим только в очень небольшом числе
случаев и не пригоден для общего случая.

> А эти системы производят тотальный контроль работы с памятью?
На такой как сейчас в x86.

> В любом случае я не вижу причин реализовывать в железе то что прекрасно
> работает без железа.
Блин! Ну _НЕ_ работает оно.

> Например есть такой компилятор называется Intel C++... я уверен что не
> смогу написать на ассемблере код который будет лучше чем генерирует этот
> компилятор.
А вот я уверен в обратном. Более того, я уже именно это и сделал.
Ускорение в 20% в одном из важнейших циклов (вейвлет-преобразование
профиля поверхности) по сравнению с IC++ в режиме WPO. Динамическое
профилирование почему-то дало результат на этом коде медленнее WPO.

> Каких таких драконовских проверок?
Точнее драконовских ограничений.

> C>Я к тому, что придумать IL-код для работы сразу на всех будущих
> архитектурах — не получится.
> А чем ncNUMA отличается от cell?
Cell — это только частный случай ncNUMA. Их достаточно много видов есть.

> C>С хорошим стилем — падает.
> Вот только у подавляющего большенства с хорошем стилем проблемы...
А я говорю про большинство? Мне плевать, пусть хоть на VB пишут. Другое
дело, что managed OS будут лишать меня возможности нормально
писать на С++.

> C>Ну да, а что у нас пользователи жмут в ответ на непонятное окно? И
> вспомнят ли они потом о нем вообще?
> А логи вам на что?
Чего? Каждого действия?

Posted via RSDN NNTP Server 2.0

C>Да, проглючил. В XBox 360 просто 3 процессора в SMP.

Кстати, GPU там — монстр:

The Xbox 360 GPU is a custom 500 MHz graphics processor from ATI. The shader core has 48 Arithmetic Logic Units (ALUs) that can execute 64 simultaneous threads on groups of 64 vertices or pixels. ALUs are automatically and dynamically assigned to either pixel or vertex processing depending on load. The ALUs can each perform one vector and one scalar operation per clock cycle, for a total of 96 shader operations per clock cycle. Texture loads can be done in parallel to ALU operations. At peak performance, the GPU can issue 48 billion shader operations per second.

Здравствуйте, Cyberax, Вы писали:

C>И все они x86. За исключением Itanium, который все равно не сильно
C>отличается.

Shure?

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

Здравствуйте, Cyberax, Вы писали:

C>В С# сейчас сильная модель памяти, так что Double-Lock Checking
C>работает.

Double check locking ты хотел сказать? Так с управляемыми средами здесь даже проще — JIT может такой паттерн распознавать и генерить потокобезопасный для целевой архитектуры код.

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

Здравствуйте, Дарней, Вы писали:

Д>если он сейчас и работает, то это просто случайность. Документация настоятельно рекомендует не использовать DCLP.

И что предлагают взамен?

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

AndrewVK wrote:
> Double check locking ты хотел сказать? Так с управляемыми средами здесь
> даже проще — JIT может такой паттерн распознавать и генерить
> потокобезопасный для целевой архитектуры код.
К сожалению, это только один из примеров неправильной работы.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

>> Double check locking ты хотел сказать? Так с управляемыми средами здесь
>> даже проще — JIT может такой паттерн распознавать и генерить
>> потокобезопасный для целевой архитектуры код.
C>К сожалению, это только один из примеров неправильной работы.

Слив засчитан.

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

Здравствуйте, McSeem2, Вы писали:

MS>Кстати, GPU там — монстр:
MS>

...

Че-то на Radeon X1900 смахивает случаем не он?

... << RSDN@Home 1.2.0 alpha rev. 642>>

Здравствуйте, Cyberax, Вы писали:

>> В любом случае я не вижу причин реализовывать в железе то что прекрасно работает без железа.
C>Блин! Ну _НЕ_ работает оно.
А сингулярити мне прислась? И .NET с жабой тоже не работают?

C>А вот я уверен в обратном. Более того, я уже именно это и сделал.
C>Ускорение в 20% в одном из важнейших циклов (вейвлет-преобразование профиля поверхности) по сравнению с IC++ в режиме WPO. Динамическое профилирование почему-то дало результат на этом коде медленнее WPO.
Те интеловский компилятор в некоторых случаях генерирует код на 20% медленней идеала.
С виду гиганское преймущество.
Но с другой стороны
1)В подавляющем большинстве задач это ничто. К томуже скорей всего в подавляющем числе задач он сгенерирует идеальный код.
2)Оптимизаторы постоянно умнеют, а мы говорим о будущем.
3)Выкидывание всякой дури из процессора позволит поднять его производительность. И возможно больше чем на эти самые 20%

C>Точнее драконовских ограничений.
Каких?
Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо. То есть вобще никаких причин не вижу.
Присутствие ГЦ? Тоже честно говоря не понял чем оно тебя не устраивает. Ну да есть некоторый оверхед по памяти. Ну и что? Память сейчас дешовая. И будет еще дешевле(уж точно не дороже ибо несчего). Проблемы с памятью есть только в кристаллах но я и не предлагаю туда засовывать управляемые ОС.
Отсутствие возможности писать на асме? В одном из 1000 (а может и еще реже) случаев мы потеряем 20% производительности. А стоит ли оно того чтобы отказыватся от управляемых ОС? Я считаю что нет.

>> А чем ncNUMA отличается от cell?
C>Cell — это только частный случай ncNUMA. Их достаточно много видов есть.
Дык эта дай ссылочку. А то гугль выдает какието ссылки на немецкие сайты, а я по немецки не понимаю.

C>А я говорю про большинство? Мне плевать, пусть хоть на VB пишут. Другое дело, что managed OS будут лишать меня возможности нормально писать на С++.
Я так и не понял зачем тебе писать на С++ если он всеравно на 20% медленней асма, а сравнивать производительность С++ и скажем C# не корректно ибо можно сравнивать только компиляторы.

>> А логи вам на что?
C>Чего? Каждого действия?
Каждого исключения. Тем болие что это исключение было показано пользователю.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

CC>>Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??
WH>Уж не намекаешь ли ты на то что у меня руки из ж растут? Ты конечно можешь считать как угодно но например brainbench считает что я знаю С++ лучше чем 99.9% проходивших этот тест...

WH>Хватит называть меня криворуким. Надоело уже

Так. Теперь все понятно. Ты просто ответы видимо читаешь через строку или вообще по диагонали...
Было написано следующее:

WH>Например у меня на машине "Vampire Masquerade — Bloodlines" просто падает при старте, а на другой работала... Причем винда свеже поставленная.
CC>А в чем тут вина неуправляемых языков? Попав молотком по пальцу ты ж молоток не винишь. Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??

Не знаю как для тебя, но для меня очевидно, что речь идет о криворуких разработчиках "Vampire Masquerade — Bloodlines", которая у тебя собственно и падает. Откуда ты выискал личный наезд непонятно, но сразу съехал на эмоции и начал тыкать брейнбенчем...

WH>Учитывая что определенный класс ошибок там просто не возможен то...
CC>... криворукость прощать не стоит а потворствовать вообще нельзя... Но согласись, если какой то человек не способен писать на языке без ошибок а другие совершают эти ошибки на порядок меньше на том же языке то это не значит что язык плохой.
Опять непонятно с какого перепугу ты решил что речь о тебе? Где тут такое написано? Речь то шла о том, что если абстрактный программер пупкин совершает в языке Z какую то ошибку снова и снова то это означает что надо менять пупкина а не язык.

CC>>Вообще то если подумать, то оба языка выполняют машинный код на одном и том же процессоре. хъ
WH>Во-во, а вы все скорость, скорость...

Ты б хоть до конца прочитал, что ли...

WH>Но обижатся я не стану. Я выше этого.

Пардон, но смысла продолжать диалог я не вижу... Мы с тобой никогда правильно друг друга не поймем, поэтому лучше прекратить флуд пока до личностей дело не дошло...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Че-то на Radeon X1900 смахивает случаем не он?

Не он. Но у GPU XBox 360 и линейки Х1000 общие корни.

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

Здравствуйте, AndrewVK, Вы писали:

Д>>если он сейчас и работает, то это просто случайность. Документация настоятельно рекомендует не использовать DCLP.

AVK>И что предлагают взамен?

простой и бесхитростный lock

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, WolfHound, Вы писали:

WH>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
А я смогу. Более того, неоднократно писал.

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cyberax, Вы писали:

>> В любом случае я не вижу причин реализовывать в железе то что прекрасно работает без железа.
C>Блин! Ну _НЕ_ работает оно.
Кстати как будут выглядеть таблици аппартоной защиты памяти для кода типа

template<class T>
struct G
{
    T v1;
    T arr[10];
    T v2;
};
int main()
{
    G<G<G<G<G<int> > > > > ggg;
}

Ы? Нужно защитить каждый массив причем это должно быть сделано типизированно.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vvotan, Вы писали:

WH>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>А я смогу. Более того, неоднократно писал.
И на сколько процентов? И стоят ли эти проценты уменьшения надежности все системы?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Блин! Ну _НЕ_ работает оно.
> Кстати как будут выглядеть таблици аппартоной защиты памяти для кода типа
> template<class T>
> struct G
> {
> T v1;
> T arr[10];
> T v2;
> };
> int main()
> {
> G<G<G<G<G<int> > > > > ggg;
> }
> Ы? Нужно защитить каждый массив причем это должно быть сделано
> типизированно.
Вы не понимаете — защищаются _сами_ указатели. То есть перезапись
указателя — это привиллегированая операция. Исход операции (успех или
trap) зависит от комбинации IP (Instruction Pointer) источника и
результата назначения.

То есть этот массив будет (скорее всего) расположен в памяти приложения,
и к нему будет иметь доступ только сам код приложения.

Posted via RSDN NNTP Server 2.0

Здравствуйте, vvotan, Вы писали:

V>Здравствуйте, WolfHound, Вы писали:

WH>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>А я смогу. Более того, неоднократно писал.

Дарней, не понял за что минус. Не веришь?

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

WH>>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>>А я смогу. Более того, неоднократно писал.
WH>И на сколько процентов? И стоят ли эти проценты уменьшения надежности все системы?
Боюсь наврать, так как последний раз занимался этим около года назад, но точно более чем вдвое.
Сразу скажу: задача — обработка изображения; основной выигрыш получился из-за: нормального использования SIMD, избавления от делений, замены условных переходов арифметикой во внутреннем цикле.
Насчет надежности — это была всего-лишь функция, принимающая массив байт на входе и записывающая выход в предварительно подсунутую память. Все размеры оговорены, падать чисто вычислительному коду не свойственно. Если оно что-то сделает не так — да и фиг с ним — будет у пользователя некрасивая картинка.
Я же не предлагаю все подряд на ассемблере писать

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cyberax, Вы писали:

C>То есть этот массив будет (скорее всего) расположен в памяти приложения, и к нему будет иметь доступ только сам код приложения.
Это ты не понимаешь. Нужно защищать именно от кода приложения. Те

template<class T>
struct G
{
    T v1;
    T arr[10];
    T v2;
};
template<class T>
void Crush(G<T>& g)
{
    for(int i = 0; i < 100; ++i)
        Crush(g.arr[i]);
}
void Crush(int& i)
{
    i = 0;
}
int main()
{
    G<G<G<G<G<int> > > > > ggg;
}

Такой код не должен разрушить никакие данные. Любой выход за приделы массива должен приводить к исключению.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> Такой код не должен разрушить никакие данные. Любой выход за приделы
> массива должен приводить к исключению.
Можно использовать "fat pointers" — то есть в указатель записывается еще
и длина адресуемого блока (так было и на AS/400).

Но это обычно никому не нужно, главное дать гарантию, что код
теоретически не сможет вырваться из своего sandbox'а. А для этого tagged
pointer'ов вполне хватает.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Можно использовать "fat pointers" — то есть в указатель записывается еще и длина адресуемого блока (так было и на AS/400).
Те указатели в общем случае должны быть в два раза больше? В любом случае это не спасет от смещения указателя на пол размера структуры. Те нам понадобится еще и размер структуры. Те указатель должен быть в 3 раза больше... плюс куча транзисторов для проверки.

C>Но это обычно никому не нужно, главное дать гарантию, что код теоретически не сможет вырваться из своего sandbox'а. А для этого tagged pointer'ов вполне хватает.

это нужно всем. Это надежность программы.
Короче я так и не понял зачем нужны все эти сложности на низком уровне если анализ проведенный на высоком уровне позволяет этого избежать?

Итого: Так и небыло предоставлено ни одного аргумента в пользу того что аппаратная защита памяти лучше программной. Наоборот было выявлена куча сложностей, а если делать по простому то у нас будут дыры в защите мелких объектов. К томуже всеравно кто-то должен формировать таблици.
Единственный аргумент в пользу нативного кода это возможность в некоторых случаях написать на ассмблере болие быстрый код. Но это тут есть три фактора
1)В подавляющем большинстве случаев компилятор генерирует оптимальный код.
2)Упрощение процессоров позволит поднять производительность процессоров.
3)Работы по совершенствованию оптимизаторов постоянно ведутся.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vvotan, Вы писали:

V>Сразу скажу: задача — обработка изображения; основной выигрыш получился из-за: нормального использования SIMD, избавления от делений, замены условных переходов арифметикой во внутреннем цикле.
Те алгоритмическими оптимизациями... классный способ опустить компилятор.
V>Насчет надежности — это была всего-лишь функция, принимающая массив байт на входе и записывающая выход в предварительно подсунутую память. Все размеры оговорены, падать чисто вычислительному коду не свойственно. Если оно что-то сделает не так — да и фиг с ним — будет у пользователя некрасивая картинка.
Пользователь будет не доволен... Пользователь платит деньги...
V>Я же не предлагаю все подряд на ассемблере писать

Ты нет, а вот Cyberax жить без С++ не может... А С++ не могим лучше ассемблера в плане надежности и статических проверок.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cyberax, Вы писали:

C>>Это не означает работу без GC и полноценное ручное управление памятью.
C>>Это всего лишь означает неиспользование GC.
WH>Те убирания кода ГЦ из процессе не означает не использование ГЦ? Очень интересно.

памятью все-равно нельзя управлять, можно будет лишь использовать "статические" массивы или стек.

Здравствуйте, vdimas, Вы писали:

V>памятью все-равно нельзя управлять, можно будет лишь использовать "статические" массивы или стек.
Для драйверов какихнибудь несложных девайсов этого может быть вполне достаточно. К томуже в сингулярити есть еще exchange heap на счетчиках ссылок... правда там есть ограничения на типы данных размещаемые в этой куче.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vdimas, Вы писали:

V>памятью все-равно нельзя управлять, можно будет лишь использовать "статические" массивы или стек.
Кстати... ведь в сингулярити можно реализовывать какие угодно мусорщики... в том числе считающие ссылки... правда опять придется смотреть чтобы ничего не зациклелось но чем это хуже того что есть в С++?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> V>памятью все-равно нельзя управлять, можно будет лишь использовать
> "статические" массивы или стек.
> Кстати... ведь в сингулярити можно реализовывать какие угодно
> мусорщики... в том числе считающие ссылки... правда опять придется
> смотреть чтобы ничего не зациклелось но чем это хуже того что есть в С++?
Вы вообще, С++ знаете?

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Вы вообще, С++ знаете?
Не хуже тебя.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
>> > В любом случае я не вижу причин реализовывать в железе то что
> прекрасно работает без железа.
> C>Блин! Ну _НЕ_ работает оно.
> А сингулярити мне прислась? И .NET с жабой тоже не работают?
Приснилась. Так как в понятие "работает" включает возможность
использования полноценного С++ с максимально близким доступом к железу.

> Те интеловский компилятор в некоторых случаях генерирует код на 20%
> медленней идеала.
Уже на 25% — сегодня еще ускорил свой код.

> 1)В подавляющем большинстве задач это ничто. К томуже скорей всего в
> подавляющем числе задач он сгенерирует идеальный код.
Еще раз: мне _плевать_ на подавляющее большинство задач. Мне
важны мои приложения.

> 2)Оптимизаторы постоянно умнеют, а мы говорим о будущем.
Ага, и постоянно находится ручной код, который работает быстрее
скомпилированного

> 3)Выкидывание всякой дури из процессора позволит поднять его
> производительность. И возможно больше чем на эти самые 20%
И что? Мой код все равно будет на 20% быстрее работать.

> C>Точнее драконовских ограничений.
> Каких?
> Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо.
Я понимаю.

> То есть вобще никаких причин не вижу.
Я вижу.

> Присутствие ГЦ?
_Обязательное_ присутствие ГЦ (или никакой динамической памяти).

> Тоже честно говоря не понял чем оно тебя не устраивает.
> Ну да есть некоторый оверхед по памяти. Ну и что? Память сейчас дешовая.
Не привык я зря выкидывать деньги.

> Отсутствие возможности писать на асме? В одном из 1000 (а может и еще
> реже) случаев мы потеряем 20% производительности. А стоит ли оно того
> чтобы отказыватся от управляемых ОС? Я считаю что нет.
Стоит. Один только этот факт стоит.

>> > А чем ncNUMA отличается от cell?
> C>Cell — это только частный случай ncNUMA. Их достаточно много видов есть.
> Дык эта дай ссылочку. А то гугль выдает какието ссылки на немецкие
> сайты, а я по немецки не понимаю.
Вот хотя бы: http://www.cs.rochester.edu/research/cashmere/

> Я так и не понял зачем тебе писать на С++ если он всеравно на 20%
> медленней асма, а сравнивать производительность С++ и скажем C# не
> корректно ибо можно сравнивать только компиляторы.
В С++ я могу когда мне это нужно (во внутренних циклах CPU-intensive
преобразований) опуститься на уровень железа.

>> > А логи вам на что?
> C>Чего? Каждого действия?
> Каждого исключения. Тем болие что это исключение было показано пользователю.
Потом добавили такую функцию.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

V>>Сразу скажу: задача — обработка изображения; основной выигрыш получился из-за: нормального использования SIMD, избавления от делений, замены условных переходов арифметикой во внутреннем цикле.
WH>Те алгоритмическими оптимизациями... классный способ опустить компилятор.
Во-первых, я никого не хочу опускать. Во-вторых, на языке С++ реализовать то, что сделал я достаточно сложно и думаю получившийся код не намного уйдет от ассемблера. В частности замена умножением деления на константу(но неизвестную при компиляции), причем по нескольку штук сразу в SIMD-регистрах.
Насчет арифметики — вот тут уж имхо компилятору все карты в руки. Однако "не шмогла я, не шмогла" Только заменой внутреннего цикла, куда это чудо запихало условный переход, на ассемблерную вставку с cmov, мне удалось без всяких SIMD поднять производительность на ~30%.
Если поиграть с растактовкой, наверное еще можно было бы выиграть пару процентов, но это уже точно никому не надо.
V>>Насчет надежности — это была всего-лишь функция, принимающая массив байт на входе и записывающая выход в предварительно подсунутую память. Все размеры оговорены, падать чисто вычислительному коду не свойственно. Если оно что-то сделает не так — да и фиг с ним — будет у пользователя некрасивая картинка.
WH>Пользователь будет не доволен... Пользователь платит деньги...
Если оно будет работать втрое дольше, пользователь его сразу выключит, как бы надежно оно не было.

V>>Я же не предлагаю все подряд на ассемблере писать

WH>Ты нет, а вот Cyberax жить без С++ не может... А С++ не могим лучше ассемблера в плане надежности и статических проверок.
Не хочется отвечать за другого человека, но AFAIK Cyberax и Jav'ой занимается.
В том, что тезис "всё на .NET" мягко говоря несвоевременен, я с ним солидарен. Так же как в большинстве случаев на С++ не стоит писать cgi-скрипты, так и слишком "безопасные" и "высокоуровневые" языки непригодны во многих областях. По крайней мере, в настоящее время

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

WolfHound wrote:
> C>Вы вообще, С++ знаете?
> Не хуже тебя.
Тогда должны знать:
1. Что refcount слишком дорог.
2. Есть _быстрые_ автоматические объекты, которые refcount просто погубит.
3. Есть схемы управления, которые не выражаются простым refcount'ом.

Posted via RSDN NNTP Server 2.0

Cyberax wrote:
> 1. Что refcount слишком дорог.
Поправка: "Что refcount слишком дорог для использования для _всех_
объектов".

Posted via RSDN NNTP Server 2.0

vvotan wrote:
> WH>Ты нет, а вот Cyberax жить без С++ не может... А С++ не могим лучше
> ассемблера в плане надежности и статических проверок.
> Не хочется отвечать за другого человека, но AFAIK Cyberax и Jav'ой
> занимается.
И как ни странно, мне Java очень нравится для написания Web-приложений.
Tapestry+Hibernate — рулят

Еще я использую Python (замечательный язык!) для скриптов через
Boost.Python.

Я не против остальных языков — мне не нравится, когда меня заставляют
писать на каком-то одном языке (соответствующем The Only Right Way (tm) ).

> В том, что тезис "всё на .NET" мягко говоря несвоевременен, я с ним
> солидарен. Так же как в большинстве случаев на С++ не стоит писать
> cgi-скрипты, так и слишком "безопасные" и "высокоуровневые" языки
> непригодны во многих областях. По крайней мере, в настоящее время
Именно.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Поправка: "Что refcount слишком дорог для использования для _всех_ объектов".
Про value типы слышал?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Поправка: "Что refcount слишком дорог для использования для _всех_
> объектов".
> Про value типы слышал?
Про ограничения value-типов слышал?

Posted via RSDN NNTP Server 2.0

Здравствуйте, VladD2, Вы писали:

VD>В обещем, решение подобной проблемы я вижу себе так. Нужно создать контейнер который как это не печально, будет динамически проверять диапазон хранимых значений. Это убдет тип в котором заранее задан этот самый диапазон. Далее не составит труда написать макрсоы статически выводящие помещаемые значени и заменяющий в таких случаях методы с динамическим контролем, на методы со статическим контролем (для скорости).

А зачем изобретать велосипеды?
В том же Паскаль и С++ размерность и пределы массива могут являться частью типа. В CORBA тоже так.

Более того. Можно было бы выставить массив не reference-типом, а ValueType. Со строками тоже самое.
Дело в том, что семантика null на строках и массивах — это какой-то идеологический курьез. Эта семантика приносит лишь проблемы и ни одного бенефита.

Надо было сделать что-то типа такого:

public struct ProxyBase<T> {
    internal protected T _value;
}

public struct String : ProxyBase<StringInternal> {

    public int Length { return _value.Length; }
    ...
}

public struct Array: ProxyBase<ArrayInternal> {

    public int Length { return _value.Length; }
    ...
}

И в конструкторе по-умолчанию рантайм должен инициализировать внутреннее _value ссылкой на String.Empty или какой-нить Array<type>.Empty.

Здравствуйте, Cyberax, Вы писали:

C>Приснилась. Так как в понятие "работает" включает возможность использования полноценного С++ с максимально близким доступом к железу.

C>И что? Мой код все равно будет на 20% быстрее работать.
Не будет. Ибо на том процессоре не будет аппаратной защиты памяти. Следовательно твой код запускать на нем полное безумие. И ничкто этого не сделает.
К томуже скорей всего там будет совсем другая система комманд.

>> Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо.
C>Я понимаю.
Объясни.

>> Присутствие ГЦ?
C>_Обязательное_ присутствие ГЦ (или никакой динамической памяти).
Ну ГЦ можно заменить на счетчик ссылок. Плюс value типы...
К томуже лично мне ГЦ никак не мешает делать алгоритмы которые очень интенсивно работают с памятью. Тут просто надо знать где использовать reference типы, а где value.

C>Не привык я зря выкидывать деньги.
Ты на отладке больше потеряешь.

C>Вот хотя бы: http://www.cs.rochester.edu/research/cashmere/
Таки NCC-NUMA.
Итого в общем случае это куча процессоров у каждого есть своя память. Причем передача данных между процессорами очень медленная.
Такие архитектуры рулят для задач которые можно распаралелить по данным.
Никаких недостатков у управляемых сред при разработке под такие системы я не вижу. На оборот потимизатору в управляемой среде доступно больше информации и он с большой вероятностью сможет распаралелить многое сам.
Однако я не исключаю что ему нужно будет както помогать. Опять таки я в управляемых средах будет как минимум не сложнее это сделать.

C>В С++ я могу когда мне это нужно (во внутренних циклах CPU-intensive преобразований) опуститься на уровень железа.
В конце концов сингулярити вполне себе использует небезопасный код в ядре. Но только в этой системе просто запрещен пользовательский небезопасный код. Даже в драйверах. В принципе можно сделать систему которая при наличии достаточных прав у пользователя таки загрузит небезопасный код. Вот только я смысла в этом не вижу.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

>> Про value типы слышал?
C>Про ограничения value-типов слышал?
А какие именно ограничения тебе так не нравятся?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vdimas, Вы писали:

V>И в конструкторе по-умолчанию рантайм должен инициализировать внутреннее _value ссылкой на String.Empty или какой-нить Array<type>.Empty.
Тоже вариант. И как ты понимаешь вполне реализуемый в отличных от .NET управляемых средах.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>И как ни странно, мне Java очень нравится для написания Web-приложений.
C>Tapestry+Hibernate — рулят

С указанными технологиями не знаком, но как язык меня Java раздражает. Уж лучше С#, который с каждой версией мне нравится все больше.
Хотя вполне допускаю что это из-за поверхностного знакомства.

C>Еще я использую Python (замечательный язык!) для скриптов через
C>Boost.Python.
Мне в последнее время больше нравится Ruby. В питоне эта маразматичная идея форматирования кода пробелами меня что-то не цепляет. Только вот жалко аналога boost::python для Ruby нет.

C>Я не против остальных языков — мне не нравится, когда меня заставляют
C>писать на каком-то одном языке (соответствующем The Only Right Way (tm) ).
+1

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

V>А зачем изобретать велосипеды?

Что бы не ездить на неудобных.

V>В том же Паскаль и С++ размерность и пределы массива могут являться частью типа. В CORBA тоже так.

Ты поглядел бы пример. Речь идет о том, что индексы массива могут сами по себе лежать в другом массиве. Причем исходный массив может иметь размер задаваемый в рантайме. Задать типами такое не удастся, так как тип не сможет отследить динамическое изменение размеров массива.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, vvotan, Вы писали:

WH>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>А я смогу. Более того, неоднократно писал.

На каком объеме? Понятно, что одну конкретную функцию в режиме тюнинга ты может и раскачегаришь. Но вот если ты попробушь написать все приложение на асме, то вряд ли сможешь опередить хороший компилятор. Ты или просто не справишся с работой в заданные сроки, или порадишь куда более плохой код. А скорее всего и то, и другое.

Здесь же именно о таком случае говорили видимо.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Cyberax, Вы писали:

C>Вы вообще, С++ знаете?

Это очень смешно, но предупреждаю, что следующий кто будет заниматься исследованиями в области компетенции другого резко пойдет в баню на недел.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

C>>Вы вообще, С++ знаете?
WH>Не хуже тебя.

Вот мужик. Поседи в нашей шкурке. И это только начало.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Cyberax, Вы писали:

C>Тогда должны знать:
C>1. Что refcount слишком дорог.

Тут кто-то недавно давал ссылку на ЖЦ основанный на подсчете ссылок. Найди ее и почитай. Узнашь много нового. Обещаю.

C>2. Есть _быстрые_ автоматические объекты, которые refcount просто погубит.
C>3. Есть схемы управления, которые не выражаются простым refcount'ом.

Об этом там тоже рассказвалось.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

C>>И что? Мой код все равно будет на 20% быстрее работать.
WH>Не будет. Ибо на том процессоре не будет аппаратной защиты памяти. Следовательно твой код запускать на нем полное безумие. И ничкто этого не сделает.
WH>К томуже скорей всего там будет совсем другая система комманд.
Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти. Все что он делает — обрабатывает один буффер, записывая результат в другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать код, работающий быстрее компилятора.

>>> Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо.
C>>Я понимаю.
WH>Объясни.
В том же коде wavelet-преобразования у меня, например, используется адресная арифметика. Или в коде тесселяции поверхности (он на С++).

>>> Присутствие ГЦ?
C>>_Обязательное_ присутствие ГЦ (или никакой динамической памяти).
WH>Ну ГЦ можно заменить на счетчик ссылок. Плюс value типы...
Не может. Во-первых, счетчик ссылок дает overhead некоторый overhead. Во-вторых, value-типы ограничены (см. другое сообщение).

C>>Не привык я зря выкидывать деньги.
WH>Ты на отладке больше потеряешь.
Нет.

C>>Вот хотя бы: http://www.cs.rochester.edu/research/cashmere/
WH>Таки NCC-NUMA.
ncNUMA тоже называют (по аналогии с ccNUMA).

WH>Итого в общем случае это куча процессоров у каждого есть своя память. Причем передача данных между процессорами очень медленная.
Не "очень медленная", а "медленнее по сравнению с локальной".

Здравствуйте, WolfHound, Вы писали:

>>> Про value типы слышал?
C>>Про ограничения value-типов слышал?
WH>А какие именно ограничения тебе так не нравятся?
А может ли value-тип реализовать мой интерфейс?

vvotan wrote:
> C>И как ни странно, мне Java очень нравится для написания Web-приложений.
> C>Tapestry+Hibernate — рулят
> С указанными технологиями не знаком, но как язык меня Java раздражает.
Мне как раз нравится, что Java — тупой как пробка язык с минимумом
сложностей. Поэтому всякую фигню типа Web-приложений на ней очень удобно
писать.

Ну и для Java есть огромное количество OpenSource-инструментов.

> C>Еще я использую Python (замечательный язык!) для скриптов через
> C>Boost.Python.
> Мне в последнее время больше нравится Ruby. В питоне эта маразматичная
> идея форматирования кода пробелами меня что-то не цепляет.
Я привык

> Только вот жалко аналога boost::python для Ruby нет.
Собственно, именно это меня и удерживает. Ну и еще в Python'е подсчет
ссылок замечательно совмещается с С++.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> На каком объеме? Понятно, что одну конкретную функцию в режиме тюнинга
> ты может и раскачегаришь. Но вот если ты попробушь написать все
> приложение на асме, то вряд ли сможешь опередить хороший компилятор.
Блин, ну никто не собирается на ассемблере писать все приложение! Он
нужен только для критичных внутренних циклов.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> C>Вы вообще, С++ знаете?
> Это очень смешно, но предупреждаю, что следующий кто будет заниматься
> исследованиями в области компетенции другого резко пойдет в баню на недел.
Это был вопрос, чтобы выяснить на каком уровне объяснять дальше.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> C>Тогда должны знать:
> C>1. Что refcount слишком дорог.
> Тут кто-то недавно давал ссылку на ЖЦ основанный на подсчете ссылок.
Этим "кто-то" был я

Дело в том, что в С++ я могу использовать такие вещи, как placement new
для коллекций value-типов (где value-коллекции в .NET?????). Поэтому
распределение памяти — достаточно редкая операция.

> C>2. Есть _быстрые_ автоматические объекты, которые refcount просто погубит.
> C>3. Есть схемы управления, которые не выражаются простым refcount'ом.
> Об этом там тоже рассказвалось.
В той доке циклические ссылки периодически собирались обычным GC.
Собственно, детектор циклов — это и есть GC.

Posted via RSDN NNTP Server 2.0

Здравствуйте, VladD2, Вы писали:

WH>>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>>А я смогу. Более того, неоднократно писал.

VD>На каком объеме?
Естественно, на минимально необходимом.

VD>Понятно, что одну конкретную функцию в режиме тюнинга ты может и раскачегаришь. Но вот если ты попробушь написать все приложение на асме, то вряд ли сможешь опередить хороший компилятор.
А нафига мне писать все приложение на асме? Ему всему предельная производительность не нужна, но фишка в том, что без предельной производительности отдельных частей, все приложение будет ненужно

VD> Ты или просто не справишся с работой в заданные сроки, или порадишь куда более плохой код.
Я застрелюсь или в крайнем случае, повешусь

VD>А скорее всего и то, и другое.
Ага, и повешусь, и застрелюсь

VD>Здесь же именно о таком случае говорили видимо.

Насколько я понял, нет. Спорили о том, что какая бы ни была среда(управляемая или не очень), должна быть возможность, когда это необходимо, опустится на уровень ниже: в некоторых случаях перейти на более производительный неуправляемый код(на С++ как наиболее адекватном для этого неуправляемом языке), а иногда и на ассемблер, несмотря на все "фи" фанатичных адептов поддерживаемости и переносимости.

--
Sergey Chadov

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cyberax, Вы писали:

WH>>А какие именно ограничения тебе так не нравятся?
C>А может ли value-тип реализовать мой интерфейс?
Может. Может ты хотябы изучишь .NET? К томуже учти что можно реализовать это все намного умнее чем это сделали мелкософты..

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Дело в том, что в С++ я могу использовать такие вещи, как placement new для коллекций value-типов (где value-коллекции в .NET?????). Поэтому распределение памяти — достаточно редкая операция.
В .NET 2 List<T> прекрасно работает с value типами.
К томуже для value типов new Type(...) это фактически placement new.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, VladD2, Вы писали:

VD>Ты поглядел бы пример. Речь идет о том, что индексы массива могут сами по себе лежать в другом массиве. Причем исходный массив может иметь размер задаваемый в рантайме. Задать типами такое не удастся, так как тип не сможет отследить динамическое изменение размеров массива.
В некоторых случаях статический анализ таки может это сделать.
Скажем в таком коде это вполне возможно

class Mesh
{
    int[] _indexes;
    Vertex[] _vertexes;
    invariant
    {
        foreach(int i in _indexes)
            if not ( i in [0, _vertexes.Length - 1])
                error;
    }
    public const int[] Indexes
    {
        get { return _indexes; }
    }
    public const Vertex[] _Vertexes
    {
        get { return _vertexes; }
    }
}

Имея информацию о инварианте Mesh'а компилятор вполне может повыкидывать кучу проверок.
Хотя над этими механизмами нужно еще очень хорошо подумать никаких принципиальных препятствий я не вижу.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти. Все что он делает — обрабатывает один буффер, записывая результат в другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать код, работающий быстрее компилятора.
Угу... пока... и не сильно...

C>В том же коде wavelet-преобразования у меня, например, используется адресная арифметика. Или в коде тесселяции поверхности (он на С++).
То что ты ее используешь это и так понятно. Вопрос в том, а оно действительно нужно?

C>Не может. Во-первых, счетчик ссылок дает overhead некоторый overhead. Во-вторых, value-типы ограничены (см. другое сообщение).
Вот только я занимался оптимизацией .NET приложений, а ты нет. Так что не надо говорить про ограничения value типов. Их возможностей для того чтобы что-то разогнать болие чем достатояно.

WH>>Таки NCC-NUMA.
C>ncNUMA тоже называют (по аналогии с ccNUMA).
Вот только гугль по ncNUMA ведет только на пару немецких сайтов...

C>Не "очень медленная", а "медленнее по сравнению с локальной".
Не суть важно. Главное что общение между процессорами нужно минимизировать.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти.
> Все что он делает — обрабатывает один буффер, записывая результат в
> другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать
> код, работающий быстрее компилятора.
> Угу... пока... и не сильно...
Разбудите когда не смогут больше....

> C>В том же коде wavelet-преобразования у меня, например, используется
> адресная арифметика. Или в коде тесселяции поверхности (он на С++).
> То что ты ее используешь это и так понятно. Вопрос в том, а оно
> действительно нужно?
В самой первой версии был красивый код тесселяции с std::vector и
контролем индексов. Работал в два раза медленнее.

> Вот только я занимался оптимизацией .NET приложений, а ты нет. Так что
> не надо говорить про ограничения value типов. Их возможностей для того
> чтобы что-то разогнать болие чем достатояно.
Чтобы "разогнать .NET" — достаточно. Чтобы заменить автоматические
объекты С++ — нет.

> WH>>Таки NCC-NUMA.
> C>ncNUMA тоже называют (по аналогии с ccNUMA).
> Вот только гугль по ncNUMA ведет только на пару немецких сайтов...
У меня так в журналах написано ("Открытые Системы").

> C>Не "очень медленная", а "медленнее по сравнению с локальной".
> Не суть важно. Главное что общение между процессорами нужно минимизировать.
Естественно. Его и в случае с SMP нужно оптимизировать — синхронизация
кэшей все равно не быстрый процесс.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>В самой первой версии был красивый код тесселяции с std::vector и контролем индексов. Работал в два раза медленнее.
Контроль индектов в С++ оптимизировать практически не реально.

C>Чтобы "разогнать .NET" — достаточно. Чтобы заменить автоматические объекты С++ — нет.
А что таково в автоматических объектах чего не могут дать value типы?

C>Естественно. Его и в случае с SMP нужно оптимизировать — синхронизация кэшей все равно не быстрый процесс.
Просто сейчас алгоритмы однопоточные и данные модифицирует только один поток. Так что ничего синхронизировать не надо.
Синхронизация понадобится если алгоритмы начнут паралелить. Но тут опять таки нужна высокоуровневая оптимизация.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Это был вопрос, чтобы выяснить на каком уровне объяснять дальше.

Этот вопрос выглядел очень некрасиво. Ты бы для разнобразия в топ С++ поглядел бы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, WolfHound, Вы писали:

WH>В некоторых случаях статический анализ таки может это сделать.

Ключевое слово здеть "В некоторых случаях". Еще раз. Общего решения тут быть не может.
Первые динамические данные и ты приехал. А зачем данные в массивы пихать если они не динамические?

В общем, тут проще положиться на рантайм проверки. В релизе их можно убрать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

VD>Ключевое слово здеть "В некоторых случаях". Еще раз. Общего решения тут быть не может.
Как правило именно эти некоторые случаи и являются критическими по производительности...
VD>Первые динамические данные и ты приехал. А зачем данные в массивы пихать если они не динамические?
Я не случайно выбрал именно такие имена для класса и челенов класса... Например это загруженая с диска модель или текстура или еще какиенибудь данные.

VD>В общем, тут проще положиться на рантайм проверки.
Если можно убрать проверки статическим анализом то нужно их убирать.
VD>В релизе их можно убрать.
А вот это делать не нужно. Особенно если мы говорим об управляемой ОС то там это сделать вобще нельзя.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>WolfHound wrote:
>> Вобщем С++ хороший язык... когдато был...
>> А сейчас рулят ковровые клинья и танковые бомбандировки тфу ты
>> управляемые среды, а дальше будут рулить упровляемые ОС типа Singularity
>> для которых на С++ вобще писать будет довольно проблематично.
C>Да вы, батенька, оптимист.

C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
C>абсолютно и полностью. С++ тоже плохо подходит, правда.

Все написаное основано на прочтении след. статьи

Некоторые особенности SPE:
— 256KBytes local store — здесь располагаются данные и программа
— Процессор предназначен для векторных вичисление. Обычные вычисления он делать может, но это не его задача, кроме того он также не предназначен для логики (много переходов)
— Своя система команд, хотя и есть пересечение с AltiVec (т.е. код нужно будет по крайне мере под него пересобрать)

Языки/решения:
1) Разделение языков. На основном процессоре (PPE) используется любой язык, для работы с SPE используется библиотека позволяющая загрузить некий job, посылать и получать данные с SPE, синхронизироваться. Для SPE используется некий достаточно низкоуровневый язык, с поддержкой векторных вычисление (ну или асм вставки) и примитивами для общения с другими SPE и PPE.

Для десктоп систем язык SPE возможно будет позводять создавать законченные mini-jobs, работающие по приниципу загрузился в SPE, сделал работу, освободили место для других.
Возможно будет некий язык описания интерфейсов на подобие IDL для COM/CORBA

Возможно на SPE вертиться миниОС, хотя скорее просто набор библиотек типа обмена с PPE/другими SPE, которые не имеет смысла выгружать.

2) Мини VM (без JIT), сидящая в SPE.
Это вряд ли, получиться медленно, да и памяти там не так много чтобы и VM и программу и еще входные и выходные данные засунуть. Но в любом случае это VM должна поддерживать все векторные возможность SPE.
Вообще моловероятные вариант, SPE сам по себе можно в качестве это VM и рассматривать (есть такие слова в статье)

3) VM c JIT.
Памяти надо еще больше чем в пред. пункте. Плюс тратить время на JIT, SPE под это не заточен

4) JIT на PPE генерирует native код для SPE из управляемого.
Т.е. на неком управляемом языке пишем, получаем IL, дальше JIT генерит код и грузит сразу в SPE на выплнение.
Забавно наверное выйдет.

В любомом случае маловероятным кажется, что все будет написано на одном языка. Слишком разные процессоры (один векторный и это его фишка), слишком разные задачи, необходимость выделения параллельных кусков для SPE, синхронизация, все компилатору/framework-у доверять не стоит.

P.S. Apple отказался от использования процессоров IBM хотя про Cell наверняка в курсе, видимо там считают, что на рынок Desktop систем это процессор ничего революционного не принесет

P.P.S. Вообще создалось такое впечатление, что автор пиарит Cell неколько больше чем следует. Да и вцелом от этого чуда ожидают больше чем оно сможет дать

Здравствуйте, RailRoadMan, Вы писали:

RRM>4) JIT на PPE генерирует native код для SPE из управляемого.
RRM>Т.е. на неком управляемом языке пишем, получаем IL, дальше JIT генерит код и грузит сразу в SPE на выплнение.
RRM>Забавно наверное выйдет.
ИМХО наиболие разумный вариант.

RRM>В любомом случае маловероятным кажется, что все будет написано на одном языка. Слишком разные процессоры (один векторный и это его фишка), слишком разные задачи, необходимость выделения параллельных кусков для SPE, синхронизация, все компилатору/framework-у доверять не стоит.
Если спроектировать ВМ для работы на NCC-NUMA системах, а это не только и не столько cell. То можно все делать на одном фреймворке. Болие того м коде программ можно раставлять хинты оптимизатору для того чтобы он лучше паралелил.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> WH>>А какие именно ограничения тебе так не нравятся?
> C>А может ли value-тип реализовать мой интерфейс?
> Может. Может ты хотябы изучишь .NET? К томуже учти что можно реализовать
> это все намного умнее чем это сделали мелкософты..

Value types can have fields, properties, and events. They can also have
static and nonstatic methods. When they are boxed, they inherit
the virtual methods from System.ValueType, and they can implement zero
or more interfaces.

И зачем мне забоксированый value-тип?

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Можно использовать "fat pointers" — то есть в указатель записывается
> еще и длина адресуемого блока (так было и на AS/400).
> Те указатели в общем случае должны быть в два раза больше?
Да.

> В любом случае это не спасет от смещения указателя на пол размера структуры. Те
> нам понадобится еще и размер структуры. Те указатель должен быть в 3
> раза больше... плюс куча транзисторов для проверки.
Поэтому толстые указатели и не используются.

> C>Но это обычно никому не нужно, главное дать гарантию, что код
> теоретически не сможет вырваться из своего sandbox'а. А для этого tagged
> pointer'ов вполне хватает.
> это нужно всем. Это надежность программы.
Нет. Это _не_ надежность программы. Надежность программы — это
отсутствие ошибок.

> Короче я так и не понял зачем нужны все эти сложности на низком уровне
> если анализ проведенный на высоком уровне позволяет этого избежать?
Нудно: "Затем что 'высокоуровневый' анализ накладывает слишком много
ограничений". Тем более, что tagged pointer'ы — это давно испробованый и
надежный вариант. Для его использования даже модули памяти не надо
менять — можно использовать бит четности для тэга.

> 1)В подавляющем большинстве случаев компилятор генерирует оптимальный код.
Однако это не всегда так. И в тех случаях, когда все-таки нормальный код
не генерируется — ничего сделать нельзя.

> 2)Упрощение процессоров позволит поднять производительность процессоров.
Небольшое упрощение.

> 3)Работы по совершенствованию оптимизаторов постоянно ведутся.
Я это слышу уже лет... не знаю сколько.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Нет. Это _не_ надежность программы. Надежность программы — это отсутствие ошибок.
Во-во... А аппаратная защита не может обеспечить даже строгую защиту памяти.
Хотя конечно если использовать тройные указатели (причем третий параметер должен быть не размер структура, а индекс в таблице типов ибо могут быть типы однакового размера) то проблема решается но ккой ценой?
Утроение размера указателя, плюс куча дополнительных таблиц которые тоже память кушают, плюс дополнительная логика зашитая в железо. Не слишком ли?

C>Нудно: "Затем что 'высокоуровневый' анализ накладывает слишком много ограничений". Тем более, что tagged pointer'ы — это давно испробованый и надежный вариант. Для его использования даже модули памяти не надо менять — можно использовать бит четности для тэга.
Я не считаю что это принципиальные ограничения. Те ограничения которые не дают возможность работать.

>> 1)В подавляющем большинстве случаев компилятор генерирует оптимальный код.
C>Однако это не всегда так. И в тех случаях, когда все-таки нормальный код не генерируется — ничего сделать нельзя.
Опять таки в подавляющем большинству случаев когда это происходит это не критично.
А что касается всех остальных то за все нужно платить.
К томуже у меня сейчас появилась мысль о том что такие системы могут производить валидацию ассемблерного кода который будет работать на данной платформе. Те в осбо маразматических случаях можно будет писать на ассемблере конкретной железки возможно с какимито ограничениями.
Но об этом еще подумать надо.

>> 2)Упрощение процессоров позволит поднять производительность процессоров.
C>Небольшое упрощение.
Если делать защиту в полный рост то большое.

>> 3)Работы по совершенствованию оптимизаторов постоянно ведутся.
C>Я это слышу уже лет... не знаю сколько.
А я вижу что оптимизаторы с каждым новым релизом становятся умнее.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>И зачем мне забоксированый value-тип?
Скажем для того чтобы использовать этот value тип в генерике у которого в констрейнтах прописан этот интерфейс. В данном случае не точто боксинга не будет, а компилятор просто заинлайнит все что можно.
К томуже ты пляшешь от решения... в то время как надо работать от задачи.
К томуже ты опять пристал к .NET'у в то время как мы тут обсуждаем процессоры вобще и управляемые ОС вобще.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, VladD2, Вы писали:

VD>Не реально, так как в общем случае данные могут появляться динамически и прийдется их контролировать в рантайме. При этом прийдетя вводить нечто воде небезопасных приведений типов.
Неа. Точнее, да, придется, но такие приведения будут вполне безопасными и редкими. Вот, к примеру, джиту дотнета не надо каждый раз в рантайме проверять, что объект на вершине стека имеет нужный тип для выполнения следующего вызова. Потому, что тип объекта можно проверить статически — если на стеке лежит параметр текущего метода, и параметр имеет нужный тип, то все в порядке. Проверка того, что нам не передали объект неверного типа, выполнена снаружи метода.
Ок, где-то вверху по стеку вызовов это был просто object, про который статически ничего неизвестно. Для того, чтобы удовлетворить верификатор, мы будем обязаны явно поставить cast. Этот cast таки будет выполняться в рантайме, медленно и печально. Но! Как только он прошел, объект можно уже не проверять. А внутри "безопасных границ" может выполняться очень много обращений к этому объекту.

Ту же идею можно попробовать применить к контролю чего угодно: и деления на ноль, и выхода за границы. Конечно, это несколько сложнее, т.к. операций, потенциально выводящих за пределы проверенного множества, значительно больше. Но принципиально это возможно.

1.1.4 stable rev. 510

WolfHound wrote:
> C>И зачем мне забоксированый value-тип?
> Скажем для того чтобы использовать этот value тип в генерике у которого
> в констрейнтах прописан этот интерфейс. В данном случае не точто
> боксинга не будет, а компилятор просто заинлайнит все что можно.
> К томуже ты пляшешь от решения... в то время как надо работать от задачи.
> К томуже ты опять пристал к .NET'у в то время как мы тут обсуждаем
> процессоры вобще и управляемые ОС вобще.
Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы
или быть наследником абстрактного класса при программном контроле.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы или быть наследником абстрактного класса при программном контроле.
Учите матчасть.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы
> или быть наследником абстрактного класса при программном контроле.
> Учите матчасть.
Прекрасно. Тогда расскажите как управляемая среда будет разруливать
такой код:

public static IComparable comp_;

void setComparable(IComparable comp)
{
    comp_=comp;
}

...
struct SomeValueType : IComparable
{
...
}

void someFunc()
{
SomeValueType tp; //Живет до конца стека

setComparable(tp); //Передаем в виде интерфейса. Время жизни: ???
}

Управляемая среда обязана перераспределить объект SomeValueType в
динамической памяти (иначе после выхода из someFunc в comp_ будет
висящий указатель). Что собственно сводит на "нет" возможность
использования value-типов для замены автоматических объектов.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Прекрасно. Тогда расскажите как управляемая среда будет разруливать
В таком коде никакого боксинга не будет

        struct Test : IComparer
        {
            public int Compare(object x, object y)
            {
                return ((IComparable)x).CompareTo(y);
            }
        }
        static void ByValue<T>(T asd)
            where T : IComparer
        {
        }
        static void ByRef<T>(ref T asd)
            where T : IComparer
        {
        }
        static void Main()
        {
            Test t = new Test();
            ByValue(t);
            ByRef(ref t);

C>такой код:
C>Управляемая среда обязана перераспределить объект SomeValueType в динамической памяти (иначе после выхода из someFunc в comp_ будет висящий указатель).
В таком коде действительно будет боксинг. Но это не мешает структурам реализовывать интерфейсы и при этом обходится без боксинга.

C>Что собственно сводит на "нет" возможность использования value-типов для замены автоматических объектов.
Приведи аналог этого кода на С++

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Прекрасно. Тогда расскажите как управляемая среда будет разруливать
> В таком коде никакого боксинга не будет
Я и не говорил, что он будет _всегда_.

> В таком коде действительно будет боксинг. Но это не мешает структурам
> реализовывать интерфейсы и при этом обходится без боксинга.
Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для
проверки совместимости для generic'ов или проверок типов.

Но не для виртуальных вызовов.

> C>Что собственно сводит на "нет" возможность использования value-типов
> для замены автоматических объектов.
> Приведи аналог этого кода на С++
Я сразу буду распределять объект в куче. Либо еще можно делать так:

struct Base
{
    virtual ~Base(){};
    virtual void someMethod()=0;
};
Base *theBaseObject=NULL;
void setBase(Base *obj) {theBaseObject=obj;}

struct SomeType : public Base
{
    int val;
    virtual void someMethod(){blah();}
};

void someFunc()
{
    SomeType tp;
    setBase(&tp);
    ON_BLOCK_EXIT(&setBase,NULL);

    ...
}

То есть я _могу_ записать указатель на автоматический объект в
глобальной переменной без накладных затрат.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Sinclair, Вы писали:

VD>>Не реально, так как в общем случае данные могут появляться динамически и прийдется их контролировать в рантайме. При этом прийдетя вводить нечто воде небезопасных приведений типов.
S>Неа. Точнее, да, придется, но такие приведения будут вполне безопасными и редкими.

Короче, разговор этот бесмысленный. Нашей компетенции в этой области явно недостаточно.
То о чем вы говорите называется программное доказательством теорем. Вопрос офигительно не простой. На сколько я знаю сейчас такие вещи есть только в очень исследовательских языках. Кстати, один из таких языков — это Spec#. Забавно что в одном из Нэмероловских документов проскакивает упоминание, что в будущем они намерены встроить подобную фичу и в Нэмерел:
https://nemerle.org/macrouse.html#designbycontract

2.4. Future work
...
Plug a theorem prover designed for Spec# into Nemerle, so we can check assertions not only in the runtime, but also statically at compile-time.

Но как видишь как всегда портит слова "not only" потому как в общем случае это невозможно.

S>Ту же идею можно попробовать применить к контролю чего угодно: и деления на ноль, и выхода за границы. Конечно, это несколько сложнее, т.к. операций, потенциально выводящих за пределы проверенного множества, значительно больше. Но принципиально это возможно.

Можно. Но не всегда и, ну, очень сложно! Хотя на то они и мечты о будущем.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Cyberax, Вы писали:

C>Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для проверки совместимости для generic'ов или проверок типов.
C>Но не для виртуальных вызовов.
А зачем? value типы используются при оптимизации чего либо. Если оптимизировать ничего то надо использовать reference типы.
Скажем когда я писал бинарный diff мне нужно было оперировать десятками миллионов объектов. В этом случае я использовал value типы ибо столько ссылочных объектов на ровном месте не оправданная нагрузка на ГЦ. Также я ручками написал хеш таблицу ибо та что в фреймворке меня не устраивала.
А если мне не нужно оптимизировать то я о value типах даже не думаю.

C>Я сразу буду распределять объект в куче.
В таком случае сразу создаешь reference тип и никаких проблем.
C>Либо еще можно делать так:
хъ
C>То есть я _могу_ записать указатель на автоматический объект в глобальной переменной без накладных затрат.
А вот за такой код я оторву руки ибо это не надежно даже по С++ным меркам.
Короче ты опять пытаешься привести решение которое плохо варажается на C# но о том что ту задачу которую ты хочешь решить можно решить банально иначе почемуто не задумываешься.
Пойми одну простую вешь: В С++ выгодно использовать одни паттерны в C# другие. И не надо пытатся делать выводы на основании что те паттерны к которым ты привык работают плохо ибо есть другие.
Короче хватит приводить решения. Давай задачу.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Нет. Это _не_ надежность программы. Надежность программы — это
> отсутствие ошибок.
> Во-во... А аппаратная защита не может обеспечить даже строгую защиту памяти.
Аппаратная защита позволяет обеспечить строгую защиту. В смысле что
приложение не вырвется за пределы своей песочницы (хотя и может получить
фатальные повреждения из-за ошибки).

В Vista будет такой механизм, а в FreeBSD уже многие годы есть система
jail-ов (каждую программу можно "посадить" в тюрьму с контролируемым
окружением). И это учитывая не особую приспособленность x86 для
виртуализации.

> Утроение размера указателя, плюс куча дополнительных таблиц которые тоже
> память кушают, плюс дополнительная логика зашитая в железо. Не слишком ли?
Просто это никому не нужно.

> Я не считаю что это принципиальные ограничения. Те ограничения которые
> не дают возможность работать.
Я считаю. Даже в Windows или FreeBSD c jail'ом я могу при желании
спуститься на уровень железа (с соответствующим контролем доступа к
критичным ресурсам типа обработки прерываний).

Managed-OSы лишат меня этой возможности ради того, чтобы программы
криворуких малограмотных программистов работали "надежно". Нафиг это
нужно мне? Со мной согласны game-developer'ы и даже сам MS, который
продолжает писать свои продукты на unmanaged-языках.

> Опять таки в подавляющем большинству случаев когда это происходит это не
> критично.
Да? А игры/вычислительный софт/"тяжелый" софт и т.п.? И это совсем не
маленький сегмент.

> К томуже у меня сейчас появилась мысль о том что такие системы могут
> производить валидацию ассемблерного кода который будет работать на
> данной платформе.
Ха. Хаха. Хахаха.

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

>> > 2)Упрощение процессоров позволит поднять производительность процессоров.
> C>Небольшое упрощение.
> Если делать защиту в полный рост то большое.
Где? MMU все равно нужен, а сегодняшняя защита на x86 фактически и
состоит только из MMU.

Tagged pointer'ы тоже реализуются абсолютно тривиально.

И при этом tagged pointer'ы позволяют переиспользовать с небольшими
изменениями почти весь существующий софт.

> C>Я это слышу уже лет... не знаю сколько.
> А я вижу что оптимизаторы с каждым новым релизом становятся умнее.
И все равно остаются внутренние циклы, дающие в разы больший прирост
скорости при переписывании на асме.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>В Vista будет такой механизм, а в FreeBSD уже многие годы есть система
C>jail-ов (каждую программу можно "посадить" в тюрьму с контролируемым
C>окружением). И это учитывая не особую приспособленность x86 для
C>виртуализации.

Я не знаю, будет ли в Vista что либо новое в OS (а не в UI). В Windows уже давно существует понятие Job. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/job_objects.asp. Насколько я понимаю, это примерно эквивалентно freebsd jail.

).
Java (как и язык Eiffel, кстати) более приспособлена к такой работе, но там тоже есть свои трудности.

alexeiz wrote:
> Я не знаю, будет ли в Vista что либо новое в OS (а не в UI). В Windows
> уже давно существует понятие Job.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/job_objects.asp.
> Насколько я понимаю, это примерно эквивалентно freebsd jail.
Не совсем. Программа в jail'е видит только свою файловую систему и
только свои процессы. Почти что отдельный компьютер получается.

Posted via RSDN NNTP Server 2.0

WolfHound wrote:
> C>Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для
> проверки совместимости для generic'ов или проверок типов.
> C>Но не для виртуальных вызовов.
> А зачем? value типы используются при оптимизации чего либо. Если
> оптимизировать ничего то надо использовать reference типы.
Оптимизировать нужно _все_ — то есть сразу писать нормальный код. В С++
автоматические типы вводятся неинтрузивно, в отличие от .NET.

> C>То есть я _могу_ записать указатель на автоматический объект в
> глобальной переменной без накладных затрат.
> А вот за такой код я оторву руки ибо это не надежно даже по С++ным меркам.
Согласен, привел первый пример, который пришел в голову. Самое главное,
что я хотел проиллюстрировать — использование виртуальных вызовов (через
виртуальный базовый тип) на value-типах не возможно.

> Короче ты опять пытаешься привести решение которое плохо варажается на
> C# но о том что ту задачу которую ты хочешь решить можно решить банально
> иначе почемуто не задумываешься.
Иногда для оптимальных решений на С++ просто нет аналога в C#.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
Нет таких задач где надо оптимизировать 100% кода. Нету!
C>В С++ автоматические типы вводятся неинтрузивно, в отличие от .NET.
Для оптимизации болие чем хватает. А когда оптимизировать не надо то reference типов вполне достаточно.
А вобще в моей практике даже когда я писал не С++ всегда существовало четкое разделение на value и reference типы. Те один и тотже класс использовался либо только как value тип либо только как reference.

C>Согласен, привел первый пример, который пришел в голову. Самое главное, что я хотел проиллюстрировать — использование виртуальных вызовов (через виртуальный базовый тип) на value-типах не возможно.
А зачем? Чесно говоря я не вижу задач для чего это нужно.

C>Иногда для оптимальных решений на С++ просто нет аналога в C#.
Например? Я не обещаю решения на C# ибо .NET довольно бедная VM но мы тут говорим об управляемых средах вобще.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

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

C>В Vista будет такой механизм, а в FreeBSD уже многие годы есть система jail-ов (каждую программу можно "посадить" в тюрьму с контролируемым окружением). И это учитывая не особую приспособленность x86 для виртуализации.
Защиты программы от самой себя? Не смешите мои тапочки... Это не x86 не реально. Разве что только в том случае если поверх x86 работает управляемая система.

C>Просто это никому не нужно.
И .NET с жабой тоже никому не нужны?

C>Я считаю. Даже в Windows или FreeBSD c jail'ом я могу при желании спуститься на уровень железа (с соответствующим контролем доступа к критичным ресурсам типа обработки прерываний).
А зачем?

C>Managed-OSы лишат меня этой возможности ради того, чтобы программы криворуких малограмотных программистов работали "надежно". Нафиг это нужно мне?
Проблема в том что это гдето 99.999999% программистов...
C>Со мной согласны game-developer'ы и даже сам MS, который продолжает писать свои продукты на unmanaged-языках.
Про МС с геймдевом вобще не заикайся. И тех и других нужно пересадить в управляемую среду. Ты например знаешь что XBox 360 постоянно сваливается в синий экран?
Я работал в одной из крупнейших контор по производству игр в России... так вот я очень хорощо знаю как пишут игры... Там постоянно ловили то порчу памяти то утечку... а какая там архитектура... И я видел код нескольких контор... везде одно и тоже...
Я лучше помолчу, а то придется самого себя забанить.

C>Да? А игры/
Про игры я уже сказал.
C>вычислительный софт/
Вот только его все чаще и чаще пишут на жабе... ибо нужно не только вычислить но еще и написать сложный вычислительный алгоритм...
C>"тяжелый" софт и т.п.? И это совсем не маленький сегмент.
Что такое тяжолый софт?

C>Программирование на ассемблере требует адресной арифметики, реинтерпретации регистров и еще много неконтролируемых вещей. Доказать корректность ассемблерного кода будет невозможно, если не наложить на него еще более драконовских ограничений, чем на managed-языки.
Моя интуиция говорит что в подавляющем большинстве случаев можно будет доказать процедуры вида

void DoSome(byte[] bytes, float[] floats)
{
    asm
    {
        ...
    }
}

Ибо нам нужно доказать лишь то что ну будет произведено чтение/запись за приделы массивов.
А операции с адресами как правило не такие уж хитрые.

C>Где? MMU все равно нужен, а сегодняшняя защита на x86 фактически и состоит только из MMU.
И мы имеем кучу софта который падает на ровном месте... А контроль всего и вся в железе потребует очень больших дополнительных затрат памяти.

C>Tagged pointer'ы тоже реализуются абсолютно тривиально.
Вот только толку от них...
C>И при этом tagged pointer'ы позволяют переиспользовать с небольшими изменениями почти весь существующий софт.
Существующий софт можно запускать на современном железе в отдельном процессе... ибо никто не мешает управляемой ОС создавать не управляемые процессы в отдельном адрессном пространстве.

C>И все равно остаются внутренние циклы, дающие в разы больший прирост скорости при переписывании на асме.
Ну в разы это ты ивно загнул. У тебя получилось 25%, тут в этой ветке приводили пример в 2 раза но там как выяснилось еще и алгоритм поправили...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, iZEN, Вы писали:

ZEN>Есть специально заточенный под это дело язык программирования Оккам:
ZEN>http://www.cluster.bsu.by/Kniga4/Chapter5.pdf
Интересное чтиво. В принципе Оккам можно применять в качестве ассемблера для ВМ. Далие это все оптимизируется под конкретную архитектуру машины.
Скажем такой код

for(int i = 0; i < n; ++i)
{
    vertexes[i] = vertexes[i] * matrix;
}

на логичеком уровне будет порождать n паралельных процессов. Но скажем если это дело запустить на какомнибудь cell'е то оптимизатор разобьет это дело на 7 групп процессов. Далие каждая группа будет превращена в один процесс работающей над частью массива. После чего эти процессы будут раскиданы по SPU.

ZEN>C# не может правилнь выполняться на многопроцессорных машинах. Он не поддерживает контролируемое распространение проверяемых (Checked) исключений и управляемую развёртку фреймов стэка в связи с этим (только крэш нити

).
ZEN>Java (как и язык Eiffel, кстати) более приспособлена к такой работе, но там тоже есть свои трудности.
Чесно говоря не понял чем жаба лучше .НЕТ. И причем тут checked exceptions?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>WolfHound wrote:
>> Нашол какуюто статью но там както все мутно написано.
>> Я так понял что программа должна подготовить данные и код для SPU, а он
>> очень быстро этот код с этими данными будет выполнять?
C>Примерно так, хотя выполнять он может и совсем не быстро.

напомнило байку про Commodore C64. У этих компьютеров был очень занятный дисковод. Настолько занятный, что некоторые программы отказывались запускаться на машинах без дисковода. Не грузится, а именно запускаться. А дело было в том, что контроллер дисковода по мощности не уступал самому компьютеру. Такой же точно процессор, и что-то порядка 64 кб памяти (а это очень не мало для конца 80-х). И есс-но ушлые программисты того времени не могли пройти равнодушным мимо такого чудо-дисковода. По-быстренькому совали в контроллер свой код, и дисковод очень здорово обсчитывал графику в играх (или демках). Праотец CELL'а так сказать был...

Впрочем наши тоже изобретали нечто подобное. Как известно, ZX-Spectrum обладал 3.5mhz процессором Z-80 (команды с опкодами 243, 118 кто-нить ещё помнит ?

) и физически не мог играть оцифрованный звук паралелльно с исполнением кода приложения. (Стоит упомянуть о разных ухищрениях, когда исполнение кода просчитывается так, что можно вырвать десяток-другой тактов процессора, и немножечно "порисовать" ценой этих тактов, что вызывало плохенькую, но иллюзию параллельной игры оцифровки. Первым был, если не ошибаюсь, гениальный харьковский программист с ником RST-7. Дмитрий. Фамилии уже не помню).
Так вот, питерские ребята соорудили девайс с именем General sound, который имел 128кб памяти, и ещё один Z-80. Компы с этим девайсом уже могли играть в фоне оцифровки и их тоже пользовали ушлые программеры для исполнения обычного кода. Правда general sound это вам не штатный дисковод, широкого распространения он не получил...

Ээээх ностальгия! А ведь чем не CELL ?

Здравствуйте, Cyberax, Вы писали:
C>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
Еще один поклонник оптимизаций. Нормальный код в большинстве типичных приложений написать сразу невозможно. Потому что оценивать нагрузку на код заранее слишком сложно.
Так что честные люди пользуются для оптимизации профайлером, а не C++. Я не спорю, некоторые вещи до сих пор нужно писать на ассемблере (хотя в жизни я таких примеров не встречал. А вот горе-оптимизаторов, которые писали более красивый, но медленный код под x86, чем генерит VC++ — встречал.). Но к счастью их мало.
C>Согласен, привел первый пример, который пришел в голову. Самое главное,
C>что я хотел проиллюстрировать — использование виртуальных вызовов (через
C>виртуальный базовый тип) на value-типах не возможно.
Все возможно. В тех случаях, когда компилятор/джит может проверить тип статически, никакого боксинга не происходит. В тех случаях, когда ты бы стал выделять память в куче, дотнет тоже выделит память в куче.

1.1.4 stable rev. 510

Здравствуйте, RailRoadMan, Вы писали:

RRM>P.S. Apple отказался от использования процессоров IBM хотя про Cell наверняка в курсе, видимо там считают, что на рынок Desktop систем это процессор ничего революционного не принесет
Кажется Apple даже коментарии давала по этому поводу., но не могу вспомгить гдже читал .

RRM>P.P.S. Вообще создалось такое впечатление, что автор пиарит Cell неколько больше чем следует. Да и вцелом от этого чуда ожидают больше чем оно сможет дать

Я лично после просмотра некоторых демок для PS3 , в том числе по обработке изображений , убедился что этонамного больше чем от него ожидают. Все потрясения еще впереди. !!!

newuser2 wrote:
> Ээээх ностальгия! А ведь чем не CELL ?
И что закономерно, многие Z80-хакеры ушли в профессиональную разработку
игр. Вспомнить того же CopperFeet'а (Медноногова).

Posted via RSDN NNTP Server 2.0

Sinclair wrote:
> C>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
> Еще один поклонник оптимизаций. Нормальный код в большинстве типичных
> приложений написать сразу невозможно. Потому что оценивать нагрузку на
> код заранее слишком сложно.
Странно, а я почему-то сразу догадался, что обсчет поверхности в моем
приложении явно не будет самой быстрой частью. Поэтому структуры данных
для нее сразу проектировал с рассчетом на оптимизацию.

Вероятно у меня просто такие задачи, где понятно сразу что будет тормозить.

> C>Согласен, привел первый пример, который пришел в голову. Самое главное,
> C>что я хотел проиллюстрировать — использование виртуальных вызовов (через
> C>виртуальный базовый тип) на value-типах не возможно.
> Все возможно. В тех случаях, когда компилятор/джит может проверить тип
> статически, никакого боксинга не происходит.
Я это, кажется, и сказал. Только это получается достаточно узкий частный
случай.

Posted via RSDN NNTP Server 2.0

Здравствуйте, WolfHound, Вы писали:

C>>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
WH>Нет таких задач где надо оптимизировать 100% кода. Нету!

Так вопрос в том, что Сингулярити запрещает возможность оптимизированных "вставок".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

C>>Будут рулить вещи типа cell-архитектур для которых C# не подходит абсолютно и полностью. С++ тоже плохо подходит, правда.
WH>И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете лень.

Философия Cell

Принципы, заложенные в архитектуру нового чипа, были разработаны в начале 2000 года инженерами IBM. Идея массового параллелизма, на основе которой работает Cell, была заложена в так называемую ("cellular architecture") "клеточную архитектуру", в которой для создания суперкомпьютеров используется множество однотипных процессоров (от 10 тыс. до 1 миллиона), каждый из которых оснащён собственным контроллером RAM и определённым объёмом самой оперативной памяти.

Стоит также вспомнить про Beowolf-кластеры, построенные на базе простых компьютеров-"кирпичиков" и объединённые в единую систему.

В 2001 году во время обнародования первых данных Кен Кутараги сопоставил Cell с построенным по принципу кластерной системы суперкомпьютером Deep Blue. Сравнение было дано не просто так: оно отображает саму философию Cell. "Благодаря встроенной возможности объединения чипов Cell, микропроцессоры, являющиеся сегодня "индивидуальными островками", будут связаны между собой более тесно, благодаря чему сеть на основе таких процессоров превратится в одну унифицированную "суперсистему".

Как простые биологические клетки в теле, объединяющиеся для создания полноценных физических систем, электронные устройства на базе Cell будут блоками для больших систем", — так описывал Кутараги концепцию Cell.

Что же значат его слова? Cell может работать не только в качестве, собственно, процессора, но и в качестве элемента большой системы. Путём объединения различной техники, содержащей чипы Cell, можно построить единую сеть, которая будет функционировать, как одно "устройство". Представим следующую ситуацию: консоль PlayStation 3 подключена к HDTV-телевизору, к которому, в свою очередь, подключён Blu-Ray-рекордер. Все три устройства оснащены процессорами Cell. Пользователь, играя в какой-нибудь WipeOut Fusion 2, даёт команду рекордеру записать очередной заезд в HDTV-формате. При этом Cell в телевизоре помогает своему "напарнику" записывать игру. После записи освободившиеся Cell'ы телевизора и рекордера "спешат на помощь" процессору PlayStation 3, в результате чего количество FPS в игре многократно ускоряется.

Таким образом, производительность отдельных Cell-устройств в сети может повышаться за счёт процессоров других устройств. Причём чипам безразлично, где находятся другие элементы сети: в одной комнате, доме, городе, или на другом континенте. Да и устройства, кстати, могут быть абсолютно разные: от уже упоминавшихся игровых консолей и телевизоров до персональных компьютеров, КПК и даже мобильных телефонов!

Единая глобальная сеть. Разве не об этом долгие годы мечтают писатели-фантасты? С приходом Cell мечты могут стать реальностью. Но мы отложим их на потом и перейдём к теме статьи — процессору Cell.

Полностью здесь.

[RSDN@Home][1.2.0][alpha][643]
[Hет ничего глупее желания всегда быть умнее всех. [Ф. Ларошфуко]]

Слышатся крики по поводу поддержки Cell рынком программного обеспечения и, в первую очередь, операционными системами. Скажем следующее: недавно IBM продала свой бизнес по производству ПК китайской компании Lenovo, сосредоточив все усилия на разработке Linux, и именно IBM занимается переносом этой ОС на Cell. Мягко говоря, довольно распространённая система, особенно среди программистов, да и новые программы к ней появляются, "как грибы после дождя". Перенос их на Cell не составит особых проблем (оптимизация под SPE потребует некоторых усилий, но это уже другой вопрос).

Оттудаже, послесловие.

Ктото тут смеялся когда я говорил что IBM перестраивается в сторону Linux... Вот вам пожалуйста. Ждем Cell

[RSDN@Home][1.2.0][alpha][643]
[Благочестие, ханжество, суеверие — три разницы. [К. Прутков]]

Здравствуйте, WolfHound, Вы писали:

C>>Медленно будет.
WH>Правда? А почему тогда сингулярити на многих тестах рвет и винду и линух? Она же по определению медленная?

В студию!

[RSDN@Home][1.2.0][alpha][643]
[Замужество открывает женщинам глаза на саму себя. [Кузьма Чорный]]

Здравствуйте, Sheridan, Вы писали:

S>В студию!
В поиск!

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Sheridan, Вы писали:

S>Таким образом, производительность отдельных Cell-устройств в сети может повышаться за счёт процессоров других устройств. Причём чипам безразлично, где находятся другие элементы сети: в одной комнате, доме, городе, или на другом континенте. Да и устройства, кстати, могут быть абсолютно разные: от уже упоминавшихся игровых консолей и телевизоров до персональных компьютеров, КПК и даже мобильных телефонов!
Господа явно лукавят.
1)Они не учитывают что связь между компьютерами по сравнению со связью внутри одного чипа просто фантастически медленная. По этому увеличения FPS при подключении cell'а из телевизора будет только если архитектуру игры заточить под это, а это не просто.
2)Для того чтобы собрать кластер процессоры не обязательно должны быть cell'ами. Это можно и на x86'ых прекрасно сделать.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> for(int i = 0; i < n; ++i)
> {
> vertexes[i] = vertexes[i] * matrix;
> }
> на логичеком уровне будет порождать n паралельных процессов. Но скажем
> если это дело запустить на какомнибудь cell'е то оптимизатор разобьет
> это дело на 7 групп процессов. Далие каждая группа будет превращена в
> один процесс работающей над частью массива. После чего эти процессы
> будут раскиданы по SPU.
Такое давно уже умеет OpenMP (который есть для С++ и Fortran'а).

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Такое давно уже умеет OpenMP (который есть для С++ и Fortran'а).
Я в курсе что есть OpenMP вот только там все делается ручками... В то время как можно паралелить на автомате... Все что нужно сделать это определить зависимости по данным.
Таким образом мы получаем логическую структуру процессов. Далие оптимизатор сам раскладывает эти процессы по физическим процессорам. После того как процессы были раскидыны по процессорам можно произвести слияние процессов в один процесс, после чего этот процесс можно оптимизировать.
Все что нам нужно сделать это написать алгоритм так чтобы было как можно меньше зависимотсей по данным.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> C>Такое давно уже умеет OpenMP (который есть для С++ и Fortran'а).
> Я в курсе что есть OpenMP вот только там все делается ручками... В то
> время как можно паралелить на автомате... Все что нужно сделать это
> определить зависимости по данным.
Такое он, в теории, тоже может сам просчитывать, если гарантируется
отсутствие aliasing'а (что почти всегда верно для MP-программ). на
практике (в родном универе используют OpenMP) получается, что лучше
руками указывать.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Cyberax, Вы писали:

C>Такое он, в теории, тоже может сам просчитывать, если гарантируется отсутствие aliasing'а (что почти всегда верно для MP-программ). на практике (в родном универе используют OpenMP) получается, что лучше руками указывать.
Я думаю что ноги тут растут из того что оптимизаторы современных компиляторов всетки заточены на однопоточный код.
ИМХО в будущем это изменится.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Cyberax, Вы писали:

C>>И все они x86. За исключением Itanium, который все равно не сильно
C>>отличается.

AVK>

Shure?

что за шура ?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Sheridan, Вы писали:

S>>Таким образом, производительность отдельных Cell-устройств в сети может повышаться за счёт процессоров других устройств. Причём чипам безразлично, где находятся другие элементы сети: в одной комнате, доме, городе, или на другом континенте. Да и устройства, кстати, могут быть абсолютно разные: от уже упоминавшихся игровых консолей и телевизоров до персональных компьютеров, КПК и даже мобильных телефонов!
WH>Господа явно лукавят.
WH>1)Они не учитывают что связь между компьютерами по сравнению со связью внутри одного чипа просто фантастически медленная. По этому увеличения FPS при подключении cell'а из телевизора будет только если архитектуру игры заточить под это, а это не просто.
По логике — да, только вот кто его знает.. Такие взрослые дядьки и не учитывают... Можно разгрузить обсчет графики за счет того что отдадим просчет звука кому нибудь, скажем видику, на приставке подготавливать полигоны и еще чтонибудь и отдавать подготовленные данные телевизору, который скажем ложит текстуры...
Хотя да, надо бы покопать в сторону как данные передаются...

WH>2)Для того чтобы собрать кластер процессоры не обязательно должны быть cell'ами. Это можно и на x86'ых прекрасно сделать.
Да все можно. Только вот переделать x86 xчтоы на кристалле можно было без особых переделок размещать нужное количество SPE (Синергический процессорный элемент) и станет похоже на Cell. Я хочу сказать что cell расширяем не только снаружи (2, 5, 8 камней) но и изнутри (по количеству SPE на кристалле), причем с минмальными затратами на переделку оборудования. Обратите внимание на расположение шины EIB (связывающей все в кучу) и SPE относительно её...

[RSDN@Home][1.2.0][alpha][643]
[Доброта лучше красоты. [Г. Гейне]]

Здравствуйте, WolfHound, Вы писали:

WH>Вот я не могу понять зачем нужна железная защита?
Потомучто быстрее имхо... Хотя на самом деле интересно узнать во сколько тактов выльется проверка железякой и во сколько тактов выльется проверка софтом...

[RSDN@Home][1.2.0][alpha][643]
[Если для одних вы будете ортодоксом, то для других — еретиком. [Д. Толанд]]

Здравствуйте, Sheridan, Вы писали:

WH>>Вот я не могу понять зачем нужна железная защита?
S>Потомучто быстрее имхо... Хотя на самом деле интересно узнать во сколько тактов выльется проверка железякой и во сколько тактов выльется проверка софтом...
Перечитай тему.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Sheridan, Вы писали:

S>По логике — да, только вот кто его знает.. Такие взрослые дядьки и не учитывают... Можно разгрузить обсчет графики за счет того что отдадим просчет звука кому нибудь, скажем видику, на приставке подготавливать полигоны и еще чтонибудь и отдавать подготовленные данные телевизору, который скажем ложит текстуры...
Это называется маркетинговый бред. Для того чтобы программа хорошо паралелилась ее архитектура должна быть на это расчитана. А если архитектура на это расчитана то cell'ы уже не обязательны.

S>Да все можно. Только вот переделать x86 xчтоы на кристалле можно было без особых переделок размещать нужное количество SPE (Синергический процессорный элемент) и станет похоже на Cell. Я хочу сказать что cell расширяем не только снаружи (2, 5, 8 камней) но и изнутри (по количеству SPE на кристалле), причем с минмальными затратами на переделку оборудования. Обратите внимание на расположение шины EIB (связывающей все в кучу) и SPE относительно её...
Читай это до просветления. Ребята загнали 8 процессоров и шину в один кристал и назвали это революцией...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

S>>По логике — да, только вот кто его знает.. Такие взрослые дядьки и не учитывают... Можно разгрузить обсчет графики за счет того что отдадим просчет звука кому нибудь, скажем видику, на приставке подготавливать полигоны и еще чтонибудь и отдавать подготовленные данные телевизору, который скажем ложит текстуры...
WH>Это называется маркетинговый бред. Для того чтобы программа хорошо паралелилась ее архитектура должна быть на это расчитана. А если архитектура на это расчитана то cell'ы уже не обязательны.

Согласен, добавлю только ещё то что в большинстве случаев проблема даже не в архитектуре программы, а в том что сама задача не распараллеливается или расходы на её распараллеливание превосходят выгоды от самого распараллеливания.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

WH>Читай это до просветления.
Почитаю, пасиб...

WH>Ребята загнали 8 процессоров и шину в один кристал и назвали это революцией...
16, 32, 64... только чип длиннее получается

[RSDN@Home][1.2.0][alpha][643]
[Если для одних вы будете ортодоксом, то для других — еретиком. [Д. Толанд]]

Здравствуйте, WolfHound, Вы писали:

C>>А где мой любимый C++ и
WH>Блин ну напиши компилятор который будет генерировать код данной виртуальной машины если тебе так хочется попрограммировать на этом антиквариате. Вот тольк зачем если тотже немерле рвет С++ как тузик грелку?

Уважаемый, это происходит только в Вашем воображении...

Здравствуйте, Left2, Вы писали:

L>Согласен, добавлю только ещё то что в большинстве случаев проблема даже не в архитектуре программы, а в том что сама задача не распараллеливается или расходы на её распараллеливание превосходят выгоды от самого распараллеливания.
Согласен. Хотя нипример 3D вобще и игры в частности очень хорошо паралелятся.
В принципе половину треугольников можно отрендерить в приставке, а половину в телевизоре. Но это всеравно не отменяет того что полученые изображения нужно слить, а для этого результаты работы нескольких процессоров должны оказатся в одном месте. Кстати при распаралеливании появляется проблема с альфа каналом.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, LeeMouse, Вы писали:

LM>Уважаемый, это происходит только в Вашем воображении...

Арументы будут?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH>Проблема в том что это гдето 99.999999% программистов...

Позвольте с вами не согласиться !

Здравствуйте, minorlogic, Вы писали:

WH>>Проблема в том что это гдето 99.999999% программистов...
M>Позвольте с вами не согласиться !
Я еще не видел людей которые не ошибаются.
А ловить тупой ляп который иногда совсем чуть-чуть залезает в чужую память ой как не просто.
Именно по этому я предпочетаю тотальный контроль рантаймом всего чего можно ибо в этом случае этот ляп вылезет сразу.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Cyberax, Вы писали:

C>Tapestry+Hibernate — рулят

Кстати, этот негатив прокомментировать можеш?

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Andrei N.Sobchuck wrote:
> C>Tapestry+Hibernate — рулят
> Кстати, этот негатив
> <http://groups.google.com.ua/group/fido7.ru.java/msg/1114e8daf58b1784?as_umsgid=cs64l2%24lmh%241@host.talk.ru>
> прокомментировать можеш?
Запросто.

Tapestry осуществляет трекинг хождения
пользователя. Делает он это не супер быстро.
Кликаешь много раз мышей нассылку и ты попал.

Есть стандартная защита от мультиклика.

Грубо говоря присваивание IDшников. Дык вот это
обозначает что транзакционность обеспечить нельзя,
потому как, если у тебя есть в Page метод
getUsers(), который волзает в базу за
пользователями, то процесс ревиндинга страницы
после вызова listenerа на этой странице вызовет
этот метод еще раз, для того чтобы получить
собственно объект, на котором ты кликнул. При чем
вызовет изнутри своего движка. Это значит, что
никакой атомарности обеспечить нельзя в принципе.
Движок сам, когда попало и как попало зовет методы
которые потенциально могут выполняться в
транзакционном контексте. Ахренительно.

Неправильный дизайн. Rewinding нужен для stateless-страниц. А если у нас
предполагаются изменения в базе между rewinding'амии _и_ это для нас
важно — то нужно использовать сессии и просто тупо класть туда объекты.

То есть чтобы getUsers не вызывался второй раз с запросом к базе, а
просто вщяли бы его из сессии.

И это вполне поддерживается Tapestry.

То есть предположим у тебя список. Ты нажимаешь
кнопку delete. Акция тайпестри будет: удалить
n-тый объект в списке. Все это сабмититься — типа
выбранный обект номер N. А в это время (то есть
после показа страницы списка, но до клика) ты
добавил запись в базу. И обана — Nтый объейкт стал
N+1вым. И для удаления тебе пришел не тот.

Простите, но если точно так же сделать без Tapestry — эффект будет
абсолютно такой же. Удалять надо не по номеру объекта, а по его ID
(который скорее всего есть PK в базе). И это прекрасно поддерживается.

Делается стандартно — колонка скрытых значений.

Идем дальше. Сам мехзанизм ревиндинга при ревинде
так же вызывает listeners всех компонентов. Там
все супер абстрактное и потому, если у тебя
например есть поле ввода потом кнопка, а потом еще
одно поле ввода — то листенер на кнопке вызоветься
_раньше_

Предполагается, что выставление значений компонентов не зависит от их
порядка на странице (что, в общем-то, логично). Если зависит, то
действительно нужно сделать несколько приседаний. В Tapestry 4 добавили
поддержку автоматического переупорядочивания на основе приоритетов.

Например — нет способа посмотреть все ошибки
валидации. Вот нет — это бесполезная функция, ну
как же, это же никогда никому не надо — есть токо
getFirstError.

public List getErrorRenderers()

Для getFirstError стоит комментарий "A convienience, as most pages just
show the first error on the page".

Для добавления ошибок нужно просто поставить состояние ошибки на
соответствующем поле. Можно и record'ом воспользоваться:

public void record(IFormComponent field, String message)

И что тут сложного?

Самым большим хитом стало знаей что? Интерференция
данных. И чем сложнее страницы тем более
несистематичная интерферениция — запускаешь на
свой сайт несолько пользователей и наблюдаешь как
все оно сыплеться без малейших признаков системы
или воспроизводимости.

Внутри Tapestry разделяемое состояние не хранится нигде. Рассогласование
данных вызывает ТОЛЬКО логика приложений.

В формах (page source) которые он генерит
встречаеться все что угодно вплоть до сериализованных объектов.

То что генерирут контролы. Генерировать они действительно могут что угодно.

То есть про простой
javascript можешь забыть. Хочешь чегото-там
confirm — приступай к way of tapestry — там для
этого надо всего 4 файла создать — шоб как
скриптовую компоненту оформить.

А кто мешает просто вывести JavaScript в рендерере? Правильно, никто не
мешает.

Дальше комментировать лень

Насколько я помню RU.JAVA, Владимир Кириченко использовал Tapestry
(точнее ругался на нее) где-то в 2003 году, а то и раньше. Тогда
некоторые из этих проблем действительно были (детские болезни
фреймворка, однако).

Сейчас на Tapestry построен http://tacos.sourceforge.net/ (включая
пресловутый AJAX) и другие проекты.

Posted via RSDN NNTP Server 2.0

	От:	Cyberax
	Дата:	13.02.06 19:40
	Оценка:

От:	IT	linq2db.com
Дата:	13.02.06 19:51
Оценка:

	От:	WolfHound
	Дата:	13.02.06 19:51
	Оценка:

От:	IT	linq2db.com
Дата:	13.02.06 20:16
Оценка:

	От:	WolfHound
	Дата:	13.02.06 20:24
	Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	14.02.06 11:55
Оценка:

	От:	Павел Кузнецов
	Дата:	14.02.06 16:04
	Оценка:	29 (2)

От:	McSeem2	http://www.antigrain.com
Дата:	14.02.06 19:19
Оценка:

От:	VladD2	www.nemerle.org
Дата:	14.02.06 22:50
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	15.02.06 00:33
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	15.02.06 05:18
Оценка:

	От:	CreatorCray
	Дата:	15.02.06 05:51
	Оценка:	+1 -1

От:	Курилка	http://kirya.narod.ru/
Дата:	15.02.06 09:15
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	15.02.06 10:48
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.02.06 15:25
Оценка:

	От:	Дьяченко Александр
	Дата:	15.02.06 17:33
	Оценка: