Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
а что это было?.. Всмысле интересно, но ничего не понял
Интересно узнать, над чем вы работали, если не секрет, а так же примеры удачного применения Semantic Web.
За удачными примерами — это не ко мне… пока :)
А к кому? )
Кстати, как думаете, вольфрамовский поисковик — это что-то семантическое?
Кстати, как думаете, вольфрамовский поисковик — это что-то семантическое?
>>А к кому? )
Из успешных проектов приходят на ум не какие-либо сервисы, а проекты, помогающие создавать те самые сервисы: Pellet, Big Owlim и т. д. Реальные семантические проекты, на которых зарабатываются деньги.
>>Кстати, как думаете, вольфрамовский поисковик — это что-то семантическое?
Может, их движок внутри и использует что-то семантическое… но вряд ли.
Из успешных проектов приходят на ум не какие-либо сервисы, а проекты, помогающие создавать те самые сервисы: Pellet, Big Owlim и т. д. Реальные семантические проекты, на которых зарабатываются деньги.
>>Кстати, как думаете, вольфрамовский поисковик — это что-то семантическое?
Может, их движок внутри и использует что-то семантическое… но вряд ли.
Интересная статья. Тоже в ближайшее время понадобится инструменты для работы с Онтологиями, а следовательно RDF, OWL и все что с ними связано.
Подход к использованию готовых решений под JAVA выглядит интересным, так как я работаю под .NET/
Зачем это нужно? Например Digital Asset Management.
Кстати у Microsoft уже есть вполне рабочие продукты в этой области, равно как и RDF хранилище построенное на SQL со SPARQL запросами к нему, реализованные в следующем продукте: www.microsoft.com/resources/mediaandentertainment/solutions_imm.mspx
Подход к использованию готовых решений под JAVA выглядит интересным, так как я работаю под .NET/
Зачем это нужно? Например Digital Asset Management.
Кстати у Microsoft уже есть вполне рабочие продукты в этой области, равно как и RDF хранилище построенное на SQL со SPARQL запросами к нему, реализованные в следующем продукте: www.microsoft.com/resources/mediaandentertainment/solutions_imm.mspx
Судя по этой (http://www.intellidimension.com/company/news/#msimm) новости двухгодичной давности с сайта Intellidimension, внутри Microsoft Interactive Media Manager кроется тот самый RDF Gateway. Intellidimension действительно крепко сотрудничают с Microsoft. И их нескромность в отношении цен, вероятно, во многом связано именно с этим. О семантических проектах самой Microsoft я не слышал.
В отличие от остальных рассматриваемых в этой статье фреймворков, которые являются OpenSource-проектами, RDF Gateway и Semantics.SDK распространяются с закрытыми исходными кодами и стоят достаточно приличных денег. Так, один лишь RDF Gateway 3.0 Enterprise стоит 10000$ (хотя версия 2.0 стоила «всего» 2000$).
Это одна из самых больших проблем .net — отсутствие качественных OpenSource библиотек.
Да, есть такая проблема. .NET'чики более алчные :)
Хотя, если внимательно приглядеться, большинство open-source Java-проектов платны для коммерческого использования (оно и понятно).
Хотя, если внимательно приглядеться, большинство open-source Java-проектов платны для коммерческого использования (оно и понятно).
на codeplex.com более 10 000 open source проектов под .net
все что я пробовал было качественным, хотя это понятие относительное
все что я пробовал было качественным, хотя это понятие относительное
Если внимательно приглядеться, то в .net в большинстве случаев вы найдете тот же привычный стек, что и в java, начиная от инструментов и заканчивая фреймворками: JUnit == NUnit, Hibernate == NHibernate, Ant == NAnt, Maverick == NMaverick, JMock == NMock/Moq, Apache JMS == ActiveMQ, Drools == drools.net, Spring == Spring.NET и т.п.
В крайнем случае есть ikvm.net.
Так что не грустите, не все еще потеряно, тем более что опенсорсное движение в .net, похоже, набирает силу.
В крайнем случае есть ikvm.net.
Так что не грустите, не все еще потеряно, тем более что опенсорсное движение в .net, похоже, набирает силу.
>> JUnit == NUnit, Hibernate == NHibernate, Ant == NAnt, Spring == Spring.NET
Что-то примеры всё подбираются такие, когда .NET аналог был сделан уже после реализации идеи в Java. Наверно, это о чём-то говорит.
Ну и Lucene => Lucene.Net, log4j => log4net
Что-то примеры всё подбираются такие, когда .NET аналог был сделан уже после реализации идеи в Java. Наверно, это о чём-то говорит.
Ну и Lucene => Lucene.Net, log4j => log4net
Ява появилась раньше… и вообще часть идей .NET инспирирована Явой.
Это говорит лишь о том, что многие нынешние .NET-разработчики — это бывшие Java-разработчики.
И это хорошо… В Яве слишком много путей, и многие из них — не красивы (особенно всё GUI).
Это всё — imho.
Это говорит лишь о том, что многие нынешние .NET-разработчики — это бывшие Java-разработчики.
И это хорошо… В Яве слишком много путей, и многие из них — не красивы (особенно всё GUI).
Это всё — imho.
В Яве слишком много путей, и многие из них — не красивы (особенно всё GUI).
Много путей потому что платформе уже много лет, что то отмирает, ему на замену приходят более красивые и интуитивные решения/фреймворки и т.п. Мне, например, ближе ява потому что здесь этот путь эволюционный. В .NET же от версии к версии MS вводит новые технологии отвергающие все что было ранее, зачастую это не необходимо.
>>В .NET же от версии к версии MS вводит новые технологии отвергающие все что было ранее, зачастую это не необходимо.
Приведите пример .NET-технологий, которые MS свернула без необходимости, на Ваш взгляд, на то.
Приведите пример .NET-технологий, которые MS свернула без необходимости, на Ваш взгляд, на то.
Легко. Linq2sql, развитие которого остановлено. На замену ему пришел ADO EF.
Linq2sql был мертворожденным. К моменту его выхода уже была стабильная бета EF и можно было догадаться, какая судьба ждет Linq2Sql.
К слову, Linq2Sql все же поддерживается: например, в .NET 3.5 SP1 была реализована поддержка Sql Server 2008.
Считаю Linq2Sql исключением и в целом не вижу тенденции, описанной teran.
К слову, Linq2Sql все же поддерживается: например, в .NET 3.5 SP1 была реализована поддержка Sql Server 2008.
Считаю Linq2Sql исключением и в целом не вижу тенденции, описанной teran.
DHTML Editor — no support in Vista/IE7
почему я должен переписывать своё приложение, которое успешно работало 5 лет, под новый браузер?
Апплет, написанный на Java 1.3 работает до сих пор.
почему я должен переписывать своё приложение, которое успешно работало 5 лет, под новый браузер?
Апплет, написанный на Java 1.3 работает до сих пор.
То, что Linq2sql, мертворожденный — это исключительно ВАШЕ необоснованное мнение, и не более. Поэтому не надо говорить, что linq2sql — исключение, только потому, что вам так удобно сказать.
Разговор был немного не о том. В общем случае, в java есть Java Community Process, который продвигает в java все то, что крайне успешно зарекомендовало себя на практике. В .net же такое отсутствует, поэтому единственный, кто принимает решения, чему быть, а чему нет — M$, причем ни с кем не советуясь. Что приводит к тому, что некоторые технологии оказываются отброшенными на обочину совершенно не согласованно с сообществом.
Разговор был немного не о том. В общем случае, в java есть Java Community Process, который продвигает в java все то, что крайне успешно зарекомендовало себя на практике. В .net же такое отсутствует, поэтому единственный, кто принимает решения, чему быть, а чему нет — M$, причем ни с кем не советуясь. Что приводит к тому, что некоторые технологии оказываются отброшенными на обочину совершенно не согласованно с сообществом.
Достаточно поискать атрибут Obsolete в сборках framework'а.
В Яве слишком много красивых путей, и каждый из них красив по своему.
Наверное, это потому, что я писал про привычный стек ИЗ JAVA, поэтому мы говорим про инструменты, которые в java уже были, а потом перенесеныв .net
Что касается использования памяти, то тестирование надо было сделать с использованием одинакового количества памяти, путь даже с флагами по умолчанию (кроме, разумеется, самих -Xmx -Xms для Java и аналогичных для .NET)
Есть подозрение, что «более алчная» до памяти Java просто использует всё, что даёте. А если ограничить все фреймворки одинаковым количеством памяти, то ещё неизвестно, что будет с производительностью.
Есть подозрение, что «более алчная» до памяти Java просто использует всё, что даёте. А если ограничить все фреймворки одинаковым количеством памяти, то ещё неизвестно, что будет с производительностью.
>>Есть подозрение, что «более алчная» до памяти Java просто использует всё, что даёте. А если >>ограничить все фреймворки одинаковым количеством памяти, то ещё неизвестно, что будет с >>производительностью.
У меня было такое подозрение. Но на компе с к 4Гб оперативы Java сваливалась в OutOfMemoryException. Из этого я сделал вывод, что ест не столько, сколько ей дают, а столько, сколько ей надо.
У меня было такое подозрение. Но на компе с к 4Гб оперативы Java сваливалась в OutOfMemoryException. Из этого я сделал вывод, что ест не столько, сколько ей дают, а столько, сколько ей надо.
А хоть какие-нибудь флаги устанавливались?
В зависимости от версии Java виртуальная машина использует разное максимальное количество памяти по умолчанию — 32, 64 или 128 Мб. Что, конечно, смешно для серьёзных приложений. И OutOfMemory выпадает не тогда, когда кончается ОЗУ память, а когда заканчивается вот эта самая память для виртуальной машины.
В зависимости от версии Java виртуальная машина использует разное максимальное количество памяти по умолчанию — 32, 64 или 128 Мб. Что, конечно, смешно для серьёзных приложений. И OutOfMemory выпадает не тогда, когда кончается ОЗУ память, а когда заканчивается вот эта самая память для виртуальной машины.
Мысль понял :)
Вроде устанавливались… но точно не скажу: запамятовал. Сейчас сделаю тест и отпишусь.
Вроде устанавливались… но точно не скажу: запамятовал. Сейчас сделаю тест и отпишусь.
Потестировал Java с меньшими ограничениями… работает, причем сборщик мусора, действительно, трудится более интенсивно. Jena выполнилась даже с параметрами -Xms256m -Xmx3g -XX:MaxPermSize=1g.
Выходит, упустил я этот момент. Сейчас подправлю статью. Спасибо за наводку!
Но все же расстраивает Java. Это что ж получается, нужно подбирать параметры JVM для каждой онтологии?! Прям не Java, а конструктор Лего какой-то.
Выходит, упустил я этот момент. Сейчас подправлю статью. Спасибо за наводку!
Но все же расстраивает Java. Это что ж получается, нужно подбирать параметры JVM для каждой онтологии?! Прям не Java, а конструктор Лего какой-то.
обычно достаточно указать максимум оперативной памяти и сделать его одинаковым с начальным уровнем:
-Xms3g -Xmx3g
Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
Если выполняется на 64 бит JVM, то можно поэкспериментировать ещё с флагами
-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops
А также для производительности
-Djava.net.preferIPv4Stack=true -Xverify:none
Если же используется последняя бета, то для упрощения работы GC:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
Также если уж мы говорим про операции, которые могут загрузить компьютер на час, то надо включать «серверную» оптимизацию:
-server
Что касается большого количества флагов, то большинство из них достаточно хорошо устанавливаются «по умолчанию» для большинства случаев. Чаще всего указание максимального количества памяти нормально работает. Редкие случаи, вроде необходимости использования большого количества perm memory бывают, но, кажется, вычисление онтологий не относится к подобным задачам и должно нормально отрабатываться даже без указания MaxPerSize. Зато указание дополнительных флагов может ускорить работу системы если администратору известно, для чего она будет использоваться. Например, на веб-сервере может быть недопустимы длительные задержки на GC — поэтому конфигурирется он таким образом, чтобы уменьшить время сбора мусора (но, может быть, увеличить частоту). А иногда, например, для вычислительных экспериментов, время сборки мусора можно и увеличить, если это приведёт к уменьшению частоты вызовов и уменьшит общее время работы GC.
Упоминаемый флаг -server, например, даже включён в спецификацию JDK, и обязан поддерживаться (хотя бы пониматься) всеми JVM. Он говорит о том, что программа будет выполняться большое количество времени, и нужно приложить все усилия к оптимизации, возможно, даже внеся задержку во время начальной работы приложения. А противоположный ему флаг -client наоборот, должен заставлять JVM жертвовать общей производительностью ради быстроты запуска приложения.
Не знаю, есть ли аналогичные флаги у .NET / CLR
-Xms3g -Xmx3g
Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
Если выполняется на 64 бит JVM, то можно поэкспериментировать ещё с флагами
-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops
А также для производительности
-Djava.net.preferIPv4Stack=true -Xverify:none
Если же используется последняя бета, то для упрощения работы GC:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
Также если уж мы говорим про операции, которые могут загрузить компьютер на час, то надо включать «серверную» оптимизацию:
-server
Что касается большого количества флагов, то большинство из них достаточно хорошо устанавливаются «по умолчанию» для большинства случаев. Чаще всего указание максимального количества памяти нормально работает. Редкие случаи, вроде необходимости использования большого количества perm memory бывают, но, кажется, вычисление онтологий не относится к подобным задачам и должно нормально отрабатываться даже без указания MaxPerSize. Зато указание дополнительных флагов может ускорить работу системы если администратору известно, для чего она будет использоваться. Например, на веб-сервере может быть недопустимы длительные задержки на GC — поэтому конфигурирется он таким образом, чтобы уменьшить время сбора мусора (но, может быть, увеличить частоту). А иногда, например, для вычислительных экспериментов, время сборки мусора можно и увеличить, если это приведёт к уменьшению частоты вызовов и уменьшит общее время работы GC.
Упоминаемый флаг -server, например, даже включён в спецификацию JDK, и обязан поддерживаться (хотя бы пониматься) всеми JVM. Он говорит о том, что программа будет выполняться большое количество времени, и нужно приложить все усилия к оптимизации, возможно, даже внеся задержку во время начальной работы приложения. А противоположный ему флаг -client наоборот, должен заставлять JVM жертвовать общей производительностью ради быстроты запуска приложения.
Не знаю, есть ли аналогичные флаги у .NET / CLR
>>обычно достаточно указать максимум оперативной памяти и сделать его одинаковым с начальным уровнем:
-Xms3g -Xmx3g
Кто это вообще придумал? :) Почему не сделать, как в .NET? Почему я должен указывать максимальный объем памяти, когда я не знаю, как и при каких нагрузках будет использоваться мое приложение?
>>Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
MaxPermSize я задал вручную не от хорошей жизни :) Валился JVM с OutOfMemoryException именно по PermSize — вот я задал с запасом :)
>>Не знаю, есть ли аналогичные флаги у .NET / CLR
Некоторые есть. «Серверный» режим сборки мусора в случае .NET означает многопоточную сборку и рекомендуется к активации только на многоядерных машинах (что неудивительно :) ).
-Xms3g -Xmx3g
Кто это вообще придумал? :) Почему не сделать, как в .NET? Почему я должен указывать максимальный объем памяти, когда я не знаю, как и при каких нагрузках будет использоваться мое приложение?
>>Устанавливать MaxPermSize в 1G это жёстко :) лучше не трогать эту настройку, если не конца понятно, о чём идёт речь.
MaxPermSize я задал вручную не от хорошей жизни :) Валился JVM с OutOfMemoryException именно по PermSize — вот я задал с запасом :)
>>Не знаю, есть ли аналогичные флаги у .NET / CLR
Некоторые есть. «Серверный» режим сборки мусора в случае .NET означает многопоточную сборку и рекомендуется к активации только на многоядерных машинах (что неудивительно :) ).
>> Кто придумал
Так ведь и не понять, сколько памяти нужно. Иногда, например, лучше вызвать пару лишних раз GC и почистить память, чем увеличить её на пару десятков мегбайт, залезть в «своп» и подвешивать после этого систему каждую минуту.
Плюс безопасность. Java-приложение никогда не займёт всю оперативную память. Поэтому из-за безопасности приложениям по умолчанию ограничивают память, а если надо больше — то обычно человек знает, зачем он это хочет, и как это сделать.
Хотя да, могли бы и приделать интерфейс «программа хочет больше памяти, поделитесь?» :)
Так ведь и не понять, сколько памяти нужно. Иногда, например, лучше вызвать пару лишних раз GC и почистить память, чем увеличить её на пару десятков мегбайт, залезть в «своп» и подвешивать после этого систему каждую минуту.
Плюс безопасность. Java-приложение никогда не займёт всю оперативную память. Поэтому из-за безопасности приложениям по умолчанию ограничивают память, а если надо больше — то обычно человек знает, зачем он это хочет, и как это сделать.
Хотя да, могли бы и приделать интерфейс «программа хочет больше памяти, поделитесь?» :)
Как бы там ни было, эти танцы с бубном не красят JVM с точки зрения пользователя (который понятия не имеет, как расширить кучу, perm size и т. д.) Почему нет сбалансированного режима, который заключался бы в следующем:
1. собирал мусор со средней интенсивностью (думаю, в рамках конкретной реализации сборщика мусора это можно сформулировать более формализованно)
2. потреблял память столько, сколько ему нужно.
? Ведь примерно так и ведет себя .NET… и ничего зазорного в этом я не вижу.
1. собирал мусор со средней интенсивностью (думаю, в рамках конкретной реализации сборщика мусора это можно сформулировать более формализованно)
2. потреблял память столько, сколько ему нужно.
? Ведь примерно так и ведет себя .NET… и ничего зазорного в этом я не вижу.
Вы похоже забыли, что Java приложение работает под большинством операционных систем, а политики работы с паматью в них могут сильно различаться. Поэтому ответственность установки свойств работы с памятью для Java-приложения перекладывается обычно на его загрузчик, который в момент старта в зависимости от ОС, железа и прочих параметров может установить эти свойства оптимальным образом.
>>Как бы там ни было, эти танцы с бубном не красят
>>JVM с точки зрения пользователя
Пользователь о всех этих тонкостях может узнать только благодаря нерадивому разработчику, которые не позаботился о его психическом здоровье :)
>>Как бы там ни было, эти танцы с бубном не красят
>>JVM с точки зрения пользователя
Пользователь о всех этих тонкостях может узнать только благодаря нерадивому разработчику, которые не позаботился о его психическом здоровье :)
>>Если же используется последняя бета, то для упрощения работы GC:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
То есть в последней бете уже не нужно задавать Xmx?
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
То есть в последней бете уже не нужно задавать Xmx?
В последней бете доступен новый GC (их у Sun Java несколько разных на выбор… ага, лего).
Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
XmX задавать нужно, но, например, не нужно задавать:
-XX:SurvivorRatio, -XX:MaxNewSize, -XX:MaxPermSize, -XX:NewRatio, -XX:NewSize, -XX:TargetSurvivorRatio
Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
XmX задавать нужно, но, например, не нужно задавать:
-XX:SurvivorRatio, -XX:MaxNewSize, -XX:MaxPermSize, -XX:NewRatio, -XX:NewSize, -XX:TargetSurvivorRatio
>>их у Sun Java несколько разных на выбор… ага, лего
Если выбор каждого из них имеет смысл в зависимости от специфики программы, то почему бы и нет. В какой-то степени это можно рассматривать и как конкурентное преимущество перед .NET: не слышал об альтернативных сборщик для CLR (хотя не исключаю, что они и есть).
>>Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
Почему это реализуется только сейчас? О_О Неужели раньше не было такой потребности?
>>XmX задавать нужно, но, например, не нужно задавать:
Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти (как было сказано выше). Xmx является обязательным параметром?
Если выбор каждого из них имеет смысл в зависимости от специфики программы, то почему бы и нет. В какой-то степени это можно рассматривать и как конкурентное преимущество перед .NET: не слышал об альтернативных сборщик для CLR (хотя не исключаю, что они и есть).
>>Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
Почему это реализуется только сейчас? О_О Неужели раньше не было такой потребности?
>>XmX задавать нужно, но, например, не нужно задавать:
Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти (как было сказано выше). Xmx является обязательным параметром?
>>Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти
-Xmx как раз и задаёт максимальный размер оперативной памяти, который разрешено использовать Java. Обязательным параметром не является, но его значение по умолчанию устраивает только апплетчиков и авторов маленьких приложений.
Надо отметить, все серьёзные клиентские приложения уже давно идут со своими runner'ами и startup'ерами, вроде того же Eclipse'а (если рассматривать его как framework). Рядом с приложением кладётся и .exe файл, и .ini файл, в котором уже прописаны сотнимегабайтовые требования к оперативной памяти.
-Xmx как раз и задаёт максимальный размер оперативной памяти, который разрешено использовать Java. Обязательным параметром не является, но его значение по умолчанию устраивает только апплетчиков и авторов маленьких приложений.
Надо отметить, все серьёзные клиентские приложения уже давно идут со своими runner'ами и startup'ерами, вроде того же Eclipse'а (если рассматривать его как framework). Рядом с приложением кладётся и .exe файл, и .ini файл, в котором уже прописаны сотнимегабайтовые требования к оперативной памяти.
Если же речь про «размер ОЗУ как ограничитель», то моя правая рука немедленно убъёт приложение, которое попыталось занять всю оперативку. У меня ещё Winamp есть, и два IDE запущено, и им всем хочется кушать. (и своп отключен)
Хм… Но ведь живут же как-то .NET-приложения, а в них такие ограничения не задаются (по крайней мере по умолчанию). И не занимаю они все память. И даже если им вдруг захочется занять всю оперативку, Винда ведь не станет отнимать ее у Винампа, IDE и других, она просто отдаст все свободное место (вероятно, вместе со свопом). Но это крайний случай, а в 99.999% случаев такая политика «сколько надо — столько берит» работает замечательно. А для того самого крайнего случая можно и ограничить максимальный объем процесса (полагаю, средства для этого есть).
Неужели в Java нельзя реализовать нечто подобное?
Я понимаю, что я Вас уже достал с этим вопросом… но он мне не дает покоя :)
Неужели в Java нельзя реализовать нечто подобное?
Я понимаю, что я Вас уже достал с этим вопросом… но он мне не дает покоя :)
Думаю, что всё именно из-за свопа. Стоит Java-приложению туда залезть, и оно уже «не вылезет» :)
Тормоза будут просто дикие.
Java-приложение использует память по максимуму, то есть очень часто обращается практически к каждому участку памяти. Стоит хотя бы паре процентов уйти в своп, система будет требовать их назад (хотя бы для работы того же GC).
Думаю, разработчики Java верят, что 128 Мб как раз и являются крайним случаем для 99% «несерьёзных» клиентских приложений (мне сложно представить «несерьёзную» систему с большими требованиями), а для серьёзных приложений есть загрузчики, которые как раз могут установить требования к памяти как надо.
Тормоза будут просто дикие.
Java-приложение использует память по максимуму, то есть очень часто обращается практически к каждому участку памяти. Стоит хотя бы паре процентов уйти в своп, система будет требовать их назад (хотя бы для работы того же GC).
Думаю, разработчики Java верят, что 128 Мб как раз и являются крайним случаем для 99% «несерьёзных» клиентских приложений (мне сложно представить «несерьёзную» систему с большими требованиями), а для серьёзных приложений есть загрузчики, которые как раз могут установить требования к памяти как надо.
Не знаю, можно или нет.
Знаю одно — в алгоритм выделения управления памяти для .net встроено знание о том, как сегментами выбирать(Commit, Reserve) память под Windows.
Java-машина, по видимому, действует как-то проще, и в процессе работы не взаимодействует с механизмами управления памятью ОС — только при инициализации.
Причины этого мне, увы, неизвестны.
Знаю одно — в алгоритм выделения управления памяти для .net встроено знание о том, как сегментами выбирать(Commit, Reserve) память под Windows.
Java-машина, по видимому, действует как-то проще, и в процессе работы не взаимодействует с механизмами управления памятью ОС — только при инициализации.
Причины этого мне, увы, неизвестны.
>>Знаю одно — в алгоритм выделения управления памяти для .net встроено знание о том, как сегментами выбирать(Commit, Reserve) память под Windows.
А что это знание дает .NET GC в контексте обсуждаемого нами вопроса?
А что это знание дает .NET GC в контексте обсуждаемого нами вопроса?
То, что CLR в курсе, как выделить память у системы, и потому не просит всяких -Xmx, например, а отъедает сколько нужно в процессе работы программы. Причем это выделение очень сильно интегрировано в работу GC: например, почти вся выделяемая в процессе работы память отводится под поколение 2 (если не считать первоначального автотюнинга размеров памяти под поколения 0 и 1.
Для java весь выделенный сегмент памяти переходит под управление менеджера памяти jvm, и потом она не обращается к Windows.
Для java весь выделенный сегмент памяти переходит под управление менеджера памяти jvm, и потом она не обращается к Windows.
Уголок прояснителя слов (а то, чёта кажется, не мне одному нихрена не понятно ничего в этой статье):
Семантика (в программировании) — система правил истолкования отдельных языковых конструкций. Семантика определяет смысловое значение предложений алгоритмического языка.
Онтоло́гия (в информатике) — это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот термин в информатике является производным от древнего философского понятия «онтология».
Онтология — учение о бытии; раздел философии, изучающий фундаментальные принципы бытия, наиболее общие категории сущего.
греч.Ontos — бытие + Logos — учение
Семанти́ческая паути́на (англ. Semantic Web) — часть глобальной концепции развития сети Интернет, целью которой является реализация возможности машинной обработки информации, доступной во Всемирной паутине. Основной акцент концепции делается на работе с метаданными, однозначно характеризующими свойства и содержание ресурсов Всемирной паутины, вместо используемого в настоящее время текстового анализа документов. В семантической паутине предполагается повсеместное использование, во-первых, универсальных идентификаторов ресурсов (URI), а во-вторых — онтологий и языков описания метаданных.
После прочтения всего этого по словарям, можно смело перечитать статью, она очень даже интересна.
Семантика (в программировании) — система правил истолкования отдельных языковых конструкций. Семантика определяет смысловое значение предложений алгоритмического языка.
Онтоло́гия (в информатике) — это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот термин в информатике является производным от древнего философского понятия «онтология».
Онтология — учение о бытии; раздел философии, изучающий фундаментальные принципы бытия, наиболее общие категории сущего.
греч.Ontos — бытие + Logos — учение
Семанти́ческая паути́на (англ. Semantic Web) — часть глобальной концепции развития сети Интернет, целью которой является реализация возможности машинной обработки информации, доступной во Всемирной паутине. Основной акцент концепции делается на работе с метаданными, однозначно характеризующими свойства и содержание ресурсов Всемирной паутины, вместо используемого в настоящее время текстового анализа документов. В семантической паутине предполагается повсеместное использование, во-первых, универсальных идентификаторов ресурсов (URI), а во-вторых — онтологий и языков описания метаданных.
После прочтения всего этого по словарям, можно смело перечитать статью, она очень даже интересна.
Эх… надо было в своё время на программиста идти учиться…
Не очень показательным получился тест SPARQL-запросов. Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
>>Не очень показательным получился тест SPARQL-запросов.
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
API рассматриваемых фреймворков. Можно, например, реализовать программно приведённые Вами запросы. Ну или что-нибудь попроще, вроде listIndividuals() или getPropertyValue() с транзитивным выводом (не знаю, как это делается в OWL API, привел примеры в терминах Jena).
Да, наверное, нужно было сделать такое сравнение. Где Вы были раньше? :)
Наверное, как-нибудь на досуге сделаю такое сравнение и сделаю минипост в блоге.
Спасибо ;) Я в свое время остановился на Jena, т.к. нужно было срочно, а она первая попалась под руку. Вот теперь интересно, может не надо было спешить.
Кроме того, помню были у меня проблемы с подгрузкой доп. правил вывода в Jena. Т.е. очень долго строилась модель, если ризонеру подсунуть пару доп. правил. Не помню сейчас подробностей, позже уточню. Все это к тому, что интересно также, как с этим обстоит у других фреймворков.
Кроме того, помню были у меня проблемы с подгрузкой доп. правил вывода в Jena. Т.е. очень долго строилась модель, если ризонеру подсунуть пару доп. правил. Не помню сейчас подробностей, позже уточню. Все это к тому, что интересно также, как с этим обстоит у других фреймворков.
>>Не очень показательным получился тест SPARQL-запросов.
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
Осталось еще добавить подсказки при орфографических ошибках
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнительный анализ фреймворков для работы с онтологиями под .NET и Java