Re[18]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 14:11
Оценка:
T>>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.64
WH>Статейка как я понимаю платная...

Там есть download/cached.

WH>Даже мой любимый обесплатниваетель http://scholar.google.com/ что-то не помогает.


T>>Аж до экспоненциальной сложности доходит для определённых логик.

WH>Да и причем тут Unrestricted Hierarchical State Machines ?
WH>Вот скажем взяли программу на хаскеле.
WH>Рассахарили, вывели все типы,...
WH>И результат сбросили в бинарник.
WH>Лично я не вижу ни одной причины по которой верификация этого бинарника требовала бы отличное от O(N) время.

Какая верификация?

Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 14:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А может там появились зависимые типы?

S>>Дай ссылки на зависимые типы, а тупой найти не могу.
WH>Уже давал. http://en.wikipedia.org/wiki/Dependent_type
WH>Ты ветку не читаешь что-ли?
Спасибо незаметил. Прочитал, вспомнил Хаскель, каррирование, но понял не всё


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

WH>Тут не финансирование виновато.
WH>Тут мозг нужен чтобы понять что и как надо делать. И главное как не надо.
Зато появилась практическая база, и понимание ккак делать нельзя.
WH>>>Для чего конкретно не подходит верифицируемый код?
S>> Надо говорить об эффективности на конкретном временном отрезке.
WH>Отрезке чего?
Пока нет этих ОСей, говорить даже об эффективности не приходится.
Хотя теоретически всё выглядит ооочень привлекательно.
S>> Которых еще не существует. А двигаться лучше от простого к сложному, тем более уже есть в этом направлении наработки.
WH>Какие? Только не надо про совершенно непотребную оберон ось.
Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
Не любишь ты Вирта. Лучше что то делать, чем ничего.
S>>>>(оберон системы для беспилотных аппаратов работают).
WH>>>Это настолько тепличная среда что обсуждать тут нечего.
S>> Работающая, но по 3 рубля.
WH>Чё?

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

и солнце б утром не вставало, когда бы не было меня
Re[19]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 14:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Какая верификация?

T>Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
Отсутствие нарушения типизации. Этого достаточно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Есть ли будущее у Native Code?
От: dr.Chaos Россия Украшения HandMade
Дата: 24.06.09 14:33
Оценка:
Здравствуйте, vdimas, Вы писали:


V>У меня еще не было компа, чтобы он в нашей жаре летом не сбоил хотя бы раз в неделю.


[offtop]
У меня таких целых 3 . Причём один из них работает 24/7.
[/offtop]
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[21]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 15:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Спасибо незаметил. Прочитал, вспомнил Хаскель, каррирование, но понял не всё

Причем тут хаскель и каррирование я так и не понял.

S> Зато появилась практическая база, и понимание ккак делать нельзя.

У меня это понимание появилось просто при чтении описания модели ОС. Так что я бы это дело зарубил бы еще до начала разработки как бесперспективное занятие.
А вот у обиронщиков оно так и не появилось.

WH>>Какие? Только не надо про совершенно непотребную оберон ось.

S>Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
А что про эту самую мидори известно?
Ну кроме того что мелкософт всеравно не пустит ее в продакшен.

S> Не любишь ты Вирта.

А за что его любить?

S>Лучше что то делать, чем ничего.

Распил грантов это не хорошее занятие.

S>

S> Раки крупные по пять рублей, но вчера, а сегодня мелкие, но по три рубля

И при чем тут это?
На беспилотниках настолько тепличные условия что там что угодно заработает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 15:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


T>>Какая верификация?

T>>Отсутствие деления на 0? Отсутствие зацикливания? Отсутствие утечек памяти?
WH>Отсутствие нарушения типизации. Этого достаточно.

Рекомендую загрузить в ghci следующее:

dup a = (a,a)

dup4 = dup . dup . dup . dup

dup16 = dup4 . dup4 . dup4 . dup4

