Здравствуйте, vdimas, Вы писали:
V>·>Там ровно одна куча для объектов. Есть другие блоки памяти, которые JVM может запросить у операционки (т.е. из нативной кучи) V>Нейтивная куча не обслуживается операционкой.
Под нативной кучей я здесь понимаю malloc/new, который в итоге просит память у операционки.
V>>>Не бывает. )) V>>>У операционки с защищённой памятью всегда аллоцируется сначала адресное пространство, а потом коммитится, по мере надобности, её отображение на физическую память. V>·>Ещё раз повторяю. В zing используется специальный ядреный модуль, который выделяет память прямо в _физической_ памяти, минуя виртуальную память операционки (чтобы исключить влияние оперционки на обращения к памяти, т.к. page faults создают latency spikes). V>Еще раз, ты говоришь мега-ерунду. Процессор I386-й не умеет в защищённом режиме работать с плоской памятью из юзверского (3-го в современных операционках) кольца.
Поэтому модуль ядерный и сделан.
V>Поэтому, речь может идти, разве что, об операции commit сразу после alloc и затем VirtualLock. В виндах это можно делать и без ядерного модуля — первые две операции делаются за один вызов VirtualAlloc (подав дополнительно флаг MEM_COMMIT), а потом можно прочитать прочитав хотя бы по одному байту с каждой выделенной страницы, чтобы заведомо раздать физическую память виртуальным адресам (до следующего свопа) или же вызывать VirtualLock, запретив своп этих страниц. Но это всё-равно будет несколько последовательных операций, чудес не бывает.
V>Возможно, твой ядерный модуль делает сие не за два вызова, а не за один, но это смешная оптимизация, ведь характер выделения страниц — он однократный, считай. Чиста для инфы — в линухах есть аналогичные mlock/munlock, т.е. ты или не разобрался в происходящем, или выдаёшь инженерные курьёзы за сакральности.
V>В любом случае, в современных процессорных узлах столько памяти, что своп тупо отключают и всё описанное становится не более чем бесполезным фетишем, бо оно и так в точности аналогично работает в отсутствии свопа.
Я подробностей не знаю почему именно они не использовали стандартный api.
V>>>https://msdn.microsoft.com/en-us/library/windows/desktop/aa366599(v=vs.85).aspx V>·>И как там можно расположить ява-объекты? V>А как они вообще в памяти располагаются? Вот точно так же.
Да пофиг, детали имплементации. Вот это: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"" — всё равно лажа. Причём тут крупность объектов?!
V>Самому сложно было посмотреть?
И что? Это конкретная оракловая имплеметация. Как и где оно располагается скажем, в zing — детали реализации. Там у них zing-memory сервис есть, который этим рулит.
V>>>Для Джавы и дотнета они неразрывные. V>·>Ими можно крутить независимо. Не знаю на счёт дотнета, но в яве дефрагметацию можно просто отключить. V>Тогда GC будет жутко тормозить на выделении через некоторое время после начала работы.
Или не будет, смотря как написано и работает приложение — как оно делает выделение объектов.
V>>>Я ничего не путаю и в LOH никаких особенностей нет, — это обычная куча как куча, которая в современных менеджерах памяти представлена деревом на основе бинарного представления части адреса объекта. Просто конкретно MS дала этой куче название в своей реализации GC, чтобы как-то отделить, сугубо терминологически, её от основной кучи GC. V>·>Конечно нет, если не считать особенностью то, что в java нет LOH, по крайней мере в оракловой VM. V>Нет названия LOH, ты хотел сказать. V>Мы о названии сейчас спорим, я правильно тебя понял? V>Тогда я сразу сдаюсь. ))
Нет никакой особой "честной" кучи. В java куча одна — Java Heap — память под неё может быть изначально зарезервирована в физических страницах при запуске. Далее идёт разные подходы gc, наиболее часто используемый — generational gc, где хип делится на поколения (области), и в зависимости от всяческих условий некоторые выделения могут происходить в разных поколениях.
V>·>Где такое про джаву пишут? V>Тут: V>http://www.rsdn.org/forum/flame.comp/6589682
Т.е. ты опять всё напутал. Никакой ни "честный образ", ни нативный аллокатор, а выделение из OG. И то при соблюдении некоторого ряда условий, зависящих от имплементации JVM и её настроек при запуске.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Как бы OpenGL ничем не хуже DirectX
Уже заметно похуже 12-го DX, Mantle или Vulkan (последний OpenCL).
Всё, забудь про OpenGL, нет его.
_>Ну т.е. понятно что надо переписать немного кода, но для такой конторы как MS это очевидно не проблема. Если бы было соответствующее желание...
Дык, вот и переписали DX полностью с 0-ля, выбросив из него кучу legacy.
Ну и современные графические программы редко пишутся на хардкорном DX или OGL, чаще через некую высокоуровневую библиотеку, многие из которых являются адаптерами и одинаково хорошо компилятся как под DX, так и под другие АПИ.
Здравствуйте, Serginio1, Вы писали:
_>>С чего это ты взял? Мы говорили о ненужности платформы UWP. .Net тут вообще никто не упоминал. А ненужность следует из того факта, что на win10 можно спокойно запускать win32 приложения, а на win7 (самой популярной десктопной ОС в данный момент) UWP приложения запускать нельзя. И от языка программирования это никак не зависит. S> Это твои фантазии. Посмотри на название ветки. Изначально я говорил о .Net
Если ты говоришь о .Net, тогда непонятно зачем ты отвечаешь на мои сообщения — я то обсуждаю исключительно UWP, вне привязки к инструменту разработки.
S> Так вот люди прекрасно зарабатывают на XBOX. И для них можно делать приложения на UWP.
Можно не означает что нужно. Ты вот тупо уже которое сообщение не можешь понять этот простейший факт.
S> А ну да. То есть программировать вообще не нужно все есть. S> Ты ссылки не читаешь. Тот же Paint, Офис, Skype они все и под UWP в том числе. S>https://www.microsoft.com/en-in/store/p/skype/9wzdncrfj364
Ну если бы ещё и сама MS не использовала пропагандируемую ею же платформу, то это было бы уже совсем смешно. Хотя... Как там, VisualStudio уже выпущена в формате UWP? Ну или SQL Server например.
S> Перделать WPF приложение сейчас есть инструменты. А программировать на C# одно удовольствие. Так, что сними очки. Есть смысл программировать под магазин. Статистику я тебе привел. Причем зарабатывают в основном на рекламе и прочих покупках. S> Так, что пишут и будут писать больше, особенно учитывая возможность преобразования классических приложений для Windows (например, Win32, WPF и Windows Forms) в приложение для универсальной платформы Windows (UWP) с помощью расширений для преобразования классических приложений.
Ты вот пишешь уже какое сообщение, но так и не смог осилить ответ на мой изначальный простейший вопрос: ЗАЧЕМ? Точнее у тебя была одна микропопытка, когда ты пытался заявить в плюсы UWP распространение через магазин, но ты же сам сразу понял её неудачность, когда узнал что через магазин можно распространять и не UWP приложения. Так что, ещё хоть одна попытка будет или я фиксирую слив? )
S>Опять же о том, что никто не пишет S>http://ffin.ru/market/future/50153/ S>Примером может служить американская компания PicsArt, предлагающая приложение для редактирования фотографий. Ранее в PicsArt пробовали кросс-платформенные решения от Microsoft, но при этом все равно приходилось поддерживать несколько вариантов приложения. С UWP и Windows 10 впервые удалось создать единый программный пакет, который работает на всех платформах. Благодаря этому 65-миллионная аудитория с момента выпуска нового пакета в декабре 2015 г. каждый месяц привлекает сотни тысяч новых пользователей Windows. Проще говоря, с UWP производители с помощью одного набора софта потенциально имеют потребительский рынок в сотни миллионов пользователей операционных систем от Microsoft. S> S>Источник: http://ffin.ru/market/future/50153/#ixzz4OZsZ42aN
Информация для умственно отсталых, т.к. аудитория обычных приложений априори шире чем UWP, т.к. включает в себе самую популярную на данный момент десктопную ОС (win7). Т.е. от замены обычного приложения на UWP можно получить только сокращение потенциальной аудитории, причём в разы.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Тут такое дело, когда речь идёт о С++ НС>Мне вот интересно — что с вами не так, что вы влазите в половину топиков и начинаете обсуждать С++?
Не буду отвечать за Евгения, но вот например я практически никогда не притаскиваю обсуждение C++ в темы не про него — мне обычно и так есть что сказать по непосредственной теме. Но почему-то другой народ обязательно притаскивает C++ в совершенно не касающиеся его темы (конкретно в данном топике это зачем-то сделал vdimas). И вот когда начинаются неверные рассуждения о C++, то тут уже можете гарантированно ждать нас.
Т.е. в данном предположение у тебя перепутаны причины и следствия.
Здравствуйте, vdimas, Вы писали:
_>>Как бы OpenGL ничем не хуже DirectX V>Уже заметно похуже 12-го DX, Mantle или Vulkan (последний OpenCL). V>Всё, забудь про OpenGL, нет его.
Для реализации GUI хватит и DX/OpenGL 15-и летней давности.
_>>Ну т.е. понятно что надо переписать немного кода, но для такой конторы как MS это очевидно не проблема. Если бы было соответствующее желание... V>Дык, вот и переписали DX полностью с 0-ля, выбросив из него кучу legacy. V>Ну и современные графические программы резко пишутся на хардкорном DX или OGL, чаще через некую высокоуровневую библиотеку, многие из которых являются адаптерами и одинаково хорошо компилятся как под DX, так и под другие АПИ.
И какое это имеет отношение к обсуждаемому вопросу реализации WPF на Linux?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>С чего это ты взял? Мы говорили о ненужности платформы UWP. .Net тут вообще никто не упоминал. А ненужность следует из того факта, что на win10 можно спокойно запускать win32 приложения, а на win7 (самой популярной десктопной ОС в данный момент) UWP приложения запускать нельзя. И от языка программирования это никак не зависит. S>> Это твои фантазии. Посмотри на название ветки. Изначально я говорил о .Net
_>Если ты говоришь о .Net, тогда непонятно зачем ты отвечаешь на мои сообщения — я то обсуждаю исключительно UWP, вне привязки к инструменту разработки.
UWP это в том числе и .Net http://metanit.com/sharp/uwp/ и на нем действительно легко писать, в отличие от С++.
S>> Так вот люди прекрасно зарабатывают на XBOX. И для них можно делать приложения на UWP.
_>Можно не означает что нужно. Ты вот тупо уже которое сообщение не можешь понять этот простейший факт.
Так ведь куча приложений в магазине. И я приводил ссылки на количество скачиваний и доходов. S>> А ну да. То есть программировать вообще не нужно все есть. S>> Ты ссылки не читаешь. Тот же Paint, Офис, Skype они все и под UWP в том числе. S>>https://www.microsoft.com/en-in/store/p/skype/9wzdncrfj364
_>Ну если бы ещё и сама MS не использовала пропагандируемую ею же платформу, то это было бы уже совсем смешно. Хотя... Как там, VisualStudio уже выпущена в формате UWP? Ну или SQL Server например.
SQL Server есть для линукс. Но ты то говришь, что никто не пишет. S>> Перделать WPF приложение сейчас есть инструменты. А программировать на C# одно удовольствие. Так, что сними очки. Есть смысл программировать под магазин. Статистику я тебе привел. Причем зарабатывают в основном на рекламе и прочих покупках. S>> Так, что пишут и будут писать больше, особенно учитывая возможность преобразования классических приложений для Windows (например, Win32, WPF и Windows Forms) в приложение для универсальной платформы Windows (UWP) с помощью расширений для преобразования классических приложений.
_>Ты вот пишешь уже какое сообщение, но так и не смог осилить ответ на мой изначальный простейший вопрос: ЗАЧЕМ? Точнее у тебя была одна микропопытка, когда ты пытался заявить в плюсы UWP распространение через магазин, но ты же сам сразу понял её неудачность, когда узнал что через магазин можно распространять и не UWP приложения. Так что, ещё хоть одна попытка будет или я фиксирую слив? )
S>>Опять же о том, что никто не пишет S>>http://ffin.ru/market/future/50153/ S>>Примером может служить американская компания PicsArt, предлагающая приложение для редактирования фотографий. Ранее в PicsArt пробовали кросс-платформенные решения от Microsoft, но при этом все равно приходилось поддерживать несколько вариантов приложения. С UWP и Windows 10 впервые удалось создать единый программный пакет, который работает на всех платформах. Благодаря этому 65-миллионная аудитория с момента выпуска нового пакета в декабре 2015 г. каждый месяц привлекает сотни тысяч новых пользователей Windows. Проще говоря, с UWP производители с помощью одного набора софта потенциально имеют потребительский рынок в сотни миллионов пользователей операционных систем от Microsoft. S>> S>>Источник: http://ffin.ru/market/future/50153/#ixzz4OZsZ42aN
_>Информация для умственно отсталых, т.к. аудитория обычных приложений априори шире чем UWP, т.к. включает в себе самую популярную на данный момент десктопную ОС (win7). Т.е. от замены обычного приложения на UWP можно получить только сокращение потенциальной аудитории, причём в разы.
Еще раз для умственно не отсталых. Есть инструменты для перевода приложений
Перделать WPF приложение сейчас есть инструменты. А программировать на C# одно удовольствие. Так, что сними очки. Есть смысл программировать под магазин. Статистику я тебе привел. Причем зарабатывают в основном на рекламе и прочих покупках.
Так, что пишут и будут писать больше, особенно учитывая возможность преобразования классических приложений для Windows (например, Win32, WPF и Windows Forms) в приложение для универсальной платформы Windows (UWP) с помощью расширений для преобразования классических приложений.
При небольших затратах ты можешь превратить свое Win32 приложение в UWP. А достоинства магазина я уже приводил.
То евсе настолько ленивы, что им использовать Desktop App Converter в лом?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Для реализации GUI хватит и DX/OpenGL 15-и летней давности.
Тормоза + неудобство программирования.
V>>Ну и современные графические программы резко пишутся на хардкорном DX или OGL, чаще через некую высокоуровневую библиотеку, многие из которых являются адаптерами и одинаково хорошо компилятся как под DX, так и под другие АПИ. _>И какое это имеет отношение к обсуждаемому вопросу реализации WPF на Linux?
WPF абстрагировано от DX с т.з. разработчика.
Ничто не мешает реализовать его на Linux.
Было бы желание вложить в это бабло.
Здравствуйте, alex_public, Вы писали:
S>>Есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками https://github.com/picoe/Eto _>Хыхы, попытка работать через нативные контролы на всех платформах — некое слабое подобие wxWidgets.
В линухах контролы нифига не нативные. Они всегда библиотечные.
_>Лично мне такой подход очень нравится идеологически, но к сожалению он вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида.
Контролы в Андроиде реализованы в нейтиве.
А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная.
_>Если MS этого не делает, то это означает просто не желание предоставлять полноценный .net на другие платформы.
Сервелат полноценно пашет под маком.
_>Двойного повтора этого тезиса достаточно тебе для понимания? Или пойдём на третий круг? )
Здравствуйте, ·, Вы писали:
V>>·>Там ровно одна куча для объектов. Есть другие блоки памяти, которые JVM может запросить у операционки (т.е. из нативной кучи) V>>Нейтивная куча не обслуживается операционкой. ·>Под нативной кучей я здесь понимаю malloc/new, который в итоге просит память у операционки.
Не просит.
V>>Еще раз, ты говоришь мега-ерунду. Процессор I386-й не умеет в защищённом режиме работать с плоской памятью из юзверского (3-го в современных операционках) кольца. ·>Поэтому модуль ядерный и сделан.
Для понтов он сделан.
Эту память невозможно будет использовать напрямую в джава-программе, только через виртуальный механизм.
V>>В любом случае, в современных процессорных узлах столько памяти, что своп тупо отключают и всё описанное становится не более чем бесполезным фетишем, бо оно и так в точности аналогично работает в отсутствии свопа. ·>Я подробностей не знаю почему именно они не использовали стандартный api.
Но ты же подаешь сие как аргумент!
Причём, в споре с теми людьми, которые хотя бы в общих чертах представляют себе механизм работы защищённой памяти.
·>Да пофиг, детали имплементации. Вот это: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"" — всё равно лажа. Причём тут крупность объектов?!
При том, что их дорого копировать.
Поэтому, их выделяют в ДРУГОЙ куче. В той куче, которую НЕ будут уплотнять, т.е. дефрагментировать. Т.е. это ДРУГОЙ набор страниц и чаще всего в ДРУГОМ адресном пространстве. Последнее важно, т.к. даёт возможность расти "кучам GC" при необходимости.
Кароч, способы выделения в таких кучах исследованы давно и применяются как раз в нейтивных программах. Устройство такой кучи весьма и весьма специфическое — каждый пул из неё располагается в правильно выравненных адресах, потому что управление такой кучей происходит по части адреса объекта. Для сравнения, куче GC никакое специфическое расположение в адресном пространстве НЕ требуется.
Т.е., ты видишь, как много происходит последствий всего лишь от того, что объект НЕ будет перемещаться в памяти в результате работы GC?
V>>Самому сложно было посмотреть? ·>И что? Это конкретная оракловая имплеметация. Как и где оно располагается скажем, в zing — детали реализации. Там у них zing-memory сервис есть, который этим рулит.
Для больших объектов zing этим всем не рулит нифига. Ты вообще читал те ссылки, что сам же давал?
Фишка zing — в создании копий объектов в ДРУГИХ страницах памяти, вместо их перемещения в СУЩЕСТВУЮЩИХ.
Большие объекты он не копирует.
Далее.
Образующиеся пустые страницы памяти из под перенесённых (скопированных) объектов помечаются объявляются как no-read/no-write.
Zing декларирует, что исключает стадию "stop the word", но эта стадия в других GC нужна как раз для обновления ссылок на объекты при их перемещении.
Вместо "stop the word" zing не делает нихрена после создания копии страниц. Вместо этого он перехватывает access violation уже при попытке доступа к таким объектам по устаревшим ссылкам, затем возвращается по стеку, делает дизассемблинг происходящего (условно назовём так) чтобы понять, "кто" обратился к этой странице и правит ссылки в регистрах, стеке или полях объектов в памяти.
Вот почему zing так медленно работает. Он не просто "размазывает" стоимость обновления ссылок, он, сцуко, делает это обновление жутко дорогим в пересчёте на ссылку. Кароч, опять и снова, никакой серебрянной пули не вышло.
V>>·>Ими можно крутить независимо. Не знаю на счёт дотнета, но в яве дефрагметацию можно просто отключить. V>>Тогда GC будет жутко тормозить на выделении через некоторое время после начала работы. ·>Или не будет, смотря как написано и работает приложение — как оно делает выделение объектов.
Если ты начинаешь плясать вокруг выделений памяти в джава, то джава становится резко не нужна. ))
V>>·>Конечно нет, если не считать особенностью то, что в java нет LOH, по крайней мере в оракловой VM. V>>Нет названия LOH, ты хотел сказать. V>>Мы о названии сейчас спорим, я правильно тебя понял? V>>Тогда я сразу сдаюсь. )) ·>Нет никакой особой "честной" кучи.
Есть обязательно.
·>В java куча одна — Java Heap — память под неё может быть изначально зарезервирована в физических страницах при запуске.
Это дело терминологии для обозначения абстракций. Тебя терминология сбивает с толку, как я посмотрю. А я говорил не об абстракциях, а о том, как это работает. С т.з. программиста, действительно, нет никакой разницы, из какой кучи был выделен объект. Для программиста на Джаве все эти подробности не существуют. Точно так же как для программиста на Дотнет. Но при этом LOH существует, ы-ы-ы.
·>Далее идёт разные подходы gc, наиболее часто используемый — generational gc, где хип делится на поколения (области), и в зависимости от всяческих условий некоторые выделения могут происходить в разных поколениях.
Без поколений вообще всё печально становится.
V>>http://www.rsdn.org/forum/flame.comp/6589682 ·>Т.е. ты опять всё напутал. Никакой ни "честный образ", ни нативный аллокатор, а выделение из OG. И то при соблюдении некоторого ряда условий, зависящих от имплементации JVM и её настроек при запуске.
Бла-бла-бла.
Тут уже смешно даже не то, что ты ни в зуб ногой по теме, а что фанатично сопротивляешься попыткам узнать — а как оно на само деле-то?
Кароч, редко на этом форуме встретишь именно воинствующее невежество. Тебе удалось меня удивить. ))
При желании, сцену можно описать в Shared Projects или PCL и сделать ее доступной сразу ко всему ряду поддерживаемых платформ:
•iOS, tvOS (в виде UIView)
•macOS (Cocoa, в виде NSView)
•UWP, WPF, WinForms (в виде контрола)
•Android (SurfaceView виджет)
•Xamarin.Forms
•Планируется: Google Cardboard, Daydream, Oculus, Vive
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>>>·>Там ровно одна куча для объектов. Есть другие блоки памяти, которые JVM может запросить у операционки (т.е. из нативной кучи) V>>>Нейтивная куча не обслуживается операционкой. V>·>Под нативной кучей я здесь понимаю malloc/new, который в итоге просит память у операционки. V>Не просит.
А откуда он её берёт?
А ещё например, запуск треда берёт память у операционки под стек.
V>>>Еще раз, ты говоришь мега-ерунду. Процессор I386-й не умеет в защищённом режиме работать с плоской памятью из юзверского (3-го в современных операционках) кольца. V>·>Поэтому модуль ядерный и сделан. V>Для понтов он сделан. V>Эту память невозможно будет использовать напрямую в джава-программе, только через виртуальный механизм.
Путь для понтов. Суть не в этом. Суть в том, что Java Heap может быть не связана никак с нативной кучей.
V>>>В любом случае, в современных процессорных узлах столько памяти, что своп тупо отключают и всё описанное становится не более чем бесполезным фетишем, бо оно и так в точности аналогично работает в отсутствии свопа. V>·>Я подробностей не знаю почему именно они не использовали стандартный api. V>Но ты же подаешь сие как аргумент!
Как аргумент чего? Мой аргумент — Java Heap не всегда зависит от нативной кучи и прочим VirtualAlloc.
V>Причём, в споре с теми людьми, которые хотя бы в общих чертах представляют себе механизм работы защищённой памяти.
Ты внезапно с нативной кучи перелез на защищённую память. Я уж потерялся в том что именно ты пытаешься доказать.
V>·>Да пофиг, детали имплементации. Вот это: "Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом"" — всё равно лажа. Причём тут крупность объектов?! V>При том, что их дорого копировать. V>Поэтому, их выделяют в ДРУГОЙ куче.
Ещё раз повторяю. В Java нет никакой "ДРУГОЙ кучи". Есть одна единственная Java Heap. Если у тебя другое мнение — подркепи его ссылками.
V>В той куче, которую НЕ будут уплотнять, т.е. дефрагментировать. Т.е. это ДРУГОЙ набор страниц и чаще всего в ДРУГОМ адресном пространстве. Последнее важно, т.к. даёт возможность расти "кучам GC" при необходимости.
Это только в C# не было дефрагметации, что вызывало серьёзные проблемы:
I've had managers point to LOH fragmentation as justification for choosing some other technology
И они наконец-то пофиксили начиная с 4.5.1: LargeObjectHeapCompactionMode
V>Кароч, способы выделения в таких кучах исследованы давно и применяются как раз в нейтивных программах. Устройство такой кучи весьма и весьма специфическое — каждый пул из неё располагается в правильно выравненных адресах, потому что управление такой кучей происходит по части адреса объекта. Для сравнения, куче GC никакое специфическое расположение в адресном пространстве НЕ требуется.
Ну в нативных кучах выбора нет, компактификация невозможна в принципе.
V>Т.е., ты видишь, как много происходит последствий всего лишь от того, что объект НЕ будет перемещаться в памяти в результате работы GC?
Ты теперь видишь, надеюсь, что твои убеждения не соответствуют фактам.
V>>>Самому сложно было посмотреть? V>·>И что? Это конкретная оракловая имплеметация. Как и где оно располагается скажем, в zing — детали реализации. Там у них zing-memory сервис есть, который этим рулит. V>Для больших объектов zing этим всем не рулит нифига. Ты вообще читал те ссылки, что сам же давал? V>Фишка zing — в создании копий объектов в ДРУГИХ страницах памяти, вместо их перемещения в СУЩЕСТВУЮЩИХ. V>Большие объекты он не копирует.
Это пенальти low latency, а не zing в частности. Скажем, Sustained LL mode в dotnet имеет ровно тот же недостаток — большее потребление памяти.
V>Далее. V>Образующиеся пустые страницы памяти из под перенесённых (скопированных) объектов помечаются объявляются как no-read/no-write. V>Zing декларирует, что исключает стадию "stop the word", но эта стадия в других GC нужна как раз для обновления ссылок на объекты при их перемещении.
V>Вместо "stop the word" zing не делает нихрена после создания копии страниц. Вместо этого он перехватывает access violation уже при попытке доступа к таким объектам по устаревшим ссылкам, затем возвращается по стеку, делает дизассемблинг происходящего (условно назовём так) чтобы понять, "кто" обратился к этой странице и правит ссылки в регистрах, стеке или полях объектов в памяти. V>Вот почему zing так медленно работает. Он не просто "размазывает" стоимость обновления ссылок, он, сцуко, делает это обновление жутко дорогим в пересчёте на ссылку. Кароч, опять и снова, никакой серебрянной пули не вышло.
А кто эту пулю обещал? LL почти всегда даётся ценой throughput.
V>>>·>Ими можно крутить независимо. Не знаю на счёт дотнета, но в яве дефрагметацию можно просто отключить. V>>>Тогда GC будет жутко тормозить на выделении через некоторое время после начала работы. V>·>Или не будет, смотря как написано и работает приложение — как оно делает выделение объектов. V>Если ты начинаешь плясать вокруг выделений памяти в джава, то джава становится резко не нужна. ))
Мнение. Будто бы в нативных приложениях танцев с памятью не бывает.
V>>>Мы о названии сейчас спорим, я правильно тебя понял? V>>>Тогда я сразу сдаюсь. )) V>·>Нет никакой особой "честной" кучи. V>Есть обязательно.
Ссылку.
V>·>В java куча одна — Java Heap — память под неё может быть изначально зарезервирована в физических страницах при запуске. V>Это дело терминологии для обозначения абстракций. Тебя терминология сбивает с толку, как я посмотрю. А я говорил не об абстракциях, а о том, как это работает. С т.з. программиста, действительно, нет никакой разницы, из какой кучи был выделен объект. Для программиста на Джаве все эти подробности не существуют. Точно так же как для программиста на Дотнет. Но при этом LOH существует, ы-ы-ы.
Ну в Джаве большие объекты в OG выделяются, LOH нет. В dotnet же LOH и OG — разные области памяти. Причём тут термины?
V>>>http://www.rsdn.org/forum/flame.comp/6589682 V>·>Т.е. ты опять всё напутал. Никакой ни "честный образ", ни нативный аллокатор, а выделение из OG. И то при соблюдении некоторого ряда условий, зависящих от имплементации JVM и её настроек при запуске. V>Бла-бла-бла. V>Тут уже смешно даже не то, что ты ни в зуб ногой по теме, а что фанатично сопротивляешься попыткам узнать — а как оно на само деле-то? V>Кароч, редко на этом форуме встретишь именно воинствующее невежество. Тебе удалось меня удивить. ))
Бла-бла только от тебя. Фактов ноль.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Ты вот пишешь уже какое сообщение, но так и не смог осилить ответ на мой изначальный простейший вопрос: ЗАЧЕМ? Точнее у тебя была одна микропопытка, когда ты пытался заявить в плюсы UWP распространение через магазин, но ты же сам сразу понял её неудачность, когда узнал что через магазин можно распространять и не UWP приложения. Так что, ещё хоть одна попытка будет или я фиксирую слив? )
Здравствуйте, vdimas, Вы писали:
V>>>Ну и современные графические программы резко пишутся на хардкорном DX или OGL, чаще через некую высокоуровневую библиотеку, многие из которых являются адаптерами и одинаково хорошо компилятся как под DX, так и под другие АПИ. _>>И какое это имеет отношение к обсуждаемому вопросу реализации WPF на Linux? V>WPF абстрагировано от DX с т.з. разработчика. V>Ничто не мешает реализовать его на Linux. V>Было бы желание вложить в это бабло.
Здравствуйте, vdimas, Вы писали:
_>>Лично мне такой подход очень нравится идеологически, но к сожалению он вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида. V>Контролы в Андроиде реализованы в нейтиве. V>А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная.
О какие интересные новости... Может тогда ещё и подскажешь какой заголовочный файл из NDK подключить, чтобы вызывать функции, создающие стандартные андроидные формочки, менюшки и т.п.? )
_>>Если MS этого не делает, то это означает просто не желание предоставлять полноценный .net на другие платформы. V>Сервелат полноценно пашет под маком.
В 2012 году Microsoft назначила конец жизненного цикла Silverlight 5 на 10 декабря 2021 года. В 2013 году Microsoft объявила, что они прекратили развитие Silverlight, за исключением выпуска исправлений ошибок. Silverlight более не поддерживается в браузерах Opera, Mozilla Firefox, Google Chrome, так как в 2015 году в этих браузерах была отключена по умолчанию или полностью прекращена поддержка плагинов формата NPAPI.
Спасибо, но не надо, некрофилией не увлекаемся. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ты вот пишешь уже какое сообщение, но так и не смог осилить ответ на мой изначальный простейший вопрос: ЗАЧЕМ? Точнее у тебя была одна микропопытка, когда ты пытался заявить в плюсы UWP распространение через магазин, но ты же сам сразу понял её неудачность, когда узнал что через магазин можно распространять и не UWP приложения. Так что, ещё хоть одна попытка будет или я фиксирую слив? )
_>Ок, не ответил, значит фиксируем слив.
Да хоть засливайся. Ты сам так и не ответил.
Есть продукт который переводит Win32 приложения, которые могут покупаться не только для Декстопа но и для мобилок и XBOX и прочих. А это десятки миллионов устройств.
И тебе настолько лениво их переделать по UWP и получать дополнительную прибыль?
Вот сам ответь на этот вопрос хотя бы для себя
Да и можно поподробнее когда это я узнал узнал что через магазин можно распространять и не UWP приложения?
Здравствуйте, Serginio1, Вы писали:
S>Ты сам так и не ответил. S>Есть продукт который переводит Win32 приложения, которые могут покупаться не только для Декстопа но и для мобилок и XBOX и прочих. А это десятки миллионов устройств. S>И тебе настолько лениво их переделать по UWP и получать дополнительную прибыль?
О, неужто пошёл нормальный разговор, а не очередные цитаты маркетингового бреда? ) Тогда ещё можно попробовать пообщаться...
Так я не понял что конкретно ты предлагаешь, добавить выпуск приложения под UWP параллельно с выпуском win32 приложения или же заменить win32 на UWP?
В первом случае получается поддержка дополнительный платформы (а это совсем не дёшево) ради совершенно незначительного числа потенциальных пользователей.
А во-втором случае получается вообще сужение потенциальной аудитории в разы, т.к. UWP не работает на старых версиях винды (которые до сих пор в разы популярнее win10).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Ты сам так и не ответил. S>>Есть продукт который переводит Win32 приложения, которые могут покупаться не только для Декстопа но и для мобилок и XBOX и прочих. А это десятки миллионов устройств. S>>И тебе настолько лениво их переделать по UWP и получать дополнительную прибыль?
_>О, неужто пошёл нормальный разговор, а не очередные цитаты маркетингового бреда? ) Тогда ещё можно попробовать пообщаться...
Я тебе про это и твержу. Но ты не читаешь. _>Так я не понял что конкретно ты предлагаешь, добавить выпуск приложения под UWP параллельно с выпуском win32 приложения или же заменить win32 на UWP?
_>В первом случае получается поддержка дополнительный платформы (а это совсем не дёшево) ради совершенно незначительного числа потенциальных пользователей.
_>А во-втором случае получается вообще сужение потенциальной аудитории в разы, т.к. UWP не работает на старых версиях винды (которые до сих пор в разы популярнее win10).
Еще раз. UWP не работают по win 7, но win32 несложно перенести в UWP? что не ясно?
То есть десятки миллионов (XBOX и WinMO) это совершенно незначительное число? да вы батенька много кушаете.
Народ отдельно для XBOX и WinMO и при этом зарабатывают.
Опять же в магазине проще распространять, а это полмиллиарда
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
V>>В той куче, которую НЕ будут уплотнять, т.е. дефрагментировать. Т.е. это ДРУГОЙ набор страниц и чаще всего в ДРУГОМ адресном пространстве. Последнее важно, т.к. даёт возможность расти "кучам GC" при необходимости. ·>Это только в C# не было дефрагметации, что вызывало серьёзные проблемы: ·>
I've had managers point to LOH fragmentation as justification for choosing some other technology
·>И они наконец-то пофиксили начиная с 4.5.1: LargeObjectHeapCompactionMode ·>Ты теперь видишь, надеюсь, что твои убеждения не соответствуют фактам.
Не надоело еще пальцем в небо? ))
Задачи дефрагментации LOH и основной кучи GC сильно разные.
Для второй дефрагментация нужна для целей быстрого выделения объектов через простой инкремент.
Для первой — для самой возможности выделения объектов.
Например, ты выделил 10 тыс элементов по 100 кБ из LOH (всего гиг), исчерпав его адресное пространство (допустим такое для 32-хразрядной системы).
Затем освободил каждый 4-й элемент. И, хотя у тебя свободной памяти нарисовалось аж четверть гига, вполне может случится так, что ты не сможешь затем выделить элемент размером всего 200 кБ.
·>А кто эту пулю обещал? LL почти всегда даётся ценой throughput.
В нейтиве такого ограничения нет.
V>>Если ты начинаешь плясать вокруг выделений памяти в джава, то джава становится резко не нужна. )) ·>Мнение. Будто бы в нативных приложениях танцев с памятью не бывает.
В нейтиве танцевать с памятью на порядки проще, трудозатраты несравнимы.
·>Ну в Джаве большие объекты в OG выделяются
На твой манер — ссылку?
Они "отправляются в OG", а не выделяются там.
В кавычках — абстрактное (упрощенное) описание происходящего.
На самом деле ничего никуда не отправляется, просто объект так помечается или ссылка на него заносится в некий список GC и т.д.
Здравствуйте, alex_public, Вы писали:
_>>>Лично мне такой подход очень нравится идеологически, но к сожалению он вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида. V>>Контролы в Андроиде реализованы в нейтиве. V>>А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная.
_>О какие интересные новости... Может тогда ещё и подскажешь какой заголовочный файл из NDK подключить,
#include <native_window.h>
Искать по ANativeWindow, ANativeActivityCallbacks, DisplayEventReceiver и т.д.
Рисовать крайне просто:
ANativeWindow* window = ANativeWindow_fromSurface(env, javaSurface);
ANativeWindow_Buffer buffer;
if (ANativeWindow_lock(window, &buffer, NULL) == 0) {
memcpy(buffer.bits, pixels, w * h * 2);
ANativeWindow_unlockAndPost(window);
}
ANativeWindow_release(window);
Не надо жульничать. "Стандартные андроидные менюшки" — это не "родные контролы", это джавовский библиотечный элемент, который рисует пикселы в нативное окно.
_>>>Если MS этого не делает, то это означает просто не желание предоставлять полноценный .net на другие платформы. V>>Сервелат полноценно пашет под маком.
_>
_>В 2012 году Microsoft назначила конец жизненного цикла Silverlight 5 на 10 декабря 2021 года. В 2013 году Microsoft объявила, что они прекратили развитие Silverlight, за исключением выпуска исправлений ошибок. Silverlight более не поддерживается в браузерах Opera, Mozilla Firefox, Google Chrome, так как в 2015 году в этих браузерах была отключена по умолчанию или полностью прекращена поддержка плагинов формата NPAPI.
_>Спасибо, но не надо, некрофилией не увлекаемся.
И опять передёргивание.
До 2021-го года будут исправляться ошибки.
После 2021-го года это будет одна из самых безбаговых платформ, вестимо.
У меня вообще складывается ощущение, что для вас публиковать никакие road maps, потому что вы не понимаете сути публикуемого.
Например, давно в ходу GTK+ 3.0 и уже выходит GTK+ 4, но львиная доля новых приложений под Linux продолжает писаться под GTK+ 2.0
Ветка GTK+ 3 демонстрирует бурное наращивание функциональности, но, к сожалению, ценой низкого уровня стабильности API, что требует от разработчиков приложений постоянной адаптации программ под меняющийся API.
Использование сегодня GTK+ 2 для новых программ, по меркам Сервелата означает примерно 2030-й год (GTK 2.0 от 2002-го года).
Ы?
Здравствуйте, alex_public, Вы писали:
V>>WPF абстрагировано от DX с т.з. разработчика. V>>Ничто не мешает реализовать его на Linux. V>>Было бы желание вложить в это бабло. _>Правильно. Именно это я тут и писал.
В Xamarin вложили, а это родственная технология — тот же самый XAML.
Xamarin теперь идёт в поставке студии.
Диалект чуть другой, но если накидать макет и биндинг мышкой, то остальная часть кода (логика/контроллеры) остаётся практически без изменений.
