M>>Брось и не начинай. Это уже было пройдено по кругу минимум два раза.
S>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно. Например вот тебе хоть ВороньяБД
Здравствуйте, Mamut, Вы писали:
M>>>Брось и не начинай. Это уже было пройдено по кругу минимум два раза.
S>>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно. Например вот тебе хоть ВороньяБД
M>Покажи мне, как из "кроссплатформенного" Qt соберется даже простейшее приложение под Windows или МакОС, если следовать, например, туториалу. Ну или приложение типа такого, такого или такого.
Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно.
Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
К тому же YaRock скорее всего соберется ибо пхонон это чать кутэ а не чтото внешнее. Впрочем, оно еще хочет libtag1 — лень смотреть в нее, есть вероятность что все получится.
Кстати, Antico тоже скорее всего соберется, ибо кроме кутэ ничего больше не хочет в зависимости.
M>Хотя твой ответ, безусловно, предсказуем.
Не спеши.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sheridan, Вы писали:
S>>В принципе отчасти ты прав. В силу своей кроссплатформенности моно несколько более жив, чем дотнет. Но до тогоже ц++ далеко обоим.
IT>Твои попытки потролить .NET ничтожны.
Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
Здравствуйте, Sheridan, Вы писали:
S>Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
Как насчёт зашоренности незашоренностью?
Если нам не помогут, то мы тоже никого не пощадим.
S>Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно. S>Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
Тогда почему же ты предлагаешь мне скомпилировать приложение, заточенное под винду?
Хотя, как оказалось, RavenDB вполне себе бегает на Mono, то есть никаких препятствий к тому, чтобы его можно бло собирать под Mono, нет. И какой-то скрипт все же существует. Видно, что процесс сборки включает в сбя всякие доп. тулзы, которых в Линуксах может и не быть. Ах, какая досада. Ведь для того же сверхсуперпупуркроссплатформенного С++ всегда все тулзы доступны для всех платформ, агагагага.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>Так как это было обсосано два-три года тому назад, ссылки (на удивление мало тебя): M>>http://rsdn.ru/forum/flame.comp/3899857.1.aspx
Здравствуйте, Иван Дубров, Вы писали:
Ф>>Я так думаю, что именно для этого она и задумывалась — типа компиляция для того проца, который сейчас установлен. Однако, практика показала, что решения без JIT быстрее, а там, где нужна оптимизация под проц, она делается руками.
ИД>Если брать ту же Java, проблема её производительности, я думаю, совсем не из-за байткода. Вон тот же LLVM с правильно выбранным языком генерирует вполне нормальный код (ну, пока отстаёт местами от GCC, но сколько лет LLVM, а сколько GCC?). Проблема в том, что JVM задаёт очень фиксированную модель выполнения, на которую прикладные задачи накладываются не оптимально. Добавь сюда ещё проверки в рантайме и жор памяти для поддержки всей этой системы и получишь тормоза.
А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
Здравствуйте, Kingofastellarwar, Вы писали: K>или для динамической компиляции? а кто ее использует?
Чуть более, чем все. Весь интернет — это либо чудовищный тормоз интерпретации (читай PHP, ASP), либо динамическая компиляция (ASP.NET, JSP). Вообще, там, где она доступна, динамическая компиляция используется в полный рост — те же регекспы очень сильно от неё выигрывают.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
S>>Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно. S>>Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
M>Тогда почему же ты предлагаешь мне скомпилировать приложение, заточенное под винду?
Под дотнет.
M>Хотя, как оказалось, RavenDB вполне себе бегает на Mono, то есть никаких препятствий к тому, чтобы его можно бло собирать под Mono, нет. И какой-то скрипт все же существует.
Я взял первый попавшийся проект, наугад. Или ты будешь возражать что найдутся дотнет проекты не собирающиеся под моно и наоборот?
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, Sheridan, Вы писали:
S>>Здравствуйте, Mamut, Вы писали:
M>>>Так как это было обсосано два-три года тому назад, ссылки (на удивление мало тебя): M>>>http://rsdn.ru/forum/flame.comp/3899857.1.aspx
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть.
Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
Нет уж, тут котят от котлет не отделишь. Есть дотнет. Есть моно. Это не одно и тоже.
Здравствуйте, Mamut, Вы писали:
S>>Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
M>О да, по маковым полям ты у нас ксперт — ты ведь из них не вылезаешь
Эй, ты уверен что сам не подсел? Вообщето пока что еще зима.
Здравствуйте, vsb, Вы писали:
vsb>А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
Например, можно представить разницу в представлении понятия "объект типа точка с двумя координатами" в ранайме, в C++ и в Java. А ещё лучше -- массив точек.
В C++ это будет, грубо говоря, память для массива + немного памяти для хранения кода методов класса "точка". Вызов метода "точки" из массива -- простейшая арифметика указателей и вызов функции.
В Java ты получишь расходы памяти и дополнительные инструкции для поддержания семантики JVM (GC, исключения, безопасность, рефлекшн, и.т.д).
При этом у тебя нет никакой возможности реализовать "легковесную" "точку", которой всё это не нужно. То есть JVM, конечно, попытается сделать какие-то оптимизации, но она всё равно достаточно ограничена в возможностях. Как-то так.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Здравствуйте, vsb, Вы писали:
vsb>>А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
ИД>Например, можно представить разницу в представлении понятия "объект типа точка с двумя координатами" в ранайме, в C++ и в Java. А ещё лучше -- массив точек.
ИД>В C++ это будет, грубо говоря, память для массива + немного памяти для хранения кода методов класса "точка". Вызов метода "точки" из массива -- простейшая арифметика указателей и вызов функции.
ИД>В Java ты получишь расходы памяти и дополнительные инструкции для поддержания семантики JVM (GC, исключения, безопасность, рефлекшн, и.т.д).
По расходу памяти — согласен. По дополнительным инструкциям — опять же интересно посмотреть, насколько они влияют на производительность реальных алгоритмов. По-моему не очень сильно влияют. Безопасность проверяется при загрузке класса, во время выполнения никаких проверок не должно быть. Рефлекшн это просто метаинформация.
ИД>При этом у тебя нет никакой возможности реализовать "легковесную" "точку", которой всё это не нужно. То есть JVM, конечно, попытается сделать какие-то оптимизации, но она всё равно достаточно ограничена в возможностях. Как-то так.
Если необходимо оптимизировать по памяти этот случай — можно использовать конструкцию вроде
int[] x;
int[] y;
или
long[] xy;
В итоге дополнительных расходов порядка O(N) не будет. Семантика, конечно, другая.
Вообще принято считать, что память нынче дешёвая и для многих приложений так и есть. Памяти всегда можно добавить до каких-то разумных пределов, конечно, вот процессор "добавить" уже сложно, если тормозит, то тормозит. Поэтому интереснее именно тормоза процессора.
Здравствуйте, FR, Вы писали:
G>>Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
FR>Ну с LLVM вполне реально, пока скорее в теории, на практике только недостаток библиотек не дает.
Никто этим заниматься никогда не планировал, ибо в общем то никому не надо. "Virtual Machine" в название случайно как-то вкралось )
Здравствуйте, Иван Дубров, Вы писали:
K>>код запускался бы сразу без JIT компиляции и тормозов с ней связанной и можно было бы делать реальную оптимизацию кода компилятором выжимать максимум.
ИД>Чем позже делается компиляция -- тем больше возможностей для оптимизации. Не зря в GCC LTO придумали.
LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
Здравствуйте, esil, Вы писали:
ИД>>Чем позже делается компиляция -- тем больше возможностей для оптимизации. Не зря в GCC LTO придумали.
E>LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
А к чему это имеет отношение? Это способ делать некоторые оптимизации в момент, когда становится доступна некоторая информаци. Вот, прям с их wiki:
>Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time).
Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
Здравствуйте, Иван Дубров, Вы писали:
E>>LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
ИД>А к чему это имеет отношение? Это способ делать некоторые оптимизации в момент, когда становится доступна некоторая информаци. Вот, прям с их wiki:
>>Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time).
LTO — это способ выполнять межпроцедурные оптимизации на всей программе (а не по-модульно). Именно это и сказано у них в wiki. Фраза "делать компиляцию как можно позже" — это спекуляция, потому что на самом деле компиляция делается не раньше и не позже, она просто делается на всей программе, а не на каждом модуле отдельно.
ИД>Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
Здравствуйте, esil, Вы писали:
E>LTO — это способ выполнять межпроцедурные оптимизации на всей программе (а не по-модульно). Именно это и сказано у них в wiki. Фраза "делать компиляцию как можно позже" — это спекуляция, потому что на самом деле компиляция делается не раньше и не позже, она просто делается на всей программе, а не на каждом модуле отдельно.
ИД>>Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
E>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
Да, это у меня фантазия, похоже, разыгралась.
Но вообще Java умеет Там, правда, нет разделения "статических" библиотек и "динамических", но заинлайнить метод идущий из класса, который был загружен уже в процессе работы (например, какой-то плагин) -- она может.
Если нам не помогут, то мы тоже никого не пощадим.