dup64 = dup16 . dup16 . dup16 . dup16

dup256 = dup64 . dup64 . dup64 . dup64

dup1024 = dup256 . dup256 . dup256 . dup256

dup4096 = dup1024 . dup1024 . dup1024 . dup1024 

dupVeryVeryVeryBig = dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     dup4096 . dup4096 . dup4096 . dup4096 . dup4096 .
                     id


Всё ещё O(N)?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 24.06.09 15:55
Оценка:
Здравствуйте, thesz, Вы писали:

T>Рекомендую загрузить в ghci следующее:

хъ
T>Всё ещё O(N)?
Тут ты специально вырастил тип просто ацкого размера.
И таки да относительно размера этого типа таки O(N).
Но как часто на практике выращивают такие ацкие типы?
Думаю никогда.
В прочем думаю можно пройтись по доступным хаскелевским программам и посчитать размеры типов.
Но лично я сильно сомневаюсь что найдутся типы больше чем dup4 . dup4
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Есть ли будущее у Native Code?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.06.09 16:26
Оценка:
Здравствуйте, WolfHound, Вы писали:


S>> Зато появилась практическая база, и понимание ккак делать нельзя.

WH>У меня это понимание появилось просто при чтении описания модели ОС. Так что я бы это дело зарубил бы еще до начала разработки как бесперспективное занятие.
WH>А вот у обиронщиков оно так и не появилось.
Только по времени на сигулярити ушло немало.
Значит их удовлетворяет для их задач.
WH>>>Какие? Только не надо про совершенно непотребную оберон ось.
S>>Нет я про Midori. Оберон только как предтеча впервые мною услышанной.
WH>А что про эту самую мидори известно?
WH>Ну кроме того что мелкософт всеравно не пустит ее в продакшен.

http://pcportal.org.ru/forum/37-100-1

Эксперты ИТ-рынка связывают большие надежды с внедрением этой системы особенно на мобильных устройствах благодаря встроенному механизму контроля энергопотребления. Модульность Midori также позволит разрабатывать программы, независимые от технических характеристик устройств. Так, например, для "тонких клиентов" станут актуальными заложенные в Midori принципы "облачных вычислений" (cloud-computing) и хранения данных в интернете. В этом случае, по мнению Брайана Мэддена (Brian Madden), на компьютер не нужно будет устанавливать много ПО — необходимые сетевые сервисы в основном уже будут существовать в Сети.

и солнце б утром не вставало, когда бы не было меня
Re[12]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 17:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты уже давно заметил, что для меня все непонятно . Я уже давно решил, что на эти высказывания не стоит обращать серьезного внимания

Это твоё право. Но очень зря. Потому что обращая внимание на непонятные тебе вещи, ты бы смог сделать свои программы лучше. Помнишь, мы обсуждали длины строк? Статистически 99% строк в природе оборудованы длиной от момента своего рождения. Игнорирование этого факта приводит к чудовищно неэффективным алгоритмам на строках.
При этом аргумент в пользу игнорирования ровно один: "а вдруг там не будет длины".

PD>Я так думаю, что придется на 100%. Потому что этот плюс там не по ошибке, а мне именно так и надо, как выяснилось

Я имею в виду, что я согласен на инфраструктуру, которая ловит 99% ошибок. Это в 100 раз сократит мне время отладки.
Понятно, что никакая математика не сможет сказать, соответствует ли спецификация задаче. А вот проверить соответствие программы спецификации очень даже можно.

PD>Многое можно улучшить, хотя при чем тут K&R — неясно. Но то, что вы улучшаете (index out of range, access violation и т.д.) есть маленький-маленький процент от числа всевозможных ошибок при мало-мальски серьезном алгоритме.

Ты опять говоришь про вчерашний день в контексте дня завтрашнего. Посмотри на Code contracts по поводу того, что доступно уже сегодня. И это — промышленный уровень; а в research лежит еще больше готовых образцов.

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

Придумывание контрпримеров — это хорошо. Это правильно. Но начиная примерно с 90го года рулят алгоритмы, которые затачиваются не на максимальное быстродействие в самом хреновом случае, а на максимальное среднее быстродействие с учётом реальной статистики. Именно поэтому смоллтоковые программы с (о, ужас!) биндингом по имени метода рвут C++ программы, скомпилированные старыми компилерами. Несмотря на биндинг по номеру слота.

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

S>>Просто в твоих задачах, значит, эти ситуации малосущественны.

PD>Да.


PD>Я никак не считал, но приведи мне эти самые иммутабельные типы в нынешней библиотеке. String, DateTime... сколько еще покажешь общеупотребимых ?

Uri. Regex. Дело не в этом — ты же считаешь, что это связано с какими-то "ограничениями". Хотелось бы аргументов на эту тему.

PD>Нет. Я, кстати, отнюдь не С-шник по первому языку. И мне язык в данном случае безразличен, правда, ограничусь императивными.

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

PD>См. мой ответ WolfHound в самом конце.

Ок, посмотрим.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 20:49
Оценка:
T>>Рекомендую загрузить в ghci следующее:
WH>хъ
T>>Всё ещё O(N)?
WH>Тут ты специально вырастил тип просто ацкого размера.
WH>И таки да относительно размера этого типа таки O(N).
WH>Но как часто на практике выращивают такие ацкие типы?
WH>Думаю никогда.
WH>В прочем думаю можно пройтись по доступным хаскелевским программам и посчитать размеры типов.
WH>Но лично я сильно сомневаюсь что найдутся типы больше чем dup4 . dup4

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

Но они могут быть и достаточно большими. Например, для одной моей программы требуется -fcontext-stack=100, то есть, она совершает не менее 100 шагов упрощения типов вычислениями над ними с семействами типов (type families). Проверка типов занимает заметное время порядка 30 секунд.

Вот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 01:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Я тебе серьезно советую — разберись наконец, чем виртуальная память отличается от физической , и кто чем управляет. Не в твоей гипотетической управляемой ОС, а в Windows. Ты их просто-напросто путаешь, а поэтому пишешь такое, что ни в какие ворота не лезет.

WH>Я это прекрасно знаю.

Вряд ли. Иначе зачем ерунду пишешь ?
With best regards
Pavel Dvorkin
Re[14]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 01:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А сразу в нулевое кольцо и не надо.

WH>Сначала вломились в какой нибудь браузер.
WH>Потом устроили эскалацию привилегий.
WH>Потом поставили драйвер.

Тебе же тут уже объяснили — не работайте под админом. Кстати, как ты собираешься устроить эту самую эскалацию для процесса броузера, если он (под Вистой) запущен хоть и от админа, но без админских прав ? (т.е с юзеровскими правами) Это тоже очень интересно бы знать
With best regards
Pavel Dvorkin
Re[15]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 02:59
Оценка:
Здравствуйте, swined, Вы писали:
S>ты же сам сказал, что верификацией должен заниматься компилятор. компилятор работает не на твоей машине и слитый из интернетов бинарь может содержать все, что угодно.
Нет, это ты путаешь. Верификатор — совершенно отдельная штука. Его нужно делать как можно более компактным, потому что его верификация выполняется вручную. Вручную верифицировать огромный компилятор ты запаришься.
S>бтв, как ты смотришь на необходимость длительной и ресурсоемкой верификации перед каждой установкой каждой программы?
Верификация делается за O(N), где N — размер программы
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 03:33
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

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

