Здравствуйте, 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>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 ?

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

S>По логике — да, только вот кто его знает.. Такие взрослые дядьки и не учитывают... Можно разгрузить обсчет графики за счет того что отдадим просчет звука кому нибудь, скажем видику, на приставке подготавливать полигоны и еще чтонибудь и отдавать подготовленные данные телевизору, который скажем ложит текстуры...
Это называется маркетинговый бред. Для того чтобы программа хорошо паралелилась ее архитектура должна быть на это расчитана. А если архитектура на это расчитана то cell'ы уже не обязательны.

S>Да все можно. Только вот переделать x86 xчтоы на кристалле можно было без особых переделок размещать нужное количество SPE (Синергический процессорный элемент) и станет похоже на Cell. Я хочу сказать что cell расширяем не только снаружи (2, 5, 8 камней) но и изнутри (по количеству SPE на кристалле), причем с минмальными затратами на переделку оборудования. Обратите внимание на расположение шины EIB (связывающей все в кучу) и SPE относительно её...
Читай это до просветления. Ребята загнали 8 процессоров и шину в один кристал и назвали это революцией...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".
Те ты просто взял плохой частный случай и обопщил его на все управляемый ОС? Это называется демагогия.

Здравствуйте, 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

Автор: c-smile
Дата: 06.02.06

читал?
Ща почитаю...

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>А я еще пофлеймю...
тогда не обижайся на отвечающих тебе...

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

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

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

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

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

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

Здравствуйте, 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>тогда не обижайся на отвечающих тебе...
Если ты думаешь что можешь меня обидеть... то ты глубоко ошибаешься.
Если ты конечно начнешь ругатся матом то я как модератор буду просто обязан тебя забанить и как минимум вырезать мат из твоих сообщений.
Но обижатся я не стану. Я выше этого.

Дарней,

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

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

IT wrote:
> C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
> абсолютно и полностью. С++ тоже плохо подходит, правда.
> О cell архитектурах на дешёвых линуксах я первый раз слышал ещё в 2001
> году. Сразу отнёсся к этой идее скептически, т.к. ещё в 1991 приходилось
> возиться с транспьютерами. Похоже что для таких архитектур не только C#
> и C++ не подходит.
Ну PS3 и Xbox2 переводит Cell'ы в ранг реальных продуктов. Учитывая
сегодняшнюю гонку числа ядер процессоров, явно всплывут идеи ncNUMA или
подобных извращений.

C# для них не подходит совершенно (так как появляется различие между
разными типами памяти, менее жесткая модель памяти и т.п). С++ подходит,
но плохо (руками за всем следить надо). Так что ждем появления новых языков.

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

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

> Вобщем управляемые среды и здесь таки должны рулить.
А смысл? Управляемость дает два преимущества:
1. Портируемость (не зависим от кодов процессора).
2. Возможную проверку корректности.
3. Динамическое исследование и модификация программы.

Первое преимущество для SPU не так важно, второе — на любителя
(аппаратная поддержка же есть). В теории, третее преимущество позволит
управляемой среде разбивать программу на куски и скармливать их в SPU.

Но текущая модель памяти CLR (однородной и бесконечной) этому как-то не
способствует.

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

Здравствуйте, 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-ого порядка.

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

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

Здравствуйте, 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"?

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&gt;
> прокомментировать можеш?
Запросто.

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) и другие проекты.

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

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

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

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

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

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

Здравствуйте, 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.

Полностью здесь.

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

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

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

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

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

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

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

WolfHound wrote:
> Вобщем С++ хороший язык... когдато был...
> А сейчас рулят ковровые клинья и танковые бомбандировки тфу ты
> управляемые среды, а дальше будут рулить упровляемые ОС типа Singularity
> для которых на С++ вобще писать будет довольно проблематично.
Да вы, батенька, оптимист.

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

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

WH>Кластер чтоли?

По-моему, это сейчас назвается что-то типа grid Впрочем, я могу путать.

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

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

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

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

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

