Здравствуйте, Sheridan, Вы писали:
>> В простых случаях JIT устраняет проверки на выход за границы. В сложных — к операции доступа добавляется одна ассемблерная инструкция. S>Синклер, глянь в этой ветке на пару сообщений выше. S>Цитирую "Сингулярити не использует JIT."
Т.е. Синклеру нельзя ничего про обычный джит в обычном дотнет писать, раз сингулярити его не использует ?
Здравствуйте, Sheridan, Вы писали:
S>WFrag однажды (26 июня 2008 [Четверг] 12:33) писал в rsdn.flame.comp:
>> Да. Могу тебя порадовать. Это замечательно работает в пределах _одного_ .c файла. S>Помоему инлайнинг внешних функций противоречит самой концепции С/С++, хотя не уверен S>Да и с дальнейшей поддержкой тяжко будет.
А с перформансом то что ?
S>Тоесть "давай наперегонки, только я на велосипеде, а ты на карачках"? S>Я правильно понял, что С код специально ограничивали от инлайнинга?
Почему же ? Пусть линкер покажет, как он умеет инлайнить.
Ikemefula однажды (26 июня 2008 [Четверг] 13:03) писал в rsdn.flame.comp:
> Т.е. Синклеру нельзя ничего про обычный джит в обычном дотнет писать, раз сингулярити его не использует ?
А я откуда знал что у вас там джитов как блох на дворняге?
Здравствуйте, Sheridan, Вы писали:
S>WFrag однажды (26 июня 2008 [Четверг] 12:33) писал в rsdn.flame.comp:
>> Да. Могу тебя порадовать. Это замечательно работает в пределах _одного_ .c файла. S>Помоему инлайнинг внешних функций противоречит самой концепции С/С++, хотя не уверен S>Да и с дальнейшей поддержкой тяжко будет.
Вообще, это оптимизация. В Java она работает совершенно прозрачно.
S>gcc умеет не только циклы оптимизировать. S>в общем случае есть даже стандартные наборы оптимизаций: S>
S>
Да я как бы в курсе.
S>Тоесть "давай наперегонки, только я на велосипеде, а ты на карачках"? S>Я правильно понял, что С код специально ограничивали от инлайнинга?
Именно. В этом и был смысл теста — показать _глобальные оптимизации_, в данном случае, в Java, в Bartok случае должно быть также. Java, между прочим, выступала вообще в кандалах — имплементация функции (той самой, что делает сложение) в одном из тестов вообще _скачивалась по HTTP_. Т.е запускаешь тест, он _догружает по HTTP_ кусок кода, выполняет его в цикле и уделывает C Впрочем, только лишь на N-ый прогон тестового метода (в моем случае — 3-ий), ибо в Java эта оптимизация не сразу срабатывает, а тогда, когда Hotspot решает, что имеет смысл потратить немного времени CPU на оптимизацию.
>> Можешь сам проверить. Могу дать исходники теста. S>Давай.
Поехали. Опять оговорюсь, тест — синтетический, т.е делать далеко идущи выводы из него не стоит.
dosum.c:
int dosum(int a, int b) {
return a + b;
}
test4.c:
#include <stdio.h>
#include <time.h>
int dosum(int a, int b);
int main(int argc, char** argv) {
int count1 = atoi(argv[1]);
int count2 = atoi(argv[2]);
long c = clock();
int l = 0, i, j;
for( j = 0; j < count1; ++j ) {
for( i = 0; i < count2; ++i ) {
l = dosum(l, i);
}
}
long end = clock();
printf( "l = %d\n", l );
printf("%f\n", (float)(end - c) / (float)CLOCKS_PER_SEC);
return 0;
}
DoSum.java:
public interface DoSum {
int dosum(int a, int b);
}
DoSumImpl.java:
public class DoSumImpl implements DoSum {
public int dosum(int a, int b) {
return a + b;
}
}
Test4.java:
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;
import java.net.*;
public class Test4 {
public static void main(String[] args) throws Exception {
int count1 = Integer.parseInt(args[1]);
int count2 = Integer.parseInt(args[2]);
// Можно заменить эту строку
DoSum d = (DoSum) Class.forName(args[0]).newInstance();
// Двумя вот этими, тогда код будет подгружаться с сервера (и локальные DoSumImpl.java/DoSumImpl.class можно вообще удалить):
//ClassLoader cl = new URLClassLoader(new URL[] { new URL("http://wfrag.org/files/") });
//DoSum d = (DoSum) cl.loadClass(args[0]).newInstance();
// Прогреем JVM :)
test(d, count1+1, count2+1);
test(d, count1+2, count2+2);
System.err.println("Real results");
// А вот теперь реально замерим:
test(d, count1, count2);
test(d, count1, count2);
}
public static void test(DoSum d, int count1, int count2) throws Exception {
ThreadMXBean mx = ManagementFactory.getThreadMXBean();
long c = mx.getCurrentThreadCpuTime();
int l = 0, i, j;
for( j = 0; j < count1; ++j ) {
for( i = 0; i < count2; ++i ) {
l = d.dosum(l, i);
}
}
long end = mx.getCurrentThreadCpuTime();
System.err.println( "l = " + l);
System.err.println((float)(end - c) / 1000000000);
}
}
Java (заметь, до запуска Java-код вообще не знает, что ему вызывать — имя класса, реализующего функциональность, передается параметром):
wfrag@fragentoo ~/test/1 $ /opt/sun-jdk-1.6.0.06/bin/javac Test4.java
wfrag@fragentoo ~/test/1 $ /opt/sun-jdk-1.6.0.06/bin/java -cp . -XX:CompileThreshold=10 -server Test4 DoSumImpl 10 1000000000
l = 1618564864
27.84
l = 490353676
30.24
Real results
l = 451808768
5.64
l = 451808768
5.65
В сумме Java, конечно, проиграла — много времени ушло на JIT-компиляцию ("разогрев"). Поэтому не пытайся мерять time-ом. Впрочем, если запускать тест не 1 раз, а в цикле раз 10, то Java и по суммарному времени должна обойти C с статической/динамической линковкой.
Ikemefula однажды (26 июня 2008 [Четверг] 13:06) писал в rsdn.flame.comp:
>>> Да. Могу тебя порадовать. Это замечательно работает в пределах _одного_ .c файла. > S>Помоему инлайнинг внешних функций противоречит самой концепции С/С++, хотя не уверен > S>Да и с дальнейшей поддержкой тяжко будет. > А с перформансом то что ?
А куда оно денется. с -O3 соберем.
Что с поддержкой?
> S>Тоесть "давай наперегонки, только я на велосипеде, а ты на карачках"? > S>Я правильно понял, что С код специально ограничивали от инлайнинга? > Почему же ? Пусть линкер покажет, как он умеет инлайнить.
Ясно. Тобишь тестировался именно линкер, тогда как со стороны явы тестировался весь комплекс. Замечательно.
Здравствуйте, Sheridan, Вы писали:
S>Ясно. Тобишь тестировался именно линкер, тогда как со стороны явы тестировался весь комплекс. Замечательно.
А теперь загляни в каталог /usr/lib и посмотри сколько там работы для линкера Или посчитай количество .o файлов, скажем, для KDE или Gnome. Всех их связывать будет именно линкер.
Здравствуйте, WolfHound, Вы писали:
WH>Вобще говоря бинарник с управляемым кодом имеет очень интересное свойство: В нем есть вся информация которая есть в исходниках. За исключением форматирования и комментариев. WH>Те исходники нам и не нужны.
С другой стороны, при наличии исходников, нам не нужны бинарники с управляемым кодом.
Здравствуйте, WFrag, Вы писали:
WF>В локальных оптимизациях JIT находится не в худшей ситуации, чем обычный компилятор. Разве что у него жесткие рамки на скорость самой компиляции.
Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.
WF>А вот в плане глобальных оптимизаций у него есть преимущества.
Это правда. Кроме того, у него есть очевидное преимущество в плане использования результатов профилирования для выборов стратегии оптимизации.
Тем не менее, FAQ про DirectShow есть вопрос, будет ли DirectShow доступен через managed код. Ответ — "нет", по причинам произвидительности. Я думаю, это честный ответ.
Здравствуйте, Pzz, Вы писали:
WF>>В локальных оптимизациях JIT находится не в худшей ситуации, чем обычный компилятор. Разве что у него жесткие рамки на скорость самой компиляции.
Pzz>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.
Не вижу проблем. Я вон даже пример приводил, где виртуальная функция была заинлайнена. LLVM, насколько я понимаю, именно над своим "биткодом" оптимизации делает.
Здравствуйте, Sinclair, Вы писали:
Pzz>>Я в принципе считаю статический контроль невредным изобретением. Позволяющим поймять многие типичные ошибки. В общем, развитие темы warning'ов в компиляторе. Но никакие warning'и не дают вам 100%-й гарантии надежности, а именно она нужна при отказе от защиты памяти времени исполнения. S>Singularity дает 100% гарантию надежности. В чем проблема?
Вы это повторяете, как мантру.
За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения?
Pzz>>Существует масса экспериментальных ОС, которые прекрасно справляются с исследовательскими задачами в условиях лаборатории. К сожалению, жизнь сложнее тех частных случаев, с которыми так замечательно справляются экспериментальные ОС в лаборатории. S>Основная проблема современных ОС — высокая стоимость системного вызова. Сингулярити показывает, как ее можно сократить еще примерно на порядок.
Сискол на линухе, который почти ничего не делает (gettimeofday(), например), занимает 1 микросекунду на довольно средненькой машине. Глядя на то, как в линухе реализована обработка сисколов, становится понятно, что его можно разогнать раз в 10, просто аккуратно перекодировав соответствующие места, без необходимости менять архитектуру. У них там в пути несколько сотен строк довольно развесистого сишного кода.
Это я к тому, что мешает использование именно аппаратной защиты. Плохому танцору известно, что мешает.
Здравствуйте, Pzz, Вы писали:
Pzz>Вы это повторяете, как мантру.
Это ты как мантру повторяешь про невозможность.
Pzz>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения? Re[10]: Wine
Здравствуйте, WFrag, Вы писали: WF>Так вот, ld/ld-linux (статический/динамический линкер) такой финт провернуть не могут (если неправ -- научите как их заставить ). Потому что информации на момент линковки в .so/.a недостаточно.
А они и не обязаны это уметь. Ибо UNIX-way, и каждый должен своим делом заниматься. Инструменты link-time оптимизации есть. Гуглите по "link-time optimization" (желатьльно с указанием целевой платформы). Вот, например: http://research.ac.upc.edu/pact01/wbt/debray.pdf.
Здравствуйте, Mr.Cat, Вы писали:
MC>А они и не обязаны это уметь. Ибо UNIX-way, и каждый должен своим делом заниматься. Инструменты link-time оптимизации есть. Гуглите по "link-time optimization" (желатьльно с указанием целевой платформы). Вот, например: http://research.ac.upc.edu/pact01/wbt/debray.pdf.
Согласен, какие-то оптимизации на x86 коде сделать можно. Вот только тот же LLVM всё равно их гораздо больше умеет и не в последнюю очередь за счёт своего представления кода. Ещё и на разных платформах работать будет.
Вот ещё интересная PDF-ка на эту тему: http://gcc.gnu.org/projects/lto/lto.pdf Собственно, там описывается ровно то, о чём я говорю — недостаток информации в объектных файлах и способ это обойти. Собственно, предлагается как раз вшивать в объектники промежуточного кода, который может использовать линкер для оптимизаци.
Здравствуйте, Pzz, Вы писали:
Pzz>Отличие от JIT, насколько я понимаю, заключается лишь в том, что AOT сохраняет результаты компиляции на диск? Т.е., при повторном запуске не надо еще раз перекомпилировать?
Компиляция происходит при инсталляции приложения. И верификация тоже.
Pzz>Однако, не из чего не следует, что качество кода при использовании этой технологии лучше, чем у JIT.
Хуже или лучше, это второй вопрос. Ты тут нам рассказывал про интерпретатор.
Здравствуйте, Pzz, Вы писали:
Pzz>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.
Вот в том то и проблема, что ты не понимаешь. Текущий JIT уже, к примеру, умеет выкидывать проверки границ массива в цикле.
Здравствуйте, WFrag, Вы писали:
Pzz>>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.
WF>Не вижу проблем. Я вон даже пример приводил, где виртуальная функция была заинлайнена. LLVM, насколько я понимаю, именно над своим "биткодом" оптимизации делает.
Вы не видите проблем как специалист по компиляторам, или как дилетант, не осознающий ограниченности своих знаних?
Я не вижу проблем сделать инлайнинг на уровне ассемблера или байт-кода — вставил нужный код в нужное место, прошелся peephole'м и все дела. Можно даже peephole'м не проходиться, если не знаешь, что это такое
Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.
Здравствуйте, Pzz, Вы писали:
Pzz>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.
А какие проблемы? Строим дерево и делаем анализ. Байткод для этого вполне адекватен.
Здравствуйте, WolfHound, Вы писали:
Pzz>>Вы это повторяете, как мантру. WH>Это ты как мантру повторяешь про невозможность.
Ну да. Вы утверждаете, что в природе существует некоторое чудо. Вполне справедливо, что на вас лежит бремя доказательства. По дефолту чудес не бывает
Pzz>>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения? WH>Re[10]: Wine