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

WH>>Зачем JIT? JIT не нужен. Кто мешает компилировать при установке приложения?
S>В натив ? А почему сразу нельзя?
По тому что:
1)Надо верифицировать.
2)Чтобы можно было поддержать новые процессоры.
3)Чтобы старые программы начинали работать быстрее после обновления бэкенда.
Ты что вообще не читаешь что тут пишут?

Здравствуйте, 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%
А тут у нас не физика и тем более не химия, а чистой воды математика.

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


WH>По тому что:
WH>1)Надо верифицировать.
WH>2)Чтобы можно было поддержать новые процессоры.
WH>3)Чтобы старые программы начинали работать быстрее после обновления бэкенда.
WH>Ты что вообще не читаешь что тут пишут?

Читаю. Но в начале мысль была, что натив не нужен. Потом, все-таки натив при установке приложения. В целом идея понятна.

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


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. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.

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

PD>Если речь идет о x86/64 — согласен, костыль на костыле, но сделали же попытку создать Itanium, исходя из современных (тогда) принципов — и что ? Если бы он и впрямь дал прорыв в плане производительности — мы бы никакого x86/64 уже не имели.
PD>Или ты что-то иное имеешь в виду ?

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

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

PD>Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
А ты знаешь, что при переписывании доказательств математических теорем на верифицируемый машиной язык наши кучу ошибок в доказательствах? Ошибки конечно исправили, но сам факт.
Вот мы говорим ровно про такой случай.

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

Но учитывая то что верификатор маленький и простой как пень вероятность такой ошибки около нуля. И главное он тоже верифицирован машиной. Так что можно спать спокойно.

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

WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.
WH>10% производительности на ровном месте тебе мало?

10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.

lpd>>В таком варианте в развертку и процесс отладки добавляются VM и
WH>О какой развёртке ты говоришь? Эта ВМ есть всегда.
WH>Мы тут говорим про VM которая лежит в основе ОС. Вся ОС кроме микроскопических кусочков ядра написана под эту ВМ.

Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.

WH>Я довольно долго писал код под платформы, которые распространяют промежуточный код.
WH>Вот там всё просто. Скачал библиотеку и несколькими кликами подключил к проекту. Или ещё проще. Указал в настройках проекта что мне нужна вот такая библиотека. И она сама скачается.
WH>А сейчас вынужден кое-что написать на С++. Вот тут АД. Без проблем встал только boost. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.

Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.

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

PD>-Моя программа работает в 10 раз быстрее твоей!
PD>-Да, но моя работает.

Майнит в 10 раз быстрее, но в чужой кошелек

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

WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд.

Это верно не только для x86. Имплементации risc\cisc могут быть разные. Но да, cisc сложнее и требует больше приседаний.

WH>Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.

Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?

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

lpd>10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.
А тут мы упрощаем и ОС, и процессор и прибавляем в скорости.

lpd>Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
Тут ты просто что-то себе навыдумывал.

lpd>Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.
И нативного кода тоже.

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

S>Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?
Это оценка человека который проектирует процессоры.
В любом случае перекодировщик совершенно точно не бесплатный.

Здравствуйте, 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, которая, собственно, и является "параметром", в протоколе никак не закреплена.