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

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

C>Нудно: "Затем что 'высокоуровневый' анализ накладывает слишком много ограничений". Тем более, что tagged pointer'ы — это давно испробованый и надежный вариант. Для его использования даже модули памяти не надо менять — можно использовать бит четности для тэга.
Я не считаю что это принципиальные ограничения. Те ограничения которые не дают возможность работать.

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

>> 2)Упрощение процессоров позволит поднять производительность процессоров.
C>Небольшое упрощение.
Если делать защиту в полный рост то большое.

>> 3)Работы по совершенствованию оптимизаторов постоянно ведутся.
C>Я это слышу уже лет... не знаю сколько.
А я вижу что оптимизаторы с каждым новым релизом становятся умнее.

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

C>И зачем мне забоксированый value-тип?
Скажем для того чтобы использовать этот value тип в генерике у которого в констрейнтах прописан этот интерфейс. В данном случае не точто боксинга не будет, а компилятор просто заинлайнит все что можно.
К томуже ты пляшешь от решения... в то время как надо работать от задачи.
К томуже ты опять пристал к .NET'у в то время как мы тут обсуждаем процессоры вобще и управляемые ОС вобще.

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

VD>Не реально, так как в общем случае данные могут появляться динамически и прийдется их контролировать в рантайме. При этом прийдетя вводить нечто воде небезопасных приведений типов.
Неа. Точнее, да, придется, но такие приведения будут вполне безопасными и редкими. Вот, к примеру, джиту дотнета не надо каждый раз в рантайме проверять, что объект на вершине стека имеет нужный тип для выполнения следующего вызова. Потому, что тип объекта можно проверить статически — если на стеке лежит параметр текущего метода, и параметр имеет нужный тип, то все в порядке. Проверка того, что нам не передали объект неверного типа, выполнена снаружи метода.
Ок, где-то вверху по стеку вызовов это был просто object, про который статически ничего неизвестно. Для того, чтобы удовлетворить верификатор, мы будем обязаны явно поставить cast. Этот cast таки будет выполняться в рантайме, медленно и печально. Но! Как только он прошел, объект можно уже не проверять. А внутри "безопасных границ" может выполняться очень много обращений к этому объекту.

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

WolfHound wrote:
> C>И зачем мне забоксированый value-тип?
> Скажем для того чтобы использовать этот value тип в генерике у которого
> в констрейнтах прописан этот интерфейс. В данном случае не точто
> боксинга не будет, а компилятор просто заинлайнит все что можно.
> К томуже ты пляшешь от решения... в то время как надо работать от задачи.
> К томуже ты опять пристал к .NET'у в то время как мы тут обсуждаем
> процессоры вобще и управляемые ОС вобще.
Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы
или быть наследником абстрактного класса при программном контроле.

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

C>Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы или быть наследником абстрактного класса при программном контроле.
Учите матчасть.

WolfHound wrote:
> C>Value-тип без боксинга _в_ _принципе_ не может реализовать интерфейсы
> или быть наследником абстрактного класса при программном контроле.
> Учите матчасть.
Прекрасно. Тогда расскажите как управляемая среда будет разруливать
такой код:

public static IComparable comp_;

void setComparable(IComparable comp)
{
    comp_=comp;
}

...
struct SomeValueType : IComparable
{
...
}

void someFunc()
{
SomeValueType tp; //Живет до конца стека

setComparable(tp); //Передаем в виде интерфейса. Время жизни: ???
}

Управляемая среда обязана перераспределить объект SomeValueType в
динамической памяти (иначе после выхода из someFunc в comp_ будет
висящий указатель). Что собственно сводит на "нет" возможность
использования value-типов для замены автоматических объектов.

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

C>Прекрасно. Тогда расскажите как управляемая среда будет разруливать
В таком коде никакого боксинга не будет

        struct Test : IComparer
        {
            public int Compare(object x, object y)
            {
                return ((IComparable)x).CompareTo(y);
            }
        }
        static void ByValue<T>(T asd)
            where T : IComparer
        {
        }
        static void ByRef<T>(ref T asd)
            where T : IComparer
        {
        }
        static void Main()
        {
            Test t = new Test();
            ByValue(t);
            ByRef(ref t);

C>такой код:
C>Управляемая среда обязана перераспределить объект SomeValueType в динамической памяти (иначе после выхода из someFunc в comp_ будет висящий указатель).
В таком коде действительно будет боксинг. Но это не мешает структурам реализовывать интерфейсы и при этом обходится без боксинга.

C>Что собственно сводит на "нет" возможность использования value-типов для замены автоматических объектов.
Приведи аналог этого кода на С++

WolfHound wrote:
> C>Прекрасно. Тогда расскажите как управляемая среда будет разруливать
> В таком коде никакого боксинга не будет
Я и не говорил, что он будет _всегда_.

> В таком коде действительно будет боксинг. Но это не мешает структурам
> реализовывать интерфейсы и при этом обходится без боксинга.
Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для
проверки совместимости для generic'ов или проверок типов.

Но не для виртуальных вызовов.

> C>Что собственно сводит на "нет" возможность использования value-типов
> для замены автоматических объектов.
> Приведи аналог этого кода на С++
Я сразу буду распределять объект в куче. Либо еще можно делать так:

struct Base
{
    virtual ~Base(){};
    virtual void someMethod()=0;
};
Base *theBaseObject=NULL;
void setBase(Base *obj) {theBaseObject=obj;}

struct SomeType : public Base
{
    int val;
    virtual void someMethod(){blah();}
};

void someFunc()
{
    SomeType tp;
    setBase(&tp);
    ON_BLOCK_EXIT(&setBase,NULL);

    ...
}

То есть я _могу_ записать указатель на автоматический объект в
глобальной переменной без накладных затрат.

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

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

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

C>Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для проверки совместимости для generic'ов или проверок типов.
C>Но не для виртуальных вызовов.
А зачем? value типы используются при оптимизации чего либо. Если оптимизировать ничего то надо использовать reference типы.
Скажем когда я писал бинарный diff мне нужно было оперировать десятками миллионов объектов. В этом случае я использовал value типы ибо столько ссылочных объектов на ровном месте не оправданная нагрузка на ГЦ. Также я ручками написал хеш таблицу ибо та что в фреймворке меня не устраивала.
А если мне не нужно оптимизировать то я о value типах даже не думаю.

C>Я сразу буду распределять объект в куче.
В таком случае сразу создаешь reference тип и никаких проблем.
C>Либо еще можно делать так:
хъ
C>То есть я _могу_ записать указатель на автоматический объект в глобальной переменной без накладных затрат.
А вот за такой код я оторву руки ибо это не надежно даже по С++ным меркам.
Короче ты опять пытаешься привести решение которое плохо варажается на C# но о том что ту задачу которую ты хочешь решить можно решить банально иначе почемуто не задумываешься.
Пойми одну простую вешь: В С++ выгодно использовать одни паттерны в C# другие. И не надо пытатся делать выводы на основании что те паттерны к которым ты привык работают плохо ибо есть другие.
Короче хватит приводить решения. Давай задачу.

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>В Vista будет такой механизм, а в FreeBSD уже многие годы есть система
C>jail-ов (каждую программу можно "посадить" в тюрьму с контролируемым
C>окружением). И это учитывая не особую приспособленность x86 для
C>виртуализации.

Я не знаю, будет ли в Vista что либо новое в OS (а не в UI). В Windows уже давно существует понятие Job. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/job_objects.asp. Насколько я понимаю, это примерно эквивалентно freebsd jail.

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

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

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

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

alexeiz wrote:
> Я не знаю, будет ли в Vista что либо новое в OS (а не в UI). В Windows
> уже давно существует понятие Job.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/job_objects.asp.
> Насколько я понимаю, это примерно эквивалентно freebsd jail.
Не совсем. Программа в jail'е видит только свою файловую систему и
только свои процессы. Почти что отдельный компьютер получается.

WolfHound wrote:
> C>Они бесполезны как _интерфейсы_. Точнее, они могут использоваться для
> проверки совместимости для generic'ов или проверок типов.
> C>Но не для виртуальных вызовов.
> А зачем? value типы используются при оптимизации чего либо. Если
> оптимизировать ничего то надо использовать reference типы.
Оптимизировать нужно _все_ — то есть сразу писать нормальный код. В С++
автоматические типы вводятся неинтрузивно, в отличие от .NET.

> C>То есть я _могу_ записать указатель на автоматический объект в
> глобальной переменной без накладных затрат.
> А вот за такой код я оторву руки ибо это не надежно даже по С++ным меркам.
Согласен, привел первый пример, который пришел в голову. Самое главное,
что я хотел проиллюстрировать — использование виртуальных вызовов (через
виртуальный базовый тип) на value-типах не возможно.

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

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

C>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
Нет таких задач где надо оптимизировать 100% кода. Нету!
C>В С++ автоматические типы вводятся неинтрузивно, в отличие от .NET.
Для оптимизации болие чем хватает. А когда оптимизировать не надо то reference типов вполне достаточно.
А вобще в моей практике даже когда я писал не С++ всегда существовало четкое разделение на value и reference типы. Те один и тотже класс использовался либо только как value тип либо только как reference.

C>Согласен, привел первый пример, который пришел в голову. Самое главное, что я хотел проиллюстрировать — использование виртуальных вызовов (через виртуальный базовый тип) на value-типах не возможно.
А зачем? Чесно говоря я не вижу задач для чего это нужно.

C>Иногда для оптимальных решений на С++ просто нет аналога в C#.
Например? Я не обещаю решения на C# ибо .NET довольно бедная VM но мы тут говорим об управляемых средах вобще.

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

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

C>В Vista будет такой механизм, а в FreeBSD уже многие годы есть система jail-ов (каждую программу можно "посадить" в тюрьму с контролируемым окружением). И это учитывая не особую приспособленность x86 для виртуализации.
Защиты программы от самой себя? Не смешите мои тапочки... Это не x86 не реально. Разве что только в том случае если поверх x86 работает управляемая система.

C>Просто это никому не нужно.
И .NET с жабой тоже никому не нужны?

C>Я считаю. Даже в Windows или FreeBSD c jail'ом я могу при желании спуститься на уровень железа (с соответствующим контролем доступа к критичным ресурсам типа обработки прерываний).
А зачем?

C>Managed-OSы лишат меня этой возможности ради того, чтобы программы криворуких малограмотных программистов работали "надежно". Нафиг это нужно мне?
Проблема в том что это гдето 99.999999% программистов...
C>Со мной согласны game-developer'ы и даже сам MS, который продолжает писать свои продукты на unmanaged-языках.
Про МС с геймдевом вобще не заикайся. И тех и других нужно пересадить в управляемую среду. Ты например знаешь что XBox 360 постоянно сваливается в синий экран?
Я работал в одной из крупнейших контор по производству игр в России... так вот я очень хорощо знаю как пишут игры... Там постоянно ловили то порчу памяти то утечку... а какая там архитектура... И я видел код нескольких контор... везде одно и тоже...
Я лучше помолчу, а то придется самого себя забанить.

C>Да? А игры/
Про игры я уже сказал.
C>вычислительный софт/
Вот только его все чаще и чаще пишут на жабе... ибо нужно не только вычислить но еще и написать сложный вычислительный алгоритм...
C>"тяжелый" софт и т.п.? И это совсем не маленький сегмент.
Что такое тяжолый софт?

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

void DoSome(byte[] bytes, float[] floats)
{
    asm
    {
        ...
    }
}

Ибо нам нужно доказать лишь то что ну будет произведено чтение/запись за приделы массивов.
А операции с адресами как правило не такие уж хитрые.

C>Где? MMU все равно нужен, а сегодняшняя защита на x86 фактически и состоит только из MMU.
И мы имеем кучу софта который падает на ровном месте... А контроль всего и вся в железе потребует очень больших дополнительных затрат памяти.

C>Tagged pointer'ы тоже реализуются абсолютно тривиально.
Вот только толку от них...
C>И при этом tagged pointer'ы позволяют переиспользовать с небольшими изменениями почти весь существующий софт.
Существующий софт можно запускать на современном железе в отдельном процессе... ибо никто не мешает управляемой ОС создавать не управляемые процессы в отдельном адрессном пространстве.

C>И все равно остаются внутренние циклы, дающие в разы больший прирост скорости при переписывании на асме.
Ну в разы это ты ивно загнул. У тебя получилось 25%, тут в этой ветке приводили пример в 2 раза но там как выяснилось еще и алгоритм поправили...

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

ZEN>Есть специально заточенный под это дело язык программирования Оккам:
ZEN>http://www.cluster.bsu.by/Kniga4/Chapter5.pdf
Интересное чтиво. В принципе Оккам можно применять в качестве ассемблера для ВМ. Далие это все оптимизируется под конкретную архитектуру машины.
Скажем такой код

for(int i = 0; i < n; ++i)
{
    vertexes[i] = vertexes[i] * matrix;
}

на логичеком уровне будет порождать n паралельных процессов. Но скажем если это дело запустить на какомнибудь cell'е то оптимизатор разобьет это дело на 7 групп процессов. Далие каждая группа будет превращена в один процесс работающей над частью массива. После чего эти процессы будут раскиданы по SPU.

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

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

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

напомнило байку про Commodore C64. У этих компьютеров был очень занятный дисковод. Настолько занятный, что некоторые программы отказывались запускаться на машинах без дисковода. Не грузится, а именно запускаться. А дело было в том, что контроллер дисковода по мощности не уступал самому компьютеру. Такой же точно процессор, и что-то порядка 64 кб памяти (а это очень не мало для конца 80-х). И есс-но ушлые программисты того времени не могли пройти равнодушным мимо такого чудо-дисковода. По-быстренькому совали в контроллер свой код, и дисковод очень здорово обсчитывал графику в играх (или демках). Праотец CELL'а так сказать был...

Впрочем наши тоже изобретали нечто подобное. Как известно, ZX-Spectrum обладал 3.5mhz процессором Z-80 (команды с опкодами 243, 118 кто-нить ещё помнит ? ) и физически не мог играть оцифрованный звук паралелльно с исполнением кода приложения. (Стоит упомянуть о разных ухищрениях, когда исполнение кода просчитывается так, что можно вырвать десяток-другой тактов процессора, и немножечно "порисовать" ценой этих тактов, что вызывало плохенькую, но иллюзию параллельной игры оцифровки. Первым был, если не ошибаюсь, гениальный харьковский программист с ником RST-7. Дмитрий. Фамилии уже не помню).
Так вот, питерские ребята соорудили девайс с именем General sound, который имел 128кб памяти, и ещё один Z-80. Компы с этим девайсом уже могли играть в фоне оцифровки и их тоже пользовали ушлые программеры для исполнения обычного кода. Правда general sound это вам не штатный дисковод, широкого распространения он не получил...

Ээээх ностальгия! А ведь чем не CELL ?

Здравствуйте, Cyberax, Вы писали:
C>Оптимизировать нужно _все_ — то есть сразу писать нормальный код.
Еще один поклонник оптимизаций. Нормальный код в большинстве типичных приложений написать сразу невозможно. Потому что оценивать нагрузку на код заранее слишком сложно.
Так что честные люди пользуются для оптимизации профайлером, а не C++. Я не спорю, некоторые вещи до сих пор нужно писать на ассемблере (хотя в жизни я таких примеров не встречал. А вот горе-оптимизаторов, которые писали более красивый, но медленный код под x86, чем генерит VC++ — встречал.). Но к счастью их мало.
C>Согласен, привел первый пример, который пришел в голову. Самое главное,
C>что я хотел проиллюстрировать — использование виртуальных вызовов (через
C>виртуальный базовый тип) на value-типах не возможно.
Все возможно. В тех случаях, когда компилятор/джит может проверить тип статически, никакого боксинга не происходит. В тех случаях, когда ты бы стал выделять память в куче, дотнет тоже выделит память в куче.