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


PD>>В программной и аппаратной реализации. В фиксированном и неизменяемом программным путем списке команд. Одним словом, в реализации софтом или аппаратурой.

P>Я могу прочитать это следующим образом: софтовая реализация процессора во время работы произвольно меняет набор выполняемых ею команд.

Не совсем так. Софтовая реализация "процессора" (как и любой другой софт) может выполнять любые операции над "командами". Я не зря взял последнее слово в кавычки так как если они исполняются софтом, то их набор может быть любым, язык — любым (хоть русским) и способ выполнения — любым. Для аппаратного процессора набор фиксирован, язык — его машинные коды, способ выполнения зашит в аппаратуру. Степеней свободы 0.

PD>>Вот если java-процессор аппаратно исполняет байт-код — тогда да.

P>Т. е. ты считаешь, что JVM может делать со своими входными данными все, что угодно, а аппаратный Java-процессор — нет?

Аппаратный java-процессор может тоже исполнять байт код как ему угодно, но аппаратно. То есть попросту байт-код — это его машинные команды. Будет там аппаратная оптимизация или нет, как они там выполняются — это вопрос к аппаратуре.
А JVM Windows — программа, которая строит аппаратный код процессора x86 .
Резюме — делать могут обе, но одна аппаратно, а другая — программно. В этом и разница. Вторую можно перепрограммировать (улучшить оптимизацию, например), первую — нельзя.

PD>>А вот аппаратный процессор только один, и понимает он только машинный код.

P>Многопроцессорные системы, в том числе асимметричные, разве не известны с незапямятных времен?

А они тут при чем ? Естественно, если несколько процессоров, то для каждого свой машинный код.

Возвращаясь к теме. Если принять твое (и не только) определение процессора, который берет команду из памяти и ее выполняет, то что такое не-процессор ? Я ведь могу утверждать, что любое Win32 приложение есть такой процессор. Оно берет команду из очереди сообщений (попробуй мне докажи, что это не команда! ), обрабатывает ее, потом следующую и т.д. Для консольных не очередь сообщений, но , в общем, то же самое. Понимаешь, если определить "процессор" иначе, чем аппаратный процессор, то любая программа — процессор. Какой тогда смысл в понятии "процессор", трактуемом таким образом ?

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

P>Моя тоже не понимает, однако.

P>JVM: считал очередную команду из памяти, выполнил.
P>Java-процессор: считал очередную команду из памяти, выполнил.
P>CPU Intel: считал очередную команду из памяти, выполнил.

P>В чем существенная разница?

Вы просто забыли контекст разговора, с которого всё началось.

Ни кто не спорит, что с определённой точки зрения можно считать и обычный x86 код и java байт-код и допустим bat файл сущностями одного порядка, то тогда из этого одновременно следуют два интересных вывода:

1. Бинарная кроссплатформенность в .net безусловно есть (на чём и настаивал оппонент)
2. Тогда и бинарная кроссплатформенность C++ точно так же есть (подразумевая исходники C++ и компиляцию при запуске).

Если с этим все согласны, то тогда никакого спора и нет. Просто как показалось Павлу (и мне тоже), тут есть народ согласный с одним утверждением и не согласный с другим. И вот тогда пускай доказывают в чём же разница между этими двумя случаями.

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

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

PD>Не совсем так. Софтовая реализация "процессора" (как и любой другой софт) может выполнять любые операции над "командами".

А я до сегодняшнего дня думал, что одна и та же виртуальная машина выполняет определенный набор операций, который не меняется во времени. Во всяком случае JVM ни от IBM, ни от Oracle не понимает ничего, кроме байт-кода Java.

PD>Я не зря взял последнее слово в кавычки так как если они исполняются софтом, то их набор может быть любым, язык — любым (хоть русским) и способ выполнения — любым. Для аппаратного процессора набор фиксирован, язык — его машинные коды, способ выполнения зашит в аппаратуру. Степеней свободы 0.

У одной отдельно взятой виртуальной машины набор команд фиксирован, формат команд строго определен, способ исполнения зашит в коде ВМ.

PD>Аппаратный java-процессор может тоже исполнять байт код как ему угодно, но аппаратно. То есть попросту байт-код — это его машинные команды. Будет там аппаратная оптимизация или нет, как они там выполняются — это вопрос к аппаратуре.

Виртуальная Java-машина может тоже исполнять код, как ей угодно, но программно. То есть попросту байт-код — это ее машинные команды (напомню, она машина, хоть и виртуальная). Будет там программная оптимизация или нет — это вопрос к программе.

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

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

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

P>>Многопроцессорные системы, в том числе асимметричные, разве не известны с незапямятных времен?

PD>А они тут при чем ? Естественно, если несколько процессоров, то для каждого свой машинный код.

Для КСВ.

