Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, Cyberax, Вы писали:
C>>>Точно так думали создатели Itanium'а — подсказать чем все закончилось?
Ш>>Вот здесь ты не совсем прав. Кроме провального Itanium а есть ведь ещё вполне успешная 6000 серия TMS ов.
К>Плюс Интел и ХП в этом году 10 миллиардов в ракскрутку его планируют вложить, так что может что и изменится
Всё может быть. Может, для десктопов время такого сорта процессоров ещё просто не пришло.
Я бы не ставил окончательный крест на этом направлении.
Тут правда есть опасность не вписаться в time-frame. Т.е. появятся новые процессорные архитектуры, которые обесценят текущие. То же Cell От IBM или собственные Интеловские многоголовки.
Здравствуйте, 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. Трудности возникнут, когда скажем
Но в таких случаях и ИЯ не помогут. Нужен другой алгоритм.
These languages reintroduce mutable state for reasons of expressibility and efficiency. In a purely functional language, aggregate data structures, such as arrays or trees, are updated by producing a copy containing a modified value. This technique is semantically attractive but can be terrible for performance (linear algorithms easily become quadratic).
Однако не забываем, что анализ — штука важная, и во многих случаях будет тот же mutable state, только за шторками. Поясню:
A1 = modify(A0).
Если A0 ниже нигде не используется, то многие современные ФЯ (если не все) просто делают модификацию A0.
Если используется и A0, и A1, то можно предложить целую кучу путей:
1. Хранить и A0, и A1, для ссылки A0 использовать A0, для A1 -> A1
2. Хранить A0, и diff(A0,A1), для ссылки A0 использовать A0, для A1 - вычисление A0 + diff
3. То же самое, что и 2, только хранить A1.
4. Хранить некий промежуточный A_, diff(A0, A_), diff(A1, A_);
A0 -> A_ + diff(A0, A_), A1 -> A_ + diff(A1, A_)
Так что с эффективностью не всё так просто: теоретических проблем для оптимизации нет, нужны только практические воплощения идей.
Кроме того не стоит забывать, что введение mutable state хоть и сохранит O(n^m), но может подавить возможность параллелизации. (Возможно обратное тоже верно, но я как-то пример не могу вообразить сходу).
In addition, functional updates do nothing to discourage the writing of a strictly sequential algorithm, in which each operation waits until the previous operation updates the program’s state.
Да, конечно, (я говорил об этом выше). Что вообще предлагается делать в этом случае (ИЯ, ФЯ — неважно)?
ПК>Не везде. Предлагаемый Саттером Concur, похоже, позволит распараллелиливать вычисления более успешно.
Ну чтож:
* define higher-level abstractions (above "threads and locks")
* for today’s imperative languages (examples are in C++)
* that evenly support the range of concurrency granularities
* to let developers write correct and efficient concurrent applications
* with lots of latent parallelism (and not lots of latent bugs)
* that can be efficiently mapped to the user’s hardware to reenable the free lunch.
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> C>А еще функции должны работать только с ограниченым по размеру >> окружением. И без всякого GC — он в 256Кб не поместится. >> Функциональные вычисления очень хорошо поддаются автоматическому >> разбиению на части если это вобще возможно для выбранного алгоритма. C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это C>неприемлимо.
Это не так. Весь memory management может делаться на этапе компиляции. Кажется
MLTon это умеет.
Здравствуйте, CreatorCray, Вы писали:
VD>>Темболее, что там скорее по описанию Nemerle подходит, а не Шарп. Шарп там как альтернатива совсем уж устаревшему С++ используется и то половине требуований не удовлетворяет. Хотя часть требований там откровенно нереальна. Статическая сежфункциональная проверка индексов в компайл-тайме — это знаете ли без травы не прокатит. CC>Бездоказательно, дорогой Ватсон, бездоказательно...
У тебя огромные проблемы с логикой. Я ничего не утверждал. Я высказал свое мнение. Высказал свои предпосылки. Доказывать тебе что-то я и не собирался.
Я спросил:
Почему нет?
И ответа не получил. Вместо этого плучил рассуждения о бездакозательности чего-то.
CC>В статье, такого вывода сделано не было.
В презентахе вообще небыло выводов. В презентахе было мнение о том, что ее автор хочет видеть в некоем гипотетическом идеальном для него языке.
CC> Т.е. вы мне сейчас опять лепите сферического коня по принципу "можно сделать".
Кто такие мы? Я здесь один.
И не надо этих эпититов "лепите". Учись переживать когда чужое мнение не совпадает с твоим.
CC>А из статьи выходит что: CC>
CC>Three Kinds of Code: Revisited
CC> Game Numeric Shading
CC> Simulation Computation
CC>Languages C++, Scripting C++ CG, HLSL
CC>CPU Budget 10% 90% n/a
CC>Lines of Code 250,000 250,000 10,000
CC>FPU Usage 0.5 GFLOPS 5 GFLOPS 500 GFLOPS
CC>Parallelism Software Implicit Implicit Data
CC> Transactiona Thread Parallelism
CC> l Memory Parallelism
CC>полностью переходить тот же Свини не предлагает и вообще не рассматривает.
Хм. Процитировал первый попашийся абзац и сделал далеко идущие выводы. Ты жту призентаху посмотри внимательнее. Тогда заметишь, что она посвящена рассуждениям о том, что нужен новый язык и что в этом языке должно быть. С++ в качестве прототипа такого языка принципиально не рассматривается, так как уже не удовлетворяет большинству критериев.
В статье реально упомянуты два языка — C# как варинт типобезопасного языка решающего 50% стояхищ проблем, и Хаскель как язык содержащий решение, по мнению автора, для остальных 50%.
CC>Да и вообще вся статья смахивает на размышлизмы "что будет когда будет": CC>CPU’s with: CC>– 20+ cores CC>– 80+ hardware threads CC>– >1 TFLOP of computing power
Вообще-то статья посвящена размышлениям о том какой язык нужен в будущем. А цифры — это предпологаемые мощьности процессоров в этом самом ближайшем будущем. По крайней мере я это так понял.
VD>>Но если устранить нереальные требования, то то Nemerle с доработкой напильником (читай маросами) проходит на ура. CC>И наверное совсем уж "нереальным" требованием является "Performance – Language Implications: The Java/C# “exceptions everywhere” model should be wholly abandoned"?
Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции. Хотя конечно отказ от исключений тоже нереален. Как минимум потому, что если нельзя контролировать вызод за еределы массивов в компайлтайме, то прийдется генерировать исключения в случае чего. Ну, и деление на 0 тоже никто не отменял. Его тоже полностью исключить нельзя.
Так что в общем случае олный отказ от исключений это утопия. Другое дело, что доведение фрэймворка и язык до состояния в котором рантайм-ошибки минимальны вполне возможно.
В любом случае Nemerle удовлетворяет (или позволяет удовлетворить) большинству критериев перечисленных в презентахе. Языков удовлетворяющих в большей степени я попросту не знаю. У того же Хаскеля сам автор назвал кучу проблемных мест.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
WinniePoh wrote: > C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это > C>неприемлимо. > Это не так. Весь memory management может делаться на этапе компиляции. > Кажется MLTon это умеет.
Ага, конечно. Почитайте про region inference.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, WinniePoh, Вы писали:
WP>> Особо сильно они способствуют высокой производительности! WP>> Самому не смешно, а?
Д>отличная иллюстрация к соседней теме, где обуждается невежество менеджмента
Да стебусь я, стебусь. Про Clean знаю, и про MLTon.
Только все равно лямбда это вовсе не тот уровнеь абстракции который нужен в том классе задач под
которые заточен CELL.
Здравствуйте, VladD2, Вы писали:
VD>Я спросил: VD>
Почему нет?
VD>И ответа не получил.
А получил фактически встречный вопрос: почему да? и зачем?
VD>Вместо этого плучил рассуждения о бездакозательности чего-то.
Итак: CC>>Но не весь же движок на шарпе писать! VD>Почему нет? CC>>Бездоказательно...
По мне так ежу понятно что в вопросах производительности на данный момент при сравнении с C++ у шарпа не все в шоколаде. Поэтому все же интересно, как VD собирается аргументировать смысл переписывания всего движка игры,причем Unreal3, о котором шла речь у Свини, с его прожорливостью к ресурсам, с C++ на С#.
Переписать часть — можно и возможно даже нужно. Но переписывать всё... без комментариев.
VD>В презентахе вообще небыло выводов. В презентахе было мнение о том, что ее автор хочет видеть в некоем гипотетическом идеальном для него языке.
И для чего именно этот язык он собирался применять?
CC>> Т.е. вы мне сейчас опять лепите сферического коня по принципу "можно сделать". VD>Кто такие мы? Я здесь один.
хорошо — ты. VD>И не надо этих эпититов "лепите". Учись переживать когда чужое мнение не совпадает с твоим.
без комментариев
VD>Хм. Процитировал первый попашийся абзац и сделал далеко идущие выводы. Ты жту призентаху посмотри внимательнее. Тогда заметишь, что она посвящена рассуждениям о том, что нужен новый язык и что в этом языке должно быть. С++ в качестве прототипа такого языка принципиально не рассматривается, так как уже не удовлетворяет большинству критериев. VD>Вообще-то статья посвящена размышлениям о том какой язык нужен в будущем. А цифры — это предпологаемые мощьности процессоров в этом самом ближайшем будущем. По крайней мере я это так понял.
А как я понял так этот новый язык и не рассматривался как основной а скорее как замена той части, что написана у Свини на скриптовом. Те самые 10% Simulation.
Допускаю что мог ошибиться. В таком случае прошу указать из чего в статье можно судить о планах глобального применения этого языка.
CC>>И наверное совсем уж "нереальным" требованием является "Performance – Language Implications: The Java/C# “exceptions everywhere” model should be wholly abandoned"? VD>Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции. Хотя конечно отказ от исключений тоже нереален. Как минимум потому, что если нельзя контролировать вызод за еределы массивов в компайлтайме, то прийдется генерировать исключения в случае чего. Ну, и деление на 0 тоже никто не отменял. Его тоже полностью исключить нельзя.
Речь шла конкретно об "exceptions everywhere". Ситуации где без исключений совсем не обойтись в это не входят.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Читай внимательнее:...
И тебе того же:
The real contribution of functional languages to concurrency comes in the higher-level programming style commonly employed in these languages, in which operations such as map or map-reduce apply computations to all elements of an aggregate data structure. These higher-level operations are rich sources of concurrency. This style of programming, fortunately, is not inherently tied to functional languages, but is valuable in imperative programs.
ПК>См. выше. Эту статью Саттер упомянул в контексте обсуждения своего проекта Concur
Дык надо же ему обосновать приемущество своих идей над чужими?
Это банальный пиар. Вот когда он сделает реальное решение и большая часть людей признает его лучшим, то и поговорим на счет врености подобных утверждений.
Характерно то, что даже его утверждения как бы косвенно подтверждают, что таки ФЯ имет большой задел в области паралеллизма.
Это я слышал от многих людей занимающихся параллелизмом. В том числе и Фаеновым из МС.
VD>> Это просто указания на возможные пробелмы. Такие проблемы есть везде.
ПК>Не везде. Предлагаемый Саттером Concur, похоже, позволит распараллелиливать вычисления более успешно.
"похоже..." это не аргумент. Не он один работает над данными проблемами, и не факт, что его решение будет лучше других.
В конце концов в области параллелизма есть не так много идей. Я бы сказал три:
1. Избавиться от побочных эффектов в вычисленихя и распараллеливать их.
2. Привязывать объекты или другие сущьности к одному потоку и организовывать общение между такими объектами по средствам сериализованных сообщений.
3. Жить по старинке на блокировках и ручном распараллеливании.
Очевидно, что исследования будут идти только в первых областях.
VD>> твои ссылки на наличие побочных эффектов в ФЯ просто смехотворны. Они конечно где-то может и есть, но это не соизмеримо с тем количеством побочных эффектов которые есть в ИЯ.
ПК>Тут дело не в количестве побочных эффектов, а в их наличии. Статья обращает внимание на принципиальную проблему: если нет побочных эффектов, то ряд алгоритмов принципиально замедляется (линейные превращаются в квадратичные и т.п.), если побочные эффекты есть, то автоматическое распараллеливание не работает.
Ну, это вообще проблема ФЯ. Однако многие задачи решаются в функциональном стиле довольно эффективно. В общем, это философия. Реальные решения скорее всего будут неким компромисом. Там где эффективно вычислительное распараллеливание будет применяться оно. Там где выгодно выделять отдельные логические блоки живущие независимо будут применяться идеи активных объектов/микропроцессов.
Ну, а где-то будут по старинке использоваться блокировки.
VD>>Да, и когда читаешь высказывания то не забывай делать скидку на то какой лагерь представляет человек.
ПК>Может, хватит в политику играть? Concur планируется сделать доступным и из C# в том числе.
Какая политика? Мне плевать кто куда что пытается встроить. В Nemerle уже встроена поддержка параллелизма аналогичная СиОмеговской. И что?
Я обсуждаю высказвания идей. Выделяю при этом здравые мысли и слова говорящиеся под влиянием корысных интересов. Только и всего.
Мне млевать кто их говорит. Мне важна суть. Я отчасти согласен с Саттером, а от части нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>У x86 уже GC выискался? Я что-то пропустил?
А в управеляемой ОС обязательно должен быть ГЦ? Или я что-то пропустил?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Павел Кузнецов, Вы писали:
WH>>ГЦ штука такая что будет жрать память пока дают. Те если у тебя много памяти то ГЦ сожрет много памяти, а если мало то мало. ПК>А если процессов с GC много, то как они память между собой делят?
Точные механизмы как это происходит сейчас я не знаю. Но мы эксперементировали запустив довольно навороченный сервер приложений и смартклиент в виртуальной машине с 64М памяти и отключеным свопом... оно конечно тормозило но работало. Причем в таскменеджере было видно как память перетекает от сервера приложений к смартклиенту и обратно в зависимости от того кто работает.
И это происходило в WinXP. А в управляемой ОС можно сделать координацию мусорщиков на всю катушку. Так что я тут вобще не вижу проблем.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Давайте рассатвим все точки над Ё. Мы находимся в форуме "Философия программирования" и философствуем от программирование. Мне в данный момент не интересно что происходит сейчас. Мне интересно что будет дальше. Как и почему это может выглядить. По этому я не буду ограничивать себя распространенными промышленными системами.
Кстати раз ты начал приводить аналогии и разводить демагогию то чтож... кто не спрятался я не виноват...
CC>А в чем тут вина неуправляемых языков? Попав молотком по пальцу ты ж молоток не винишь.
А зачем не использовать простой молоток если я могу взять пневматический и получить прирост производительности забивания гвоздей и гарантию того что не отобью себе пальци? CC>Если у разработчиков руки из жо то при чем тут инструментарий, которым они пользоваться не умеют??
Уж не намекаешь ли ты на то что у меня руки из ж растут? Ты конечно можешь считать как угодно но например brainbench считает что я знаю С++ лучше чем 99.9% проходивших этот тест...
CC>И несешь теперь ты слово как истину. И наставляешь ты агнцев неразумных на путь истинный огнем и мечем...
Куда несу? Я обсуждаю и прошу своих апонентов изложить свою точку зрения и аргументировать необходимость нативных языков в место этого я получаю обвинения в фанатизме, буйство демагогии и полное отсутствие технических агрументов
WH>>Это просто не серьезно. CC>Отнюдь.
Если программа стартует пару минут (а это с играми случается) то пара лишних секунд на разогорев ВМ ничего не решат.
CC>Смотря в чем. Иногда разница в 5% уже критична...
Например я бы предпочем чтобы "Vampire Masquerade — Bloodlines" работал в два раза медленней но РАБОТАЛ.
CC>А если памяти мало даже для unmanaged? Возьми современные игры например.
А что современные игры? Если бы разработчики болие тщательно подходили к архитектуре то они бы и работали быстрее и памяти ели меньше. Болие того они бы просто работали...
CC>дискуссию развивать пожалуй не будем, ок? потому как это будет еще на постов 20 уже обсосанного тут флуда...
Это конечно твое право но в твоих сообщениях прослеживается явное не знание тогоже .NET'а.
CC>В таком случае коллега, может поделитесь своим видением managed в ресурсоемкой FPS игре?
А какие собственно проблемы?
CC>До выхода еще почти год. Что там микрософт наворотит еще не известно... грозились же весь АПИ на .нет перевести...
Да ничего там не будет. NT она и в африке NT.
CC>Основное возмущение народа вызвала как раз неточность и категоричность твоих оценок касательно ниш.
Возмущение, демагогия, обвинения во всех смертных грехах были, а вот аргументов почему я не прав небыло.
CC>... криворукость прощать не стоит а потворствовать вообще нельзя... Но согласись, если какой то человек не способен писать на языке без ошибок а другие совершают эти ошибки на порядок меньше на том же языке то это не значит что язык плохой.
Хватит называть меня криворуким. Надоело уже.
Когда я писал на С++ я постоянно думал о том где тут может быть UB, как избежать циклических ссылок и тп
На C# с ReSharper'ом я пишу в совершенно другой манере. Я все свои мозговые ресурсы сосредотачиваю на архитектуре, а не на коде. Код за меня пишет ReSharper, а я только показываю ему направление движения. Сосредоточившись на архитектуре и раставив в критических местах проверки я уверен что если я что-то забуду то тут же вылетит исключение и я это исправлю. Причем до тестеров ошибки практически не доходят, а если и доходят то в подавляющем большинстве их ноги растут из того что я непонял ТЗ или ТЗ было не точным.
CC>знаю... единственная программа (кроме игр) у меня на домашнем компе которая медленнее всего работает и больше всего ест памяти. но это к слову...
А ты знаешь что там тормозит и жрет память? Вот когда узнешь тогда и делай выводы...
hint:В Янусе использованы JET и IE...
CC>кста, не вижу широкого распространения "аппаратной поддержки" к которой собственно и относилась фраза про широкое распространение... отнесем это на не совсем верное формулирование мной мысли...
Еще раз аппаратная поддержка управляемым ОС нужна гораздо меньше чем современным.
CC>имелось в виду — портировано на 100% и полностью функционально и уже промышленно используется. в смысле не пример и не тест а реальный солидный рабочий продукт
Что значит на 100%? Рантайм портирован на 100%. Библиотеки портированны не все. Но дело в том что некоторые библиотеки платформозависимои и их просто нельзя портировать тк они используют WinAPI и тп...
CC>надежность в чем? в работе с памятью? и все?
Дык основные проблемы какраз с памятью и возникают. К томуже в управляемых средах частично можно проверять логику программы.
CC>Вообще то если подумать, то оба языка выполняют машинный код на одном и том же процессоре. хъ
Во-во, а вы все скорость, скорость...
WH>>А вот на реальных приложения C# легко делает С++ хотябы по тому что такие вещи на С++ писались бы намного дольше... CC>Эээ.. Мы вроде производительность результата обсуждаем а не время разработки. На дельфях народ к базам данных на готовых контролах тоже быстро проги лепил, и что?
Э нет братан. Если приложение не написано то его производительность не играет роли тк ее (производительности) вобще нет.
WH>>И дело ту не только и не столько в том что там везде подушки разложены но и рантайме который позволяет применять совершенно другие архитектурные решения. CC>Т.е. там просто к языку идет стандартная библиотека с кучей полезняшек и заготовок. И если такую библу присобачить к C++.....
Это конечно тоже не маловажно но у .NET эсть еще и очень мощьная среда испольнения.
И благодоря этой среде можно использовать архитектурные решения на которые при разработки на С++ я бы просто не решился ибо без поддержки среды данные решения даже еслибы и были реализованны какимто чудом то былибы очень не стабильны и подвержены большому колличеству ручной работы и как следствие ошибкам.
CC>Смотри, мозг жиром заплывет без тренировки
Не боись не заплывут. Просто я думаю не о мелких деталях типа "если написать так то будет UB", а об архитектуре программы.
CC>Кста, приходилось писать на жаббе... Свалил через некоторое время бо платили хреново... Не очень приятные воспоминания... Впрочем в основном благодаря менеджменту.
Те неприятные воспоминания о менеджере ты распространяешь на все управляемые среды? Сдорово
CC>тогда не обижайся на отвечающих тебе...
Если ты думаешь что можешь меня обидеть... то ты глубоко ошибаешься.
Если ты конечно начнешь ругатся матом то я как модератор буду просто обязан тебя забанить и как минимум вырезать мат из твоих сообщений.
Но обижатся я не стану. Я выше этого.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > ГВ>У x86 уже GC выискался? Я что-то пропустил? > А в управеляемой ОС обязательно должен быть ГЦ? Или я что-то пропустил?
Да, GC быть _обязан_. Причем любые неGC-механизмы управления памятью —
невозможны (точнее возможны, но с потенциалом порушить всю систему).
Только GC может гарантировать отсутствие "висячих указателей".
Здравствуйте, Cyberax, Вы писали:
C>Тем что процессор не заставляет меня использовать GC
А что управляемая ОС заставляет использовать ГЦ? Например в сингулярити можно для конкретного процесса отключить ГЦ. C>или не использовать адресную арифметику.
Зачем тебе адресная арифметика?
>> Те предлагаешь сделать таки виртуальную машину... А почему бы не посадить все на одну виртуальную машину которая занимается тотальными проверками всего что можно? C>Медленно будет.
Правда? А почему тогда сингулярити на многих тестах рвет и винду и линух? Она же по определению медленная?
C>Ну да, конечно. Эта VM будет работать на уровне VMWare, что неприемлимо для game-development'а, например.
Нет. Она будет работать как минимун на уровне .NET. А если учесть что раблты по разработке оптимизаторов ведутся постоянно то...
C>Сейчас примерно такая же схема работает для MMU — и что-то никто не жалуется, что оно работает медленно (lookup занимает один такт). в MMU используются тривиальные таблици. Тут же придется использовать гораздо болие сложные сущьности. И даже если это какимто чудом удатся свести к одному такту в чем я очень сильно сомневаюсь то это будет стоить прорву транзисторов.
C>Тем что это не ассемблер железа.
А зачем тебе ассеблер железа?
>> C>1. Скорость. >> C>2. Гибкость. C>Пункты 1) и 2).
Ты можешь назвать задачу которую ты этим решаешь?
C>Защитой стека занимается системный код, который можно проверить на корректность (при желании).
О! Код! Те таки софт! Так зачем нам еще железо если код и без железа может проверить все?
C>В С# сейчас сильная модель памяти, так что Double-Lock Checking работает. В слабой модели памяти он работать не будет, и появится еще куча крайне интересных threading-багов.
Угу... хреново он работает.
Кстати как это отностися к управляемым средам? Не понимаю.
C>Где в Nemerle мои любимые деструкторы с нормальной семантикой?
На нахрен не нужны эти деструкторы. Я сам долго плевался по поводу их отсутствия но потом понял что можно работать и без них ничего не теряя.
C>А С++ помешает написать невозможность адресной арифметики.
Ее можно эмулировать.
C>И что? Windows тоже по определению не переносим.
Эты ты мелкософтам скажи...
Например смотри фаил atlstdthunk.h
C>Ага, конечно. А игнорирование (у нас ведь все managed и в принципе сломаться не может!) приводит к еще более тонким ошибкам: http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1
Игнорирование чего? Там какойто умник создал кривую архитектуру и в этом виновата жаба?
Дело в том что на С++ можно сделать такуюже ошибку, а вот записать в чужую память в жабе нельзя.
К томуже как я уже говорил эту ошибку ловить гораздо легче ведь у нас есть последовательность действий для ее воспроизведения и нам нужно просмотреть только те места которые отвечают непосредственно за сериализацию.
А вот если бы дело было при разработке на С++ то память могло бы попортить например то кокшко с сообщением об ошибке... или вобще что-то никак не связаное с сериализацией.
Те масштабы поиска ошибки совсем иные.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Да, GC быть _обязан_. Причем любые неGC-механизмы управления памятью — невозможны (точнее возможны, но с потенциалом порушить всю систему). C>Только GC может гарантировать отсутствие "висячих указателей".
Раскажи это авторам сингулярити.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Я вообще-то сказал, что считаю нереальным. Могу еще раз повторить. Нереальным является контроль индексов массивов во время комапиляции.
Реально. Например так
void TwiceRange(int[] array, int begin, int length)
required array != null && begin > 0 && length > 0 && begin + length < array.Length
otherwise compile error
{
for (int i = begin; i < begin + length; ++i)
array[i] = array[i] * 2;
}
теперь если написать так
void DoSome(int[] array, int begin)
{
TwiceRange(array, begin, 5);
}
То будет ошибка компиляции по тому что значения параметров TwiceRange не проверены
А если написать например так
void DoSome(int[] array, int begin)
required array != null && begin > 0
otherwise compile error
{
if (begin + 5 < array.Length)
TwiceRange(array, begin, 5);
}
То все скомпилируется ибо статический анализ вполне сможет все проверить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Тем что процессор не заставляет меня использовать GC > А что управляемая ОС заставляет использовать ГЦ? Например в сингулярити > можно для конкретного процесса отключить ГЦ.
Ну да, и наслаждаться только статически распределенной памятью. Или как
варинат распределить память ровно 1 раз (освобождать некому).
Сам подумай: что будет с OS без защиты памяти, если я сделаю ручной
delete для объкта, затру это место другими данными, а потом попробую
обратиться по висячему указателю?
> C>или не использовать адресную арифметику. > Зачем тебе адресная арифметика?
А просто так. Для скорости, например.
> C>Медленно будет. > Правда? А почему тогда сингулярити на многих тестах рвет и винду и > линух? Она же по определению медленная?
Оно рвет Винду так как целиком работает в нулевом кольце аппаратной защиты.
У меня вот есть программа, которая в DOS (мы тоже на нулевом кольце)
рвет свою версию для Windowsов и Linuxов как тузик грелку. Так что,
теперь у нас DOS — будущее софтостроения?
> C>Сейчас примерно такая же схема работает для MMU — и что-то никто не > жалуется, что оно работает медленно (lookup занимает один такт). > в MMU используются тривиальные таблици. Тут же придется использовать > гораздо болие сложные сущьности. И даже если это какимто чудом удатся > свести к одному такту в чем я очень сильно сомневаюсь то это будет > стоить прорву транзисторов.
Нам нужен lookup не в одной, а в двух таблицах (по источнику и цели).
Таблицы тоже можно сделать достаточно простыми.
> C>Тем что это не ассемблер железа. > А зачем тебе ассеблер железа?.
Скорость.
> C>Пункты 1) и 2). > Ты можешь назвать задачу которую ты этим решаешь?
Разработку конкуррентных приложений. Нафиг заказчику мой крутой софт,
если соседняя фирма производит софт, работающий быстрее? И при этом
подобный по функциональности.
> C>Защитой стека занимается системный код, который можно проверить на > корректность (при желании). > О! Код! Те таки софт! Так зачем нам еще железо если код и без железа > может проверить все?
Потому что _нельзя_ проверить все без драконовских ограничений.
> C>В С# сейчас сильная модель памяти, так что Double-Lock Checking > работает. В слабой модели памяти он работать не будет, и появится еще > куча крайне интересных threading-багов. > Угу... хреново он работает. > Кстати как это отностися к управляемым средам? Не понимаю.
Это я про портабельность. Этот аспект портабельности известен давно, что
не помешало MS наступить на грабли. А что будет с новыми ncNUMA-системами?
> C>И что? Windows тоже по определению не переносим. > Эты ты мелкософтам скажи... > Например смотри фаил atlstdthunk.h
А у нас Windows под Linux работает? И не в Wine/VMWare?
> C>Ага, конечно. А игнорирование (у нас ведь все managed и в принципе > сломаться не может!) приводит к еще более тонким ошибкам: > http://rsdn.ru/Forum/Message.aspx?mid=1281017&only=1
> Игнорирование чего? Там какойто умник создал кривую архитектуру и в этом > виновата жаба?
Нет, это к чему приводит пресловутая устойчивость (вот в С++ у нас бы
уже все давно упало, а тут жмем "Ignore exception" и работаем дальше!).
> К томуже как я уже говорил эту ошибку ловить гораздо легче ведь у нас > есть последовательность действий для ее воспроизведения и нам нужно > просмотреть только те места которые отвечают непосредственно за > сериализацию.
Агащаз. У вас есть поврежденные файлы.
Здравствуйте, Павел Кузнецов, Вы писали:
CC>> Кста, Intel C++ 9 уже сам умеет распараллеливать участки кода на многопоточность. Если ему разрешить это опцией... ПК>Плюс и Intel, и VC++ (начиная с версий 7 и 8 соответственно) поддерживают OpenMP.
А теперь обьясните какие проблемы сделать тоже самое в управляемой среде?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