Здравствуйте, 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)?
А зачем? Му тут филосовствуем или где? Мы рассуждаем о том что лучше навороченая железка которая занимается всякой ерундой типа контроля кто куда пишет или простая железка которая ничего не проверяет но весть софт который на ней крутится проверен до запуска, а там где статика не дает ответа вставлены проверки.

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

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

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


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

Здравствуйте, 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 нужен. А вот защита памяти врядли.

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

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

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

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

CC>К примеру: в той области где я на данный момент работаю (геймдев) 1 и 2 — критичные параметры.
Вот только не надо при мне говорить слово геймдев. Я не по наслишке знаю что это такое... Кстати The Next Mainstream Programming Language

Автор: c-smile
Дата: 06.02.06

читал?
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>впрочем хватит... развивать эту тему я не намерен. Все равно каждый останется при своем мнении.
А я еще пофлеймю...

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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)") и выводила красивое окошко с ошибкой о поврежденном файле.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь же именно о таком случае говорили видимо.

Здравствуйте, 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>Ту же идею можно попробовать применить к контролю чего угодно: и деления на ноль, и выхода за границы. Конечно, это несколько сложнее, т.к. операций, потенциально выводящих за пределы проверенного множества, значительно больше. Но принципиально это возможно.

Можно. Но не всегда и, ну, очень сложно! Хотя на то они и мечты о будущем.

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>Я это слышу уже лет... не знаю сколько.
> А я вижу что оптимизаторы с каждым новым релизом становятся умнее.
И все равно остаются внутренние циклы, дающие в разы больший прирост
скорости при переписывании на асме.

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

C>WolfHound wrote:
>> Вобщем С++ хороший язык... когдато был...
>> А сейчас рулят ковровые клинья и танковые бомбандировки тфу ты
>> управляемые среды, а дальше будут рулить упровляемые ОС типа Singularity
>> для которых на С++ вобще писать будет довольно проблематично.
C>Да вы, батенька, оптимист.

C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
C>абсолютно и полностью. С++ тоже плохо подходит, правда.
Есть специально заточенный под это дело язык программирования Оккам:
http://www.cluster.bsu.by/Kniga4/Chapter5.pdf

C# не может правилнь выполняться на многопроцессорных машинах. Он не поддерживает контролируемое распространение проверяемых (Checked) исключений и управляемую развёртку фреймов стэка в связи с этим (только крэш нити ).
Java (как и язык Eiffel, кстати) более приспособлена к такой работе, но там тоже есть свои трудности.

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

S>Таким образом, производительность отдельных Cell-устройств в сети может повышаться за счёт процессоров других устройств. Причём чипам безразлично, где находятся другие элементы сети: в одной комнате, доме, городе, или на другом континенте. Да и устройства, кстати, могут быть абсолютно разные: от уже упоминавшихся игровых консолей и телевизоров до персональных компьютеров, КПК и даже мобильных телефонов!
Господа явно лукавят.
1)Они не учитывают что связь между компьютерами по сравнению со связью внутри одного чипа просто фантастически медленная. По этому увеличения FPS при подключении cell'а из телевизора будет только если архитектуру игры заточить под это, а это не просто.
2)Для того чтобы собрать кластер процессоры не обязательно должны быть cell'ами. Это можно и на x86'ых прекрасно сделать.

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

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

Уважаемый, это происходит только в Вашем воображении...

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

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

О cell архитектурах на дешёвых линуксах я первый раз слышал ещё в 2001 году. Сразу отнёсся к этой идее скептически, т.к. ещё в 1991 приходилось возиться с транспьютерами. Похоже что для таких архитектур не только C# и C++ не подходит.

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

C>Да вы, батенька, оптимист.
Бывает.

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

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

WH>И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете лень.

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

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

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

WolfHound wrote:
> C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
> абсолютно и полностью. С++ тоже плохо подходит, правда.
> И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете
> лень.
Один центральный процессор и семь SPU (Sinergetic Processing Elements) —
простых процессоров без out-of-order execution, имеющих свою собственную
память (около 256Кб) и специальные наборы команд. То есть программа на
основном процессоре может взять какую-нибудь задачу и отправить ее на SPU.