Может, тебе что-то из основ программирования почитать? Ну, чтобы знать, что далеко не все языки программирования оперируют абстракциями типа "блок памяти".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Есть ли будущее у Native Code?
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 03:33
Оценка: +1
Здравствуйте, Mystic, Вы писали:
M>Аппаратную независимость можно достичь и на уровне исходников. По крайней мере принципиальных отличий байт-кода от исходников нет. По идее один и тот же C# код должен компилироваться в один и тот же байт-код. Так что большой разницы нет, то ли я получу байт-код, то ли я получу код на C#. Так что претензии больше не к самой идее JIT, а к требованию верифицируемости кода. Да, верификация нужна больше в тех случаях, когда код запускается без моего ведома, как, например, скрипты на странице. Но в этом случае, по большому счету, и не нужна производительность. А если я скачал программу из интернета, я доверяю ее автору. Откомпилировал да запустил, и на верификацию плевать. И пример больше иллюстрировал тот факт, что разрабатывать неверифицированный код в некоторых случаях проще.
Пример иллюстрировал тот факт, что ты привык применять определённые средства, совершенно неудобные для твоей задачи. Но ты привык это делать настолько хорошо, что теперь тебе сложно воспринять более простые вещи. Верификация кода не имеет к твоим проблемам никакого отношения. Да, наверное, MSIL не лучший язык для записи твоих задач. Но и ассемблер — тоже. По-хорошему, это должен быть DSL, который очень компактно и понятно отражает суть алгоритма. А упаковка алгоритма в битхакинг — дело компилятора.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 05:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>То, о чем ты говоришь, есть управление физической памятью в ОС, своп файл и RAM исключительно под ее контролем, я туда никак из 3 кольца попасть не могу. А сборка мусора есть действие исключительно в виртуальной памяти процесса.

WH>Почему исключительно?

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

PD>>А если не секрет, как из программы 3 кольца узнать, как давно мы не обращались к этой странице ?

WH>А ей и не надо.

Ты же мне предлагал это сделать

WH>Хачим ОСь и вперед.


А подробности опять-таки можно ? Какие файлы, как именно. Как к этому WFP отнесется ?

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



PD>>И твоя тотально управляемая ОС в теории тоже не так уж плоха. Как идея. Но реально тебе накидали немало возражений (DMA, текстуры, внешние устройства), могу еще и свое добавить — CUDA, там надо резидентную память иметь.

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

Все же, что с CUDA делать-то будешь ? Мне резидентную память для нее вынь да положь!


PD>>И ради этого переписать все ПО, переделать всю аппаратуру ? И ради этого миллиарды долларов ? Не дадут.

WH>ПО можно переделывать постепенно. Ведь можно начать с относительно небольших ниш.

А ОС тоже постепенно будешь переделывать ? Превратим Windows в управляемую систему ? Не выйдет. А существующее ПО куда ?

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


VM Java существует полтора десятка лет и до сих пор ни в какую ОС не пыталась превратиться, по крайней мере на x86.


WH>Железо подойдет современное.


CUDA ?

WH>Даже без IOMMU но тогда периферии придется доверять. В прочем в современных ОС ей и так доверяют.


PD>>Именно. Я же об этом и говорю. Разные есть задачи. А машина одна

WH>А процессор один.
WH>Ты сказать то что хотел?
WH>Что нештатные ситуации обрабатывать не надо?

Можно ссылку, где это я сказал ? Или это твои домыслы ?

PD>>Так разные же есть задачи. Вот ты писал, как говоришь, числодробилки. Там констант много было ? Как бы все не кончилось 4 константами — 0 , 1 pi и e

WH>Числомолотилки прекрасно пишутся на функциональщине при наличии оптимизатора.




WH>А есть и более интересный базис.

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

Ох! Тихий ужас. Не зная сути задач, не зная их потребностей предлагать какое-то распределенное решение...

WH>Вот например простенький оптимизатор без единой переменной.


<skipped>

WH>Написать это короче практически невозможно.


А меня мало интересует, короче или длинее.

PD>>В конце концов по существу переменная (в широком смысле слова) — это некий блок памяти, содержимое которого может изменяться (а константы — не может).

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

Совершенно верно. В моделях языка не существует. Но выполняется этот код не в модельной среде, а на конкретной машине. У этой машины линейное (скорее всего) адресное пространство. Память, иными словами. И все твои абстракции в конечном счете превращаются в эти презренные блоки памяти. Так что я просто говорю о том, что из твоих модельных соображений получается в конечном счете. И от этого никуда не деться — до тех пор, пока твои абстракции не будут реализованы аппаратно, то есть вместо ОП мы будем иметь какой-то набор аппаратных то ли ArrayList, то ли LinQ моделей, то ли еще чего-то...

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

WH>См код выше.
WH>Скока там переменных?

Нет, ты никак понять меня либо не хочешь, либо не можешь.

Последний аргумент (ибо дискуссию в этой ветви я прекращаю). Я иногда позволяю себе давать советы и рекомендации в форуме .Net, хотя я отнюдь не специалист в ней. Когда там особенности языка или библиотек обсуждаются, я молчу — некомпетентен. Но когда там обсуждается нечто такое, что требует выхода на уровень ниже (Win API) — я иногда свои советы даю, и не без успеха. И с таким же успехом я могу их дать в форуме , например, по FoxPro, которуя я совсем не знаю. Один раз я видел пример для FoxPro с вызовом средств Win API, так что я знаю, что это возможно. Все. Этого вполне достаточно, чтобы я мог давать советы в этой части. Есть базис, есть надстройка. Можно бы это наконец понять...
With best regards
Pavel Dvorkin
Re[13]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 06:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:


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

S>Может, тебе что-то из основ программирования почитать? Ну, чтобы знать, что далеко не все языки программирования оперируют абстракциями типа "блок памяти".

Может, тебе основы организации компьютера почитать ? Чтобы понять, что независимо от языка, при выполнении программы дело закончится некими действиями с блоками памяти ? По крайней мере до тех пор, пока вместо ОП не появятся аппаратно реализованные абстракции твоего любимого языка.
With best regards
Pavel Dvorkin
Re[11]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 25.06.09 07:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Да, вот тут ты прав. Жаль, что идея 4 колец не реализовалась. Драйверы ИМХО не должны бы быть в нулевом кольце, а должны бы в 1-м. Тогда при ошибке в драйвере ядро могло бы его прибить. В общем, модель 80286. Но не пошло.

WH>Ага. По тому что тормозило...

Нет, не поэтому. Потому что сегментная модель неудобна для реализации.

PD>>А зачем ? Что все же плохого просто в том, чтобы проверить наличие файла ?

WH>Чтобы не забыть проверить и не придумывать потом что делать если его таки нет.

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

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


В теории да. В реальности — просто не выйдет.

PD>>И что ? Что вы все эти пустяки раздуваете до немыслимых размеров , а потом борьбу с ними представляете как чуть не главное в программировании. Ну пустяки это же все. Мелочи.

WH>Избавление от всех исключений не вызванных внешними факторами мелочи?

Всех ? А ну-ка, избавь меня от FloatOverflowException или ZeroDivideException? При одних данных умножение/деление работает, при других — exception. Или это внешние факторы ?

Не всех, а только некоторых — IndexOutOfBounds, AccessViolation и т.п. Вот от этого еще можно надеяться. А это для меня истинно мелочи.


WH>Проверка кода на уровне до которого юниттестам как до пекина раком мелочи?


Да. И юниттесты меня также мало интересуют. У меня свои тесты были, их не сгенерируешь, их получить надо, и было их примерно 100 тысяч.

WH>Уничтожение вирусов мелочи?


В огороде бузина, а в Киеве дядька. Я не пишу вирусы, и к написанию моей программы это не имеет отношения.


PD>>При чем тут менеджер памяти ОС, когда я говорю о произошедшем в моем процессе исключении, которое я хочу обработать (SEH) и продолжать.

WH>А у меня этого исключения гарантированно не будет.

PD>>А тебе известно, что я могу вполне сознательно допускать Access Violation, ибо он часть логики моей программы и именно этого я и хочу ?

WH>А нахрена оно тебе нужно? Что это за логика такая?
PD>>Посмотри у Рихтера, там это обсуждается (в разделе по управлению виртуальной памятью). И вообще ты про резервирование и коммитирование слышал, чем отличаются, понимаешь ?
WH>Не хуже тебя.

А если не хуже меня, зачем вопрос задаешь насчет того, для чего надо допускать Access Violation и что это за логика такая ? Я же тебе написал про Рихтера, мог бы и посмотреть. Более того, если бы ты и впрямь знал это — у тебя такого вопроса даже не могло бы возникнуть, это же азбука.

Ладно, приведу кусок из Рихтера сам. Не для тебя — так для других может быть полезно

///////////////////////////////////////////////////////////////////////////////////////////////////////////////
Let's pretend you're implementing a spreadsheet application that supports 200 rows by 256 columns. For each cell, you need a CELLDATA structure that describes the contents of the cell. The easiest way for you to manipulate the two-dimensional matrix of cells would be to declare the following variable in your application:

CELLDATA CellData[200][256];

If the size of a CELLDATA structure were 128 bytes, the two-dimensional matrix would require 6,553,600 (200 × 256 × 128) bytes of physical storage. That's a lot of physical storage to allocate from the paging file right up front for a spreadsheet, especially when you consider that most users put information into only a few spreadsheet cells, leaving the majority unused. The memory usage would be very inefficient.

So, historically, spreadsheets have been implemented using other data structure techniques, such as linked lists. With the linked-list approach, CELLDATA structures have to be created only for the cells in the spreadsheet that actually contain data. Since most cells in a spreadsheet go unused, this method saves a tremendous amount of storage. However, this technique makes it much more difficult to obtain the contents of a cell. If you want to know the contents of the cell in row 5, column 10, you must walk through linked lists in order to find the desired cell, which makes the linked-list method slower than the declared-matrix method.

Virtual memory offers us a compromise between declaring the two-dimensional matrix up front and implementing linked lists. With virtual memory, you get the fast, easy access offered by the declared-matrix technique combined with the superior storage savings offered by the linked-list technique.

// далее пропущены детали

There are four methods for determining whether to commit physical storage to a portion of a region:

// пропущены первые 3 метода. ниже все выделенное — мной (PD)

Use structured exception handling (SEH)—the best method . SEH is an operating system feature that causes the system to notify your application when certain situations occur. Essentially, you set up your application with an exception handler, and then, whenever an attempt is made to access uncommitted memory, the system notifies your application of the problem. Your application then commits the memory and tells the system to retry the instruction that caused the exception. This time the memory access succeeds, and the program continues running as though there had never been a problem. This method is the most advantageous because it requires the least amount of work from you (meaning less code) and because your program will run at full speed. A complete discussion of the SEH mechanism is saved for Chapters 23, 24, and 25. The Spreadsheet sample application in Chapter 25 illustrates exactly how to use virtual memory as I've just described
With best regards
Pavel Dvorkin
Re[7]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 25.06.09 07:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...

V>>Ну вот С++ на зависимых типах построен,
WH>Чё?!
WH>В С++ нет зависимых типов.

Не ожидал от тебя такого заявления.
Ты точно знаешь, о чем говоришь?

V>>Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное".

WH> А что по твоему разработчик ГЦ будет ручками память ковырять?

Не важно чем, если есть ср-ва прочитать/записать хотя бы байт из/в произвольного участка памяти, то вся безопасность и доказуемость сразу улетучивается.
Re[9]: Есть ли будущее у Native Code?
От: vdimas Россия  
Дата: 25.06.09 07:11
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>В общем случае не можно.

WH>Можно. Учи матчасть.

Блин, тебе хочется хлеба и зрелищ? Ну давай покажи как можно в ОбЩЕМ случае. Заодно список языков с примерами.

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

WH>

А я тебе на С++ покажу.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.