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

S>А почему ты решил, что вот этот абзац про тебя?

<skipped>

S>Может быть, я имел в виду совсем других людей — ты же вроде как официально не против книжки-то читать.

А, ну тогда ладно. Будем считать, что этот абзац ко мне не относится. Это все о ком-то другом. Это именно он заявлял, что "недостаточно изучить основы компиляторостроения для того, чтобы написать современный компилятор". Это он заявлял : "поэтому я не буду ничего читать на эту тему. Лучше я пофантазирую на тему того, что я прочитал в описании ключей командной строки". Ну и т.д. И , конечно, именно он является обскурантом и клерикалом.

Подождем тогда, пока он вернется и скажет, что он об этом думает Вернусь из отпуска — посмотрю его ответ

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

PD>Что из себя представляет моя задача — ты не знал и знать не мог, так как я об этом не писал и не напишу. И не имея ни малейшего представления о задаче, ты взялся рекомендовать для нее средства решения. И разумееется, попал пальцем в небо — тот протокол, который там используется, утвержден CEN (European Committee for Standardization).
Павел, мне совершенно неважно, кто именно утвердил вам протокол. Даже подпись пророка Мухаммеда на спецификации не гарантирует никаких волшебных свойств. Комитетов по стандартизации в мире — как собак нерезаных.
Ты сказал, что вы разрабатываете новый протокол.
Если протокол был уже утвержден — в чем проблема? Если ваш раввин сказал, что мацу надо употреблять именно таким способом — значит надо употреблять таким способом. Это не вопрос технического превосходства, это вопрос технических ограничений.
PD>Как я могу после этого серьезно к твоим рекомендациям относиться ?
Как к словам человека, который разбирается в обсуждаемой теме. А как еще?

Кстати, в процитированном тексте нет ничего про то, что HTTP лучший потому, что на нем работаю я.
Он лучше, чем навязываемый выше по ветке самописанный XML поверх TCP, по объективным причинам. Которые я озвучивал неоднократно как в той ветке, так и в других.

Конечно, новичкам в программировании тяжело себе представить, с какими проблемами может столкнуться наивная реализация. Ну там, к примеру, что сравнение символов может оказаться сложнее, чем ordinal сравнение байт. Или что в распределенной среде умение не передавать данные там, где это возможно, важнее умения передавать данные.
Или что умение строить адаптивный словарь полезнее для уменьшения трафика, чем умение пользоваться заготовленным словарём.

Это ничего, это можно исправить — было бы желание задавать вопросы и воспринимать ответы на них.

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

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

PD>>Что из себя представляет моя задача — ты не знал и знать не мог, так как я об этом не писал и не напишу. И не имея ни малейшего представления о задаче, ты взялся рекомендовать для нее средства решения. И разумееется, попал пальцем в небо — тот протокол, который там используется, утвержден CEN (European Committee for Standardization).
S>Павел, мне совершенно неважно, кто именно утвердил вам протокол. Даже подпись пророка Мухаммеда на спецификации не гарантирует никаких волшебных свойств. Комитетов по стандартизации в мире — как собак нерезаных.

Угу. При том, что этот протокол обязаны использовать все страны, входящие в CEN.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.


Ладно, не стоит дальше обсуждать. Нет смысла.

S>Как к словам человека, который разбирается в обсуждаемой теме. А как еще?

Скорее уж как к словам человека, который берется рекомендовать, не зная о чем идет речь.

S>Конечно, новичкам в программировании тяжело себе представить, с какими проблемами может столкнуться наивная реализация. Ну там, к примеру, что сравнение символов может оказаться сложнее, чем ordinal сравнение байт. Или что в распределенной среде умение не передавать данные там, где это возможно, важнее умения передавать данные.

Ох, хоть кур-то не смеши. Совсем не зная сути дела, делать хоть какие-то высказывания — это же курам насмех.

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

PD>CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
PD>Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
Ой, я прямо вся дрожу. Вот если бы ты ссылку на описание протокола привел, то было бы что обсуждать. А список national standards bodies меня никак не впечатляет. Они еще много во что входят, к примеру в ISO.
Тем не менее, далеко не всё, выходящее в ISO, является образцом хорошего вкуса.
PD>Скорее уж как к словам человека, который берется рекомендовать, не зная о чем идет речь.

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

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

Обсуждать здесь нечего и незачем. Этот протокол принят в качестве стандарта для тех стран, которые его используют — список я их привел. И все они обязаны этому протоколу следовать, так как речь идет об интеграции национальных стандартов. Вот и все в данном случае. Я вовсе не обсуждаю преимущества и недостатки этого протокола и не намерен обсуждать. А не зная сути дела, рекомендовать что-то иное — имеет такой же смысл, как рекомендовать ЕС перейти на японские иены . Даже если иены очень хороши.

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

M>Помню, что эта тема не раз обсуждалась, но что-то сейчас я найти ее не могу.
M>Часто говорится о том, что JIT'у доступны оптимизации, которые C++ — компилятору и не снились
M>Можно поинтересоваться — какие


К сожалению не представляется возможным перечитать всю ветку, но на всякий случай (если это тут ещё не упоминалось).
ICC (Intel C/C++ компилятор) умеет генерировать несколько специализаций одной функции под разные семейства процессоров, и уже в ран-тайм выбирать нужную специализацию. Это, конечно, не полный аналог JIT компиляции, тут есть и свои плюсы и минусы.
Минусы — то, что увеличивается размер бинарного файла; в коде стоят косвенные вызовы вместо прямых; набор "поддерживаемых" компиляторов фиксируется в момент компиляции.
Плюсы — то, что в ран-тайме не тратится время на компиляцию; компиляция может быть традиционно тяжело-эффективная.

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

PD>Обсуждать здесь нечего и незачем. Этот протокол принят в качестве стандарта для тех стран, которые его используют — список я их привел. И все они обязаны этому протоколу следовать, так как речь идет об интеграции национальных стандартов. Вот и все в данном случае. Я вовсе не обсуждаю преимущества и недостатки этого протокола и не намерен обсуждать. А не зная сути дела, рекомендовать что-то иное — имеет такой же смысл, как рекомендовать ЕС перейти на японские иены . Даже если иены очень хороши.

А зачем вы его тогда разрабатываете?
Типа тренеруетесь?

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

PD>И все же не час.

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

Ява занимается перекомпиляцией горчих точек в реальном времени. Даже применяе спекулятивную перекомпиляцию. По началу когда классов фиксированное количество генерируется код только в расчете на них. Когда подгружаются другие классы которые могут изменить переопределение некоторых методов производится перекомпиляция.

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

PD>А вообще-то схоластическая это дискуссия. У обоих способов есть свои плюсы и минусы, о чем я и говорил в своем первом постинге в этом треде.

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

Многие оптимизации не удается (или очень сложно) сделать просто в виду того, что целевая платформа имеет некие фичи не дающие сделать оптимизации или попросту требующие неких доп.вычислений которые устраняют выигрыш от оптимизации. Скажем для дотнета это — ковариантность массивов (модификацию массивов объектов требуется защищать специальным кодом), барьер записи используемые GC, организация интерфейсов... В общем, много чего. Вот и получается, что может джит и порождает более быстрый код, но это компенсируется накладными расходами. В итоге скорость получается чуть быстрее или чуть медленнее нежели при статической компиляции. Еще надо учитывать, что во флагманские С++-компиляторы (с которыми обычно и сравнивают управляемый код) за последние десятилетия была вложено куча денег которые, конечно же, дают о себе знать.

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

PD>Ну здесь мы бумерангом ту же ситуацию обратно получаем. JIT — да, но при компиляции с исходного кода компилятор с C#, к примеру, не знает, на какую обстановку это ориентировано. И не знает хуже, чем обычный компилятор. Тот, к примеру, может учесть специфику x86-x64 со всеми конвейерами и микрооперациями (как Intel C++) или Intel-AMD (последнее маловероятно, конечно, но мы же о принципах говорим), а компилятор C#, если явно не указана платформа, вынужден делать в расчете на произвольную платформу. А оптимизацию ИМХО все же лучше делать с исходного языка, а не с псевдоассемблера (IL) — информации для принятия решений больше.

Жать таких знатоков нет в командах разрабатывающих оптимизирующие компиляторы. А то вот и в MS VC++ и в некоторых других компиляторах разработан специальный промежуточный язык (дико низкоуровневый) в котором и производятся оптимизации. Более того, даже на стадию линковки оптимизацию переводят.

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

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

M>Можно поинтересоваться — какие

Официального названия не знаю , но могу описать на пальцах.

1. Компилятор определяет что функция не имеет побочных эфектов и состояния, т.е. ее результат зависит только от входных данных.
2. компилятор собирает статистику и анализирует входны данные , и видит что некоторые комбинации повторяются довольно часто.
3. компилятор вместо работы функции подставляет данные из таблицы результатов по ключу входных значений.