Pull to refresh
0
0
tegger @tegger

User

Send message
Не помню уже. В течение суток точно.
Странно, мне помогло. Я писал через форму обратной связи (по ссылке «Обратная связь» на страницах МК).
Достаточно написать в support.
Есть еще 9.6.
Улучшений пока не заметил, но вот форматирование едет в нескольких местах (например, кнопка Previous item у меня в 9.62 выглядит очень странно).
А вот на Оперу забили, как обычно.
DSA работает с хэшем сообщения, а не с самим сообщением.
Ни к чему такому он не стремится. Принципиально невозможно избавиться от того, что одному хэш-значению будут соответствовать несколько разных сообщений. Но разработчики алгоритма стремятся к тому, чтобы получение коллизий было максимально сложным: groups.csail.mit.edu/cis/md6/submitted-2008-10-27/Supporting_Documentation/md6_report.pdf
Несколько странное заявление.
Никакой хэш не является однозначным идентификатором сообщения.
Ценность исходников сильно преувеличена. Исходники по-хорошему надо тащить вместе со всей командой разработчиков.
Jazelle и hotspot друг друга вовсе не исключают.
Проблема в том, что сам по себе CLDC hotspot умеет делать только простейшие оптимизации. Но при этом он может компилировать код под набор инструкций Jazelle RCT.
Конечно, процессор с Jazelle — это нифига не честный java-процессор, но зато он хоть для чего-то полезен:)
В мобилах на базе ARM-процессоров аппаратное ускорение Java используется давно и, похоже, успешно. Получается существенно быстрее, чем при тупой интерпретации. Оптимизирующий hotspot-компилятор, конечно, еще лучше, но в телефон он не влезает.
Во-первых, валидация — это проверка XML не только на синтаксическую корректность, но и на соответствие схеме.
Во-вторых, посмотрите в Conclusion статьи:
"… Intel SSE4.2/STTNI instructions are used in schema validation component… to speed up performance and reduce memory consumption in attribute/element declaration lookup, string enumeration facet validation and model group state transion, which are hot bottlenecks in core schema validation."
И речь в статье идет не о полном перекладывании валидации на магический аппаратный ускоритель, а об оптимизации одного небольшого (но часто используемого) кусочка кода валидатора.
Валидация XML — это просто хороший пример использования новых «строковых» инструкций (очень уж много сравнений строк делается при валидации). На самом деле эти инструкции подойдут для самых разных задач.
А есть уже. Только не плата, а отдельная машинка: www-01.ibm.com/software/integration/datapower/xa35/
100 млн. строк кода в ядре?? Тут более точная оценка: linux.slashdot.org/article.pl?sid=08/10/22/1713241

А вообще да, я имел в виду монолитные большие проекты внутри одной конторы.
С большими проектами git пока хуже справляется, чем svn. К тому же, merge tracking в svn уже есть.
Вот в Орден Белого Ниндзя я бы вступил.
Прежде всего, Java != JavaScript :)
Сам по себе JavaScript весьма неплох. Никакой излишней кривости или запутанности в языке нет, он очень простой.
Тормозит обычно не интерпретация языка, а работа с DOM и прочими браузерными API. Манипуляции с DOM приводят к необходимости пересчитывать положение объектов и заново выполнять рендеринг частей страницы. Хуже того, до наступления полного AJAXа мало кто задумывался об оптимизации. Я уж не говорю о браузерных войнах и несовместимых корявых API, из-за которых приходится использовать всякие тормозные прокладки (Prototype etc.).
В случае PHP все намного проще: прослойка между функциями PHP и системными вызовами ОС минимальна. Интерпретатору не приходится в runtime решать, например, как открывать файл в данной ОС. Скорость интерпретации PHP не очень-то отличается от JavaScript (примеры тестов можно посмотреть на shootout.alioth.debian.org/ )

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity