Здравствуйте, Sharov, Вы писали:
WH>>Зачем JIT? JIT не нужен. Кто мешает компилировать при установке приложения? S>В натив ? А почему сразу нельзя?
По тому что:
1)Надо верифицировать.
2)Чтобы можно было поддержать новые процессоры.
3)Чтобы старые программы начинали работать быстрее после обновления бэкенда.
Ты что вообще не читаешь что тут пишут?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Лучше я скажу это, чем то, что никаких гарантий надежности нет и не закладывалось на уровне выбора ЯП в пользу мощности, и то что для выполнения программ, требующих надежности, нет вообще ни одного гарантированного способа их выполнить без утечки.
PD>Да живем же как-то без всего этого. И 0 кольцо вполне изолировано, да и в 3 кольце определенная изоляция по UAC есть. А ты нагородил огород, заставил пользователя вторую машину покупать, а теперь заявляешь — никаких гарантий надежности нет. Что-то все это крайне сомнительно, чтобы могло взлететь.
Я как раз заявляю что гарантии, обеспеченные таким способом лучше, чем отсутсвие и их.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Смайлик заметил, но если серьезно, то ни из чего не следует, что при нынешней элементной базе оно вообще возможно.
Наверняка возможно. Проблемы — в костыльно-заплаточной архитектуре процессоров, которая на такой рост вообще никогда не была рассчитана.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот теперь понял. Все ясно. Правда, последнее едва ли нужно — контрольная сумма и так в секторе есть.
Практика показывает, что этого не всегда достаточно.
PD>Ну что скажу... В общем, достаточно стройно и логично. PD>Я только не уверен в том, что этот алгоритм верификации действительно будет 100% надежным. То, что он , как ты говоришь, доказан — охотно готов поверить, но все равно не убеждает.
А вся современная математика тебя убеждает или нет?
PD>Дело в том, что ты тут привел идеальную схему. А вот что ты писал чуть раньше >>ОС находит те места, которые не может верифицировать и добавляет туда проверку. PD>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме.
Мы тут обсуждали твоего сфероконя в которого я не верю.
Всё что я написал относится исключительно к крайне гипотетическому случаю если в доказательстве верификатора будет ошибка.
PD>А вот строгого доказательства того, что таких случаев будет действительно исчезающе мало — я не вижу. И мне остается только верить тебе на слово, что это будет очень редко, настолько редко, что этим можно пренебречь.
Если верификатор доказан их 0. Строго 0.
PD>Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%.
Я понимаю, что ты путаешь математику и естественные науки.
В математике всё всегда определено на 100%
А тут у нас не физика и тем более не химия, а чистой воды математика.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>По тому что: WH>1)Надо верифицировать. WH>2)Чтобы можно было поддержать новые процессоры. WH>3)Чтобы старые программы начинали работать быстрее после обновления бэкенда. WH>Ты что вообще не читаешь что тут пишут?
Читаю. Но в начале мысль была, что натив не нужен. Потом, все-таки натив при установке приложения. В целом идея понятна.
PD>>Да живем же как-то без всего этого. И 0 кольцо вполне изолировано, да и в 3 кольце определенная изоляция по UAC есть. А ты нагородил огород, заставил пользователя вторую машину покупать, а теперь заявляешь — никаких гарантий надежности нет. Что-то все это крайне сомнительно, чтобы могло взлететь. S>Я как раз заявляю что гарантии, обеспеченные таким способом лучше, чем отсутсвие и их.
Гарантии , конечно, нынешняя система не дает.
Гарантию вообще никто не дает. То. что у нас называется гарантией, есть лишь заложенная в смету стоимость ремонта, если упадет, поделенная на всех покупателей
Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает.
Оснований менять на то, что ты предлагаешь — не вижу.
Здравствуйте, CoderMonkey, Вы писали:
CM>Наверняка возможно. Проблемы — в костыльно-заплаточной архитектуре процессоров, которая на такой рост вообще никогда не была рассчитана.
Если речь идет о x86/64 — согласен, костыль на костыле, но сделали же попытку создать Itanium, исходя из современных (тогда) принципов — и что ? Если бы он и впрямь дал прорыв в плане производительности — мы бы никакого x86/64 уже не имели.
Или ты что-то иное имеешь в виду ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает.
Гомеопатия тоже живет и как бы работает.
PD>Оснований менять на то, что ты предлагаешь — не вижу.
Я не предлагал. Я показывал что кроме двух вариантов (иметь нэтив и не иметь) есть другие.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lpd, Вы писали:
lpd>>У нас регулярно появляются принципиально новые процессорные архитектуры, которые в разы быстрее и лучше предыдущих? WH>Так по тому и не появляются что невозможно перетащить на эти процессоры все программы.
Архитектур было предложено не так мало. Самые популярные x86 и arm. Про особенные преимущества других архитектур,
которым мешает совместимость, я ничего не слышал. Есть конкретные примеры в несколько раз более быстрых,
но незаслуженно редких архитектур, которые ты мог бы привести в обоснование своего утверждения?
Или, хотя бы, проекты таких процессоров?
Чем, вкратце, они принципиально лучше arm?
Если действительно появится процессор в два раза быстрее x86/arm, на него быстро спортируют ОС и перекомпилируют все программы.
Пока промежуточный код выглядит сложным решением несуществующих проблем.
lpd>>Сложно скомпилировать программу под все нужные процессоры? WH>Одну нет. WH>А вот все программы невозможно.
"Все" программы нужны только домашним пользователям, и вполне поддерживаются порты дистрибутивов Linux под разные процессоры.
lpd>>Лично я бы запретил распространять программы в промежуточных кодах, т.к. это усложняет и запутывает развертывание без значительной пользы. WH> Это просто противоречит вообще всему. WH>В случае с промежуточным кодом у тебя один бинарник который работает везде.
Чтобы бинарник работал везде, мне не надо; а если понадобиться, я его просто пересоберу.
В таком варианте в развертку и процесс отладки добавляются VM и хранение прекомпилированных исполняемых файлов.
Вот у тебя подпись про простоту. Почему не следуешь принципам, которые сам же декларируешь?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
PD>>Я только не уверен в том, что этот алгоритм верификации действительно будет 100% надежным. То, что он , как ты говоришь, доказан — охотно готов поверить, но все равно не убеждает. WH>А вся современная математика тебя убеждает или нет?
Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
PD>>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме. WH>Мы тут обсуждали твоего сфероконя в которого я не верю.
Имеешь право, но это не отменяет того факта, что тебе приходится к математическому доказательству хотя бы в теории допустить необходимость ручной проверки.
WH>Всё что я написал относится исключительно к крайне гипотетическому случаю если в доказательстве верификатора будет ошибка. PD>>А вот строгого доказательства того, что таких случаев будет действительно исчезающе мало — я не вижу. И мне остается только верить тебе на слово, что это будет очень редко, настолько редко, что этим можно пренебречь. WH>Если верификатор доказан их 0. Строго 0.
Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство.
PD>>Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%. WH>Я понимаю, что ты путаешь математику и естественные науки. WH>В математике всё всегда определено на 100%
Верно. Именно поэтому математическое доказательство не допускает ни в каком гипотетическом случае невыполнения того, что оно доказало. В естественных науках любой закон допускает , что при каких-то условиях он не выполняется. Так что ничего я не путаю.
Понимаешь, если хоть один раз на дециллион случаев сумма углов не будет равна 180 — надо пересматривать Евклидову геометрию. Больше ее доказательства не могут считаться верными. Даже если для получения следующего отклонения от 180 придется перебрать еще один дециллион треугольников.
А вот современная существующая архитектура основана не на доказательстве. Она в этом плане из естественного мира. И если она даст сбой даже не на дециллион, а лишь на гептиллион случаев — живем спокойно и не нервничаем.
Здравствуйте, samius, Вы писали:
PD>>Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает. S>Гомеопатия тоже живет и как бы работает.
-Моя программа работает в 10 раз быстрее твоей!
-Да, но моя работает.
Здравствуйте, lpd, Вы писали:
lpd>Архитектур было предложено не так мало. Самые популярные x86 и arm. Про особенные преимущества других архитектур, lpd>которым мешает совместимость, я ничего не слышал. Есть конкретные примеры в несколько раз более быстрых, lpd>но незаслуженно редких архитектур, которые ты мог бы привести в обоснование своего утверждения? lpd>Или, хотя бы, проекты таких процессоров?
Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.
10% производительности на ровном месте тебе мало?
lpd>"Все" программы нужны только домашним пользователям, и вполне поддерживаются порты дистрибутивов Linux под разные процессоры.
Это просто не правда.
lpd>Чтобы бинарник работал везде, мне не надо; а если понадобиться, я его просто пересоберу.
А если это старая программа, исходники которой потеряны?
Вот я сейчас одну такую переписываю.
lpd>В таком варианте в развертку и процесс отладки добавляются VM и
О какой развёртке ты говоришь? Эта ВМ есть всегда.
Мы тут говорим про VM которая лежит в основе ОС. Вся ОС кроме микроскопических кусочков ядра написана под эту ВМ.
lpd>хранение прекомпилированных исполняемых файлов.
ОС делает это совершенно прозрачно для пользователей. Большинство пользователей об этом даже знать не будут. Большинство из тех, кто про это вообще в курсе будут знать об этом исключительно по тому что они про это где-то прочитали или им кто-то сказал.
И только разработчики ядра ОС будут иметь с этим дело.
lpd>Вот у тебя подпись про простоту. Почему не следуешь принципам, которые сам же декларируешь?
Я-то следую.
Я довольно долго писал код под платформы, которые распространяют промежуточный код.
Вот там всё просто. Скачал библиотеку и несколькими кликами подключил к проекту. Или ещё проще. Указал в настройках проекта что мне нужна вот такая библиотека. И она сама скачается.
А сейчас вынужден кое-что написать на С++. Вот тут АД. Без проблем встал только boost. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если речь идет о x86/64 — согласен, костыль на костыле, но сделали же попытку создать Itanium, исходя из современных (тогда) принципов — и что ? Если бы он и впрямь дал прорыв в плане производительности — мы бы никакого x86/64 уже не имели. PD>Или ты что-то иное имеешь в виду ?
Этого было недостаточно. Сейчас уже вполне очевидно, что росту частоты пришел конец и нужно намного больше ядер. Проблема в том, что для когерентного кэша накладные расходы растут полиномиально с ростом числа ядер. Значит — нужен некогерентный. А это значит — заодно переписывать все компиляторы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
А ты знаешь, что при переписывании доказательств математических теорем на верифицируемый машиной язык наши кучу ошибок в доказательствах? Ошибки конечно исправили, но сам факт.
Вот мы говорим ровно про такой случай.
PD>Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство.
Либо доказательство с ошибкой.
Но учитывая то что верификатор маленький и простой как пень вероятность такой ошибки около нуля. И главное он тоже верифицирован машиной. Так что можно спать спокойно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов. WH>10% производительности на ровном месте тебе мало?
10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.
lpd>>В таком варианте в развертку и процесс отладки добавляются VM и WH>О какой развёртке ты говоришь? Эта ВМ есть всегда. WH>Мы тут говорим про VM которая лежит в основе ОС. Вся ОС кроме микроскопических кусочков ядра написана под эту ВМ.
Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
WH>Я довольно долго писал код под платформы, которые распространяют промежуточный код. WH>Вот там всё просто. Скачал библиотеку и несколькими кликами подключил к проекту. Или ещё проще. Указал в настройках проекта что мне нужна вот такая библиотека. И она сама скачается. WH>А сейчас вынужден кое-что написать на С++. Вот тут АД. Без проблем встал только boost. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.
Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд.
Это верно не только для x86. Имплементации risc\cisc могут быть разные. Но да, cisc сложнее и требует больше приседаний.
WH>Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.
Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?
Здравствуйте, lpd, Вы писали:
lpd>10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.
А тут мы упрощаем и ОС, и процессор и прибавляем в скорости.
lpd>Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
Тут ты просто что-то себе навыдумывал.
lpd>Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.
И нативного кода тоже.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
S>Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?
Это оценка человека который проектирует процессоры.
В любом случае перекодировщик совершенно точно не бесплатный.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот об URI я и говорю
PD>Мне вот этот формат
PD>https://www.google.ru/search?newwindow=1&ei=gfleWpawL8GcsgGSvIewBg&q=get+http+format+URI&oq=get+http+format+URI&gs_l=psy-ab.3..0i22i30k1.36647.38270.0.38847.4.4.0.0.0.0.141.508.1j3.4.0....0...1c.1.64.psy-ab..0.4.499...33i160k1.0.Wjec5wew_bo
PD>c упаковкой параметров через '&" и знаком вопроса не кажется особенно элегантным. Для 1990 года он был хорош, но сейчас все же можно и что-то лучше структурированное предложить.
В протоколе HTTP нет ничего про & и знаки вопроса.
Он вообще всё, что после hostname, не регламентирует никак — ну, кроме charset. PD>И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить.
И какую проблему это призвано решить?
Я просто знаю про людей (это авторы Microsoft Exchange), которым казалось, что хранить заголовки писем в текстовом виде — затратно.
(На всякий случай поясню, что вот эта часть HTTP — не его собственность, а MIME — несколько более общий формат; принятый, в том числе, и в email).
Они придумали классную вещь — каждый раз, когда встречался новый заголовок,его заносили в список заголовков,и присваивали ему 16битное число. В итоге они огребли в полный рост, и были вынуждены отказаться от этого решения.
Я не испытываю желания бегать по известным граблям.
PD>По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать.
Это плохой способ представлять себе работу HTTP. PD>Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ?
Да, именно в двух местах.
Параметры в URL — это не часть HTTP. Это как если бы кто-то делал параметр частью имени метода. То есть вызываем не power(x, 2), а power2(x), power5(x), power435345(x).
Заголовки — это такая специальная штука с предопределённым значением. Благодаря им, между клиентом и сервером можно вклинить proxy, который умеет делать разные полезные штуки. Это не "параметры метода" — RPC это вообще плохая идея сама по себе, а уж тем более плохой способ думать о HTTP.
А структура body, которая, собственно, и является "параметром", в протоколе никак не закреплена.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.