Фишка в том, что SPU имеют доступ к основной памяти только через
достаточно медленный DMA.

IT wrote:
> Ничего особенного. Наращивание мощности путём добавления дешёвых
> элементов. Например, замена одного современного Windows сервера двумяста
> PII с линуксом.
Нет! SPU в Cell предназначены для разгрузки основного процессора от
утилитных задач и не могут быть использованы в качестве основного
процессора.

При этом затраты на управление по сравнению с SMP — минимальны, так как
SPU не имеет прямого доступа в основную память.

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

C>Один центральный процессор и семь SPU (Sinergetic Processing Elements) — простых процессоров без out-of-order execution, имеющих свою собственную память (около 256Кб) и специальные наборы команд. То есть программа на основном процессоре может взять какую-нибудь задачу и отправить ее на SPU.
Нашол какуюто статью но там както все мутно написано.
Я так понял что программа должна подготовить данные и код для SPU, а он очень быстро этот код с этими данными будет выполнять?

WolfHound wrote:
> Нашол какуюто статью но там както все мутно написано.
> Я так понял что программа должна подготовить данные и код для SPU, а он
> очень быстро этот код с этими данными будет выполнять?
Примерно так, хотя выполнять он может и совсем не быстро.

Дарней wrote:
> C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
> C>абсолютно и полностью. С++ тоже плохо подходит, правда.
> подозреваю, что как раз там будут рулить ФЯ
> по крайней мере, функции без сторонних эффектов и лямбда-функции вполне
> этому способствуют
А еще функции должны работать только с ограниченым по размеру
окружением. И без всякого GC — он в 256Кб не поместится.

Так что С++ все же в более выгодном положении.

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

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

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

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

C>А еще функции должны работать только с ограниченым по размеру
C>окружением. И без всякого GC — он в 256Кб не поместится.

В 64 поместился, а в 256 никак?

Andrei N.Sobchuck wrote:
> C>А еще функции должны работать только с ограниченым по размеру
> C>окружением. И без всякого GC — он в 256Кб не поместится.
> В 64 поместился <http://www.esmertec.com/solutions/M2M/OSVM/specs.shtml&gt;, а в 256 никак?
Ага. Учитывая, что в этих процессорах выполняется не интерпретируемый
код, а быстрый скомпилированый.

Ничего кроме простенького mark&sweep в такие рамки положить не
получится, а от него мало толку будет.

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

C>Ничего кроме простенького mark&sweep в такие рамки положить не
C>получится, а от него мало толку будет.

Ладно ладно. Спорить не буду. А у тебя есть, что сказать про compile time GC (O'Caml)?

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

C>А еще функции должны работать только с ограниченым по размеру
C>окружением.

это уже забота ВМ

C>И без всякого GC — он в 256Кб не поместится.

как насчет region inference?

C>Так что С++ все же в более выгодном положении.

Делать все вручную?

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

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

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

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

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 — но там нет верификатора (точнее не было,
когда я в последний раз смотрел).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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".

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

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

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

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

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

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

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

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

Здравствуйте, 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>без арифметики указателей и возможности спуститься на уровень ассемблера.
А зачем тебе это надо я так и не понял. Объясни пожалуйста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Next Mainstream Programming Language

Автор: c-smile
Дата: 06.02.06

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

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

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

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

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

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

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

Почему нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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&amp;only=1

Автор: Cyberax
Дата: 19.07.05

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

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

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

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

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

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

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

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

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

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

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

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

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

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

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

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

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

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

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

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

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

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

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

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

ПК>

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 удовлетворяет (или позволяет удовлетворить) большинству критериев перечисленных в презентахе. Языков удовлетворяющих в большей степени я попросту не знаю. У того же Хаскеля сам автор назвал кучу проблемных мест.

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

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

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

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

Здравствуйте, 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". Ситуации где без исключений совсем не обойтись в это не входят.

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