AndrewVK wrote: > Double check locking ты хотел сказать? Так с управляемыми средами здесь > даже проще — JIT может такой паттерн распознавать и генерить > потокобезопасный для целевой архитектуры код.
К сожалению, это только один из примеров неправильной работы.
Здравствуйте, Cyberax, Вы писали:
>> Double check locking ты хотел сказать? Так с управляемыми средами здесь >> даже проще — JIT может такой паттерн распознавать и генерить >> потокобезопасный для целевой архитектуры код. C>К сожалению, это только один из примеров неправильной работы.
Слив засчитан.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Cyberax, Вы писали:
>> В любом случае я не вижу причин реализовывать в железе то что прекрасно работает без железа. C>Блин! Ну _НЕ_ работает оно.
А сингулярити мне прислась? И .NET с жабой тоже не работают?
C>А вот я уверен в обратном. Более того, я уже именно это и сделал. C>Ускорение в 20% в одном из важнейших циклов (вейвлет-преобразование профиля поверхности) по сравнению с IC++ в режиме WPO. Динамическое профилирование почему-то дало результат на этом коде медленнее WPO.
Те интеловский компилятор в некоторых случаях генерирует код на 20% медленней идеала.
С виду гиганское преймущество.
Но с другой стороны
1)В подавляющем большинстве задач это ничто. К томуже скорей всего в подавляющем числе задач он сгенерирует идеальный код.
2)Оптимизаторы постоянно умнеют, а мы говорим о будущем.
3)Выкидывание всякой дури из процессора позволит поднять его производительность. И возможно больше чем на эти самые 20%
C>Точнее драконовских ограничений.
Каких?
Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо. То есть вобще никаких причин не вижу.
Присутствие ГЦ? Тоже честно говоря не понял чем оно тебя не устраивает. Ну да есть некоторый оверхед по памяти. Ну и что? Память сейчас дешовая. И будет еще дешевле(уж точно не дороже ибо несчего). Проблемы с памятью есть только в кристаллах но я и не предлагаю туда засовывать управляемые ОС.
Отсутствие возможности писать на асме? В одном из 1000 (а может и еще реже) случаев мы потеряем 20% производительности. А стоит ли оно того чтобы отказыватся от управляемых ОС? Я считаю что нет.
>> А чем ncNUMA отличается от cell? C>Cell — это только частный случай ncNUMA. Их достаточно много видов есть.
Дык эта дай ссылочку. А то гугль выдает какието ссылки на немецкие сайты, а я по немецки не понимаю.
C>А я говорю про большинство? Мне плевать, пусть хоть на VB пишут. Другое дело, что managed OS будут лишать меня возможности нормально писать на С++.
Я так и не понял зачем тебе писать на С++ если он всеравно на 20% медленней асма, а сравнивать производительность С++ и скажем C# не корректно ибо можно сравнивать только компиляторы.
>> А логи вам на что? C>Чего? Каждого действия?
Каждого исключения. Тем болие что это исключение было показано пользователю.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
CC>>Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют?? WH>Уж не намекаешь ли ты на то что у меня руки из ж растут? Ты конечно можешь считать как угодно но например brainbench считает что я знаю С++ лучше чем 99.9% проходивших этот тест...
WH>Хватит называть меня криворуким. Надоело уже
Так. Теперь все понятно. Ты просто ответы видимо читаешь через строку или вообще по диагонали...
Было написано следующее:
WH>Например у меня на машине "Vampire Masquerade — Bloodlines" просто падает при старте, а на другой работала... Причем винда свеже поставленная.
CC>А в чем тут вина неуправляемых языков? Попав молотком по пальцу ты ж молоток не винишь. Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??
Не знаю как для тебя, но для меня очевидно, что речь идет о криворуких разработчиках "Vampire Masquerade — Bloodlines", которая у тебя собственно и падает. Откуда ты выискал личный наезд непонятно, но сразу съехал на эмоции и начал тыкать брейнбенчем...
WH>Учитывая что определенный класс ошибок там просто не возможен то... CC>... криворукость прощать не стоит а потворствовать вообще нельзя... Но согласись, если какой то человек не способен писать на языке без ошибок а другие совершают эти ошибки на порядок меньше на том же языке то это не значит что язык плохой.
Опять непонятно с какого перепугу ты решил что речь о тебе? Где тут такое написано? Речь то шла о том, что если абстрактный программер пупкин совершает в языке Z какую то ошибку снова и снова то это означает что надо менять пупкина а не язык.
CC>>Вообще то если подумать, то оба языка выполняют машинный код на одном и том же процессоре. хъ WH>Во-во, а вы все скорость, скорость... Ты б хоть до конца прочитал, что ли...
WH>Но обижатся я не стану. Я выше этого.
Пардон, но смысла продолжать диалог я не вижу... Мы с тобой никогда правильно друг друга не поймем, поэтому лучше прекратить флуд пока до личностей дело не дошло...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndrewVK, Вы писали:
Д>>если он сейчас и работает, то это просто случайность. Документация настоятельно рекомендует не использовать DCLP.
AVK>И что предлагают взамен?
Здравствуйте, WolfHound, Вы писали:
WH>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
А я смогу. Более того, неоднократно писал.
Здравствуйте, Cyberax, Вы писали:
>> В любом случае я не вижу причин реализовывать в железе то что прекрасно работает без железа. C>Блин! Ну _НЕ_ работает оно.
Кстати как будут выглядеть таблици аппартоной защиты памяти для кода типа
template<class T>
struct G
{
T v1;
T arr[10];
T v2;
};
int main()
{
G<G<G<G<G<int> > > > > ggg;
}
Ы? Нужно защитить каждый массив причем это должно быть сделано типизированно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vvotan, Вы писали:
WH>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор. V>А я смогу. Более того, неоднократно писал.
И на сколько процентов? И стоят ли эти проценты уменьшения надежности все системы?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Блин! Ну _НЕ_ работает оно. > Кстати как будут выглядеть таблици аппартоной защиты памяти для кода типа > template<class T> > struct G > { > T v1; > T arr[10]; > T v2; > }; > int main() > { > G<G<G<G<G<int> > > > > ggg; > } > Ы? Нужно защитить каждый массив причем это должно быть сделано > типизированно.
Вы не понимаете — защищаются _сами_ указатели. То есть перезапись
указателя — это привиллегированая операция. Исход операции (успех или
trap) зависит от комбинации IP (Instruction Pointer) источника и
результата назначения.
То есть этот массив будет (скорее всего) расположен в памяти приложения,
и к нему будет иметь доступ только сам код приложения.
Здравствуйте, vvotan, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор. V>А я смогу. Более того, неоднократно писал.
Здравствуйте, WolfHound, Вы писали:
WH>>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор. V>>А я смогу. Более того, неоднократно писал. WH>И на сколько процентов? И стоят ли эти проценты уменьшения надежности все системы?
Боюсь наврать, так как последний раз занимался этим около года назад, но точно более чем вдвое.
Сразу скажу: задача — обработка изображения; основной выигрыш получился из-за: нормального использования SIMD, избавления от делений, замены условных переходов арифметикой во внутреннем цикле.
Насчет надежности — это была всего-лишь функция, принимающая массив байт на входе и записывающая выход в предварительно подсунутую память. Все размеры оговорены, падать чисто вычислительному коду не свойственно. Если оно что-то сделает не так — да и фиг с ним — будет у пользователя некрасивая картинка.
Я же не предлагаю все подряд на ассемблере писать
Здравствуйте, Cyberax, Вы писали:
C>То есть этот массив будет (скорее всего) расположен в памяти приложения, и к нему будет иметь доступ только сам код приложения.
Это ты не понимаешь. Нужно защищать именно от кода приложения. Те
template<class T>
struct G
{
T v1;
T arr[10];
T v2;
};
template<class T>
void Crush(G<T>& g)
{
for(int i = 0; i < 100; ++i)
Crush(g.arr[i]);
}
void Crush(int& i)
{
i = 0;
}
int main()
{
G<G<G<G<G<int> > > > > ggg;
}
Такой код не должен разрушить никакие данные. Любой выход за приделы массива должен приводить к исключению.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > Такой код не должен разрушить никакие данные. Любой выход за приделы > массива должен приводить к исключению.
Можно использовать "fat pointers" — то есть в указатель записывается еще
и длина адресуемого блока (так было и на AS/400).
Но это обычно никому не нужно, главное дать гарантию, что код
теоретически не сможет вырваться из своего sandbox'а. А для этого tagged
pointer'ов вполне хватает.
Здравствуйте, Cyberax, Вы писали:
C>Можно использовать "fat pointers" — то есть в указатель записывается еще и длина адресуемого блока (так было и на AS/400).
Те указатели в общем случае должны быть в два раза больше? В любом случае это не спасет от смещения указателя на пол размера структуры. Те нам понадобится еще и размер структуры. Те указатель должен быть в 3 раза больше... плюс куча транзисторов для проверки.
C>Но это обычно никому не нужно, главное дать гарантию, что код теоретически не сможет вырваться из своего sandbox'а. А для этого tagged pointer'ов вполне хватает. это нужно всем. Это надежность программы.
Короче я так и не понял зачем нужны все эти сложности на низком уровне если анализ проведенный на высоком уровне позволяет этого избежать?
Итого: Так и небыло предоставлено ни одного аргумента в пользу того что аппаратная защита памяти лучше программной. Наоборот было выявлена куча сложностей, а если делать по простому то у нас будут дыры в защите мелких объектов. К томуже всеравно кто-то должен формировать таблици.
Единственный аргумент в пользу нативного кода это возможность в некоторых случаях написать на ассмблере болие быстрый код. Но это тут есть три фактора
1)В подавляющем большинстве случаев компилятор генерирует оптимальный код.
2)Упрощение процессоров позволит поднять производительность процессоров.
3)Работы по совершенствованию оптимизаторов постоянно ведутся.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vvotan, Вы писали:
V>Сразу скажу: задача — обработка изображения; основной выигрыш получился из-за: нормального использования SIMD, избавления от делений, замены условных переходов арифметикой во внутреннем цикле.
Те алгоритмическими оптимизациями... классный способ опустить компилятор. V>Насчет надежности — это была всего-лишь функция, принимающая массив байт на входе и записывающая выход в предварительно подсунутую память. Все размеры оговорены, падать чисто вычислительному коду не свойственно. Если оно что-то сделает не так — да и фиг с ним — будет у пользователя некрасивая картинка.
Пользователь будет не доволен... Пользователь платит деньги... V>Я же не предлагаю все подряд на ассемблере писать
Ты нет, а вот Cyberax жить без С++ не может... А С++ не могим лучше ассемблера в плане надежности и статических проверок.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>Это не означает работу без GC и полноценное ручное управление памятью. C>>Это всего лишь означает неиспользование GC. WH>Те убирания кода ГЦ из процессе не означает не использование ГЦ? Очень интересно.
памятью все-равно нельзя управлять, можно будет лишь использовать "статические" массивы или стек.
Здравствуйте, vdimas, Вы писали:
V>памятью все-равно нельзя управлять, можно будет лишь использовать "статические" массивы или стек.
Для драйверов какихнибудь несложных девайсов этого может быть вполне достаточно. К томуже в сингулярити есть еще exchange heap на счетчиках ссылок... правда там есть ограничения на типы данных размещаемые в этой куче.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ты б хоть до конца прочитал, что ли... 