PD>Возвращаясь к теме. Если принять твое (и не только) определение процессора, который берет команду из памяти и ее выполняет, то что такое не-процессор ? Я ведь могу утверждать, что любое Win32 приложение есть такой процессор. Оно берет команду из очереди сообщений (попробуй мне докажи, что это не команда! ), обрабатывает ее, потом следующую и т.д. Для консольных не очередь сообщений, но , в общем, то же самое. Понимаешь, если определить "процессор" иначе, чем аппаратный процессор, то любая программа — процессор. Какой тогда смысл в понятии "процессор", трактуемом таким образом ?

Понятие "процессор" может трактоваться достаточно широко. Это нечто, умеющее что-то выполнять. В конкретных случаях необходимо конкретизировать, о чем речь. Центральный процессор ЭВМ — это одно, текстовый процессор — другое, цифровой сигнальный процессор — третье. Не вижу здесь никаких противоречий. Кухонный комбайн тоже вполне подходит под определение процессора.

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

P>Понятие "процессор" может трактоваться достаточно широко. Это нечто, умеющее что-то выполнять. В конкретных случаях необходимо конкретизировать, о чем речь. Центральный процессор ЭВМ — это одно, текстовый процессор — другое, цифровой сигнальный процессор — третье. Не вижу здесь никаких противоречий. Кухонный комбайн тоже вполне подходит под определение процессора.

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

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

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

P>>Понятие "процессор" может трактоваться достаточно широко. Это нечто, умеющее что-то выполнять.

PD>Да я . в общем, со всем согласен. Просто в таком понимании разницы между программой и процессором нет никакой.

Дак нужно сразу уточнять, о каком именно процессоре идет речь. Тогда все становится на свои места. При конкретизации сферический процессор в вакууме исчезает и на его месте возникает вполне определенная сущность, о которой можно спорить.

PD>А вообще пустой какой-то спор.

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

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

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

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

LC>Мамут во всю очень не красиво тут переходит на личностные оскорбления, прям таки очень не корректно пишет в отношении товарища Шеридана.
Забей, эти двое тут с не запамятных времён развлекают контингент.

LC> А мое сообщение, где я назвал вещи своими именами, Мамута троллем, взяли, да стерли?
Видимо сочли его старым баяном.

LC>весь ресурс превращается в помойку (уже превратился)
Спасибо, Кэп!

LC>сразу же засираются личностными оскорблениями таких товарищей как Мамут, что читать аж тошно.
Пользуйся janus и сразу ставь на такие сообщения правильную галочку.

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

S>Вы как-то узко трактуете понятие бинарного кода. Лично меня та степень бинарности, которая используется в дотнете, вполне устраивает.
Её там нет. Там IL код, а это промежуточный язык а не бинарь.

S>И мы же оба понимаем, что между кодом и процессором в наше время всегда "сидит кто-то ещё", не так ли? Скажем, загрузчик.
Загрузчик не производит ни компиляцию ни JIT ничего что генерило бы непосредственно финальный бинарь.

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

PD>Ты с Mono работал ?
PD>Нет никаких бинарных библиотек и приложений под платформу A (Windows) и Б (Linux). Компилятор Mono создает обычный EXE или DLL, с той же структурой, что и Visual Studio. Я писал программу в VS, делал EXE файл, а заказчик потом исполнял его в линуксе. Другое дело, что он использует системные библиотеки, которые в Windows и Linux отличаются, но опять же не по структуре, а по своим действиям на неуправляемом уровне.

Ты под wine виндовые проги запускал?

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

S>Photoshop Lightroom написан на Qt, достаточно в качестве примера?
То то он такой гм... нестандартный.

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

PD>Ну что же, вопрос исчерпан. Мы понимаем здесь существенно разное, спорить дальше не о чем.

Самое время вернуться к исходной точке:

Отож. Если нет платформенно-зависимого кода, то можно запросто взять программу, написанную под моно, запустить под гентой, и она зареференсит сборку, скомпилированную дотнетом под виндой, и даже создаст экземпляры типов из этой сборки, и сможет вызывать их методы.
Вот это — бинарная совместимость. А про С++ возвращайся рассуждать тогда, когда твоя программа, скомпилённая gcc под генту сможет импортировать и выполнить функции из 32х-битной виндовой DLL.

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

G>Более чудовищной рекламы Qt сделать невозможно. Lightroom это такая кошмарно тормозящая поделка с подглючивающим интерфейсом, что как пример хоть чего-либо ее лучше не приводить.

Лайтрум прекрасен и уж точно не тормозит. Другое дело что от QT в плане UI там остались рожки да ножки. И то что осталось ничего кроме раздражения не вызывает, уж не знаю чья в том заслуга, Qt или адобовских юзабилистов.

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

CC>Загрузчик не производит ни компиляцию ни JIT ничего что генерило бы непосредственно финальный бинарь.
C моей точки зрения неважно, какова степень преобразования бинаря при загрузке. "Голый" .exe запустить на железке невозможно, будь он управляемым или неуправляемым.

Здравствуйте, Ночной Смотрящий, Вы писали:

G>>Более чудовищной рекламы Qt сделать невозможно. Lightroom это такая кошмарно тормозящая поделка с подглючивающим интерфейсом, что как пример хоть чего-либо ее лучше не приводить.
НС>Лайтрум прекрасен и уж точно не тормозит.

Конечно. именно поэтому на сайте адоба есть прекрасная статья "как ускорить работу лайтрума". И эта шедевральная статья дает два совета — поменьше пользоваться функционалом программы и купить комп помощнее.

НС>Другое дело что от QT в плане UI там остались рожки да ножки. И то что осталось ничего кроме раздражения не вызывает, уж не знаю чья в том заслуга, Qt или адобовских юзабилистов.

Лайтрум прекрасен как раз в юзабилити, в эргономике, в идеях в него заложенных. А вот исполнение — полный трындец.

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

G>Конечно. именно поэтому на сайте адоба есть прекрасная статья "как ускорить работу лайтрума". И эта шедевральная статья дает два совета — поменьше пользоваться функционалом программы и купить комп помощнее.

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

G>Лайтрум прекрасен как раз в юзабилити, в эргономике, в идеях в него заложенных. А вот исполнение — полный трындец.

В идеях — да. А вот в юзабилити диалогов — полная жопа. Одно окошко параметров экспорта чего стоит.
Ты, кстати, про какую версию говоришь? А то в 3 версии он существенно получшел, да и в 4 хуже точно не стал.

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

1) Nemerle
2) Nemerle
3) C#

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Комп помощнее лайтруму, очевидно, нужен. Там довольно специфичная архитектура, с одной стороны развязывающая руки, с другой стороны неслабо жрущая ресурсы.

Да вот не очевидно. Некоторые вещи, которые казалось бы требуют ресурсов, типа live preview изменений, как раз работают более менее. Не сказать, чтобы быстро, но работать можно. А вот те вещи которые казалось бы тормозить вообще не должны — тормозят.
Например у меня самая долгая операция это доставание превьюхи фото из базы. Если превьюха есть в кэше — две секунды (!!!), если нет — до 5.

Это блин в 21 веке, база на 100тысяч превьюх. Причем различные эксперименты показывают, что скачок по времени доступа где-то в районе нескольких тысяч превьюх.

Это не касательно именно UI. В котором свои фишки. Переключение Library->Develop занимает до 10 секунд. Да за такое ссаными тряпками из профессии надо гнать.

Самое прикольное, что Qt с коорого все началось тут скорее всего не при чем. Но будь Lightroom написан на C# — ох вою бы поднялось про тормознутость .Net

НС>Но мой не первой свежести десктоп с библиотеками в десятки тысяч равов справляется играючи. Разве что экспорт медленно работает, но он работает в фоне и нужен нечасто.



G>>Лайтрум прекрасен как раз в юзабилити, в эргономике, в идеях в него заложенных. А вот исполнение — полный трындец.
НС>В идеях — да. А вот в юзабилити диалогов — полная жопа. Одно окошко параметров экспорта чего стоит.
НС>Ты, кстати, про какую версию говоришь? А то в 3 версии он существенно получшел, да и в 4 хуже точно не стал.

про 4. окошко параметров экспорта фигня, настроил пяток пресетов и больше туда заходить не приходится.

приятнее всего просто на СИ, решать задачки из глав всем известного учебника по этому языку.
а приходится на си#

Не знаю как так получилось, но на текущий момент это факт. Так что программировать приятно сейчас нельзя в принципе. Я не говорю о программировании драйверов на чистом С (это удел немногих), я говорю о программировании прикладных задач. Если вы захотите написать сапровскую программу, то обнаружите, что С++ помимо архитектурных заморочек не имеет нормальной библиотеки для построения windows приложений. Qt не вспоминать. Qt только с виду нормальная библиотека, а на самом деле не развитая. И глючная! Кто вспомнит о MFC тому мы вызовем 03 Работа с аппаратно ускоренной графикой не в полноэкранном режиме тоже тот ещё геморрой. Вот и получается, что программист на С++ похож на того строителя дома, которому, как оказалось, нужно построить сначала кирпичный завод.
Про дот нет скажу одно: оно для чего создано? Единственное место применение дот нету — клепать web приложения для ввода заявок. Настольное windows приложение (сапровское или бухгалтерское) никто еще не написал. Ни один человек, ни одна фирма. Предполагаю, что сейчас раздадутся крики про Autocad. Докладываю: я работал с Autocadom начиная с 10 версии под DOS и заканчивая 14 под винду. То, что сотворили с автокадом сейчас с его ужасным, тупым риббоном на нете — это... это... да за это надо по рукам бить. так что регресс и деградация по всем направлениям.
Единственное, что позволяет быстро и легко создавать более — менее качественные приложения для работы с данными — это 1С. Поэтому 1С и применяется для построения 99,9999999999999 % учётных систем в России и за рубежом. Но в 1С есть существенный недостаток — тормоза.

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

...

Чувак, нет слов...

Что-то вспомнился язык RS.

Интересно, как он там поживает.