https://www.opennet.me/openforum/vsluhforumID3/52637.html Вышел (http://www.citadel.org/doku.php/news:citadel.7.50.released) релиз Citadel 7.50 (http://www.citadel.org/), продукта для организации коллективной работы, распространяемого в рамках лицензии GPLv3. Пакет включает в себя средства для чтения электронной почты, совместного планирования по календарю, адресную книгу, форум, списки рассылок, службу мгновенного обмена сообщениями. Работа производится через web-интерфейс, оформленный в "AJAX-стиле" и поддерживающий WYSWYG средства редактирования документов. Альтернативно распространяется клиент для запуска на локальной машине и консольный клиент, работающий через telnet/SSH.<br><br>URL: http://www.citadel.org/doku.php/news:citadel.7.50.released<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=21301<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#45 Mon, 20 Apr 2009 05:53:19 GMT &gt;Это лишь подверждает правило: На Java идеально оптимизированные программы работают так же <br>&gt;быстро, как посредственно написанные на С/С++. <br>&gt;<br>&gt;В случае с saxon мы имеем дело не со скоростью Java, а <br>&gt;с хорошо написанными опитимизированными алгоритмами. Надеюсь Вы не собираетесь отрицать, что <br>&gt;если этиже оптимизации (как компиляция XPath например с помощью LLVM и <br>&gt;более продвинутые алгоритмы) перенести в libxslt, то приведенный выше бенчмарк повторится <br>&gt;с похожим соотношением, только уже с другими цифрами. <br><br>Я утверждаю что скорость будет примерно одинаковой. В Java код компилируется с помощью Jit (а он не менее эффективен чем gcc), а уменьшение скорости идёт из-за большего количества cache miss (а в saxon в процесе работы память почти не перераспределяется).<br><br>А в этих тестах вполне возможно для каждой xslt запускался JVM. А пока он скомпилирует весь байткод в нативный код, это требует некоторого времени.<br><br>К слову о бенчмарках (хоть и со старой Jvm но результат показателен): http://www.idiom.co https://www.opennet.me/openforum/vsluhforumID3/52637.html#44 Mon, 20 Apr 2009 05:43:50 GMT &gt;Неуважаемый троль,<br><br>Ага, конечно.Неудобный - вроде так хочется оспорить утверждения, а кишка тонка, да еще сцуко факты привел - бенч прям с сайта разрабов либы, на него правда выступили что там плохая реализация.Хорошую впрочем писать отказались, хоть алгоритм и несложный и даже референсная реализация уже есть :).Поэтому просто переводятся стрелки на другую тему.Стандартно.И вы сами это явление и охарактеризовали - троллинг это.<br><br>&gt; расскажите ка мне о XSLT процессоре на С/С++,<br><br>Как только вы перепишете жава-вариант quicklz так чтобы он (без читов с вызовом нативного кода) уделал сишный, я подумаю над тем чтобы изучить этот вопрос :)<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#43 Mon, 20 Apr 2009 05:27:08 GMT &gt;&gt;http://www.davidpashley.com/articles/xslt-benchmarks.html <br>&gt;<br>&gt;Этот бенчмарк несколько устарел. <br>&gt;В последниз версиях уже появилась куча дополнительных оптимизаций запросов (а в коммерческой <br>&gt;версии ещё и компиляция XPath в JVM код). Пол года назад <br>&gt;он (в версии 8.5) давал до 5Mb/s на огромных XML (около <br>&gt;500&#1461;Mb). Остальные XSLT процессоры просто не тянули такие объёмы. <br><br>Это лишь подверждает правило: На Java идеально оптимизированные программы работают так же быстро, как посредственно написанные на С/С++.<br><br>В случае с saxon мы имеем дело не со скоростью Java, а с хорошо написанными опитимизированными алгоритмами. Надеюсь Вы не собираетесь отрицать, что если этиже оптимизации (как компиляция XPath например с помощью LLVM и более продвинутые алгоритмы) перенести в libxslt, то приведенный выше бенчмарк повторится с похожим соотношением, только уже с другими цифрами.<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#42 Sun, 19 Apr 2009 20:28:02 GMT &gt;&gt;Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был <br>&gt;&gt;бы быстрее чем saxon (написанный на чистой java). И не надо <br>&gt;&gt;расказывать что XML/XSLT не нужно. <br>&gt;<br>&gt;http://www.davidpashley.com/articles/xslt-benchmarks.html <br><br>Этот бенчмарк несколько устарел. <br>В последниз версиях уже появилась куча дополнительных оптимизаций запросов (а в коммерческой версии ещё и компиляция XPath в JVM код). Пол года назад он (в версии 8.5) давал до 5Mb/s на огромных XML (около 500&#1461;Mb). Остальные XSLT процессоры просто не тянули такие объёмы.<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#41 Sun, 19 Apr 2009 20:08:08 GMT &gt;Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был <br>&gt;бы быстрее чем saxon (написанный на чистой java). И не надо <br>&gt;расказывать что XML/XSLT не нужно. <br><br>http://www.davidpashley.com/articles/xslt-benchmarks.html<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#40 Sat, 18 Apr 2009 21:44:28 GMT Всё замечательно - но для СНГ - не канает - с кирилицей никак. Вернее с utf8 - ни Кои ни 1251 не пробовал. Кстати - не такая уж она и шкстрая. И ксати - она оказывается из bbs разрослась - админить удобнее всего через как раз через нее. <br>Но танцы с бубнами не помогли. Вернее так - если использовать её как набор IMAP + POP3 + Jabber + MailMan - в одном флаконе - сойдёт с пивом - но не дай бог с содержимым поработать средствами bbs или веб-интерфейса - "всё пропало - гипс снимают".<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#39 Sat, 18 Apr 2009 19:20:57 GMT &gt;только формально ;), а задумайтесь по сути... <br><br>если вы так продолжите "формально" - то и зайти можете далеко, только ни туда куда нужно.<br><br>1. на java написано достаточно кода, которые не использует никакие библиотеки, за исключением быть может 10 библиотечных вызовов.<br><br>2. jni на то и jni, что придуман быть прослойкой между java и dll.<br><br>3. вм никогда не была, и не будет так-же проста как dll, просто потому что задачи и условия работы разные.<br><br>4. вм ВСЕГДА будет тормознее нативного кода, другое дело, что может и не так сильно, чтобы например писать на с/c++ или тем более asm.<br><br>5. каждой задаче - свой инструмент.<br> https://www.opennet.me/openforum/vsluhforumID3/52637.html#38 Sat, 18 Apr 2009 14:16:22 GMT &gt;игры - когда САН сделает движки подо все платформы, тогда и игры <br>&gt;будут на джава <br><br>Жава есть под винды, линукс и наверное мак.Мало чтоли?Игры на жаве - есть.Ну там тетрис.Пакман.И подобная ерунда.В которую на спектрумах и подобных гоняли с их 64 кило оперативы и процом на пару МГц :).А вот что-то уровня Nexuiz?Quake 3?Как минимальная планка.Не хотите изобразить?:)<br><br>&gt;кодеки - аналогичная история <br><br>Ага, вот приедет барин и все будет зашибись... ох уж эта русская вера в барина, царя-батюшку, сан микросистемс и кого там еще.А я верю только в факты.И меня не устраивает подождать пяток лет пока сан сподобится засунуть нужный мне сегодня кодек в свое добро.<br><br>&gt;поймите - ВМ и есть большая длл (условно) обеспечивающая кроссплатформенность <br><br>Она гораздо больше чем длл.В частности оно управляет памятью, ставит ограничения (например неподписанным апплетам) и прочая.И даже если приперло, от этой навязчивой услуги хрен откажешься.Вон на мобилках с тем же Jimm траха на тему секурити - вагон.Кто-то вообще нужное апи https://www.opennet.me/openforum/vsluhforumID3/52637.html#37 Sat, 18 Apr 2009 10:47:20 GMT &gt;Ну так напишите ваш вариант компрессора, кодека, ... чтоб он уделал современных <br>&gt;сишных аналогов написанных без халтуры, с оптимизацией.Ну вон H.264, LZMA или <br>&gt;еще что-нить тяжеленькое попробуйте вон написать на яве.А для начала можете <br>&gt;и просто quicklz переделать, так как вам угодно, обещаю забенчить переделанный <br>&gt;вариант в сравнении с сишным во всех позах, если вы на <br>&gt;это сподвигнетесь как крутой жава-програмер.Он сравнительно простой.Какие проблемы то?А то жиденькие <br>&gt;отмазки жава-кодеров - заманали.Отмазки - есть.Быстрого софта, особенно того в котором <br>&gt;скорость натурально важна - не вижу.Зато теоретических распальцовок о скорости - <br>&gt;это всегда пожалуйста. <br><br>Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был бы быстрее чем saxon (написанный на чистой java). И не надо расказывать что XML/XSLT не нужно.<br>