Re[17]: Альтернативные ОС
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.08 09:03
Оценка:
Здравствуйте, Sheridan, Вы писали:

>> В простых случаях JIT устраняет проверки на выход за границы. В сложных — к операции доступа добавляется одна ассемблерная инструкция.

S>Синклер, глянь в этой ветке на пару сообщений выше.
S>Цитирую "Сингулярити не использует JIT."

Т.е. Синклеру нельзя ничего про обычный джит в обычном дотнет писать, раз сингулярити его не использует ?
Re[31]: Альтернативные ОС
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.08 09:06
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>WFrag однажды (26 июня 2008 [Четверг] 12:33) писал в rsdn.flame.comp:


>> Да. Могу тебя порадовать. Это замечательно работает в пределах _одного_ .c файла.

S>Помоему инлайнинг внешних функций противоречит самой концепции С/С++, хотя не уверен
S>Да и с дальнейшей поддержкой тяжко будет.

А с перформансом то что ?

S>Тоесть "давай наперегонки, только я на велосипеде, а ты на карачках"?

S>Я правильно понял, что С код специально ограничивали от инлайнинга?

Почему же ? Пусть линкер покажет, как он умеет инлайнить.
Re[18]: Альтернативные ОС
От: Sheridan Россия  
Дата: 26.06.08 09:07
Оценка:
Ikemefula однажды (26 июня 2008 [Четверг] 13:03) писал в rsdn.flame.comp:

> Т.е. Синклеру нельзя ничего про обычный джит в обычном дотнет писать, раз сингулярити его не использует ?

А я откуда знал что у вас там джитов как блох на дворняге?

--
...belive in the matrix...
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[31]: Альтернативные ОС
От: WFrag США  
Дата: 26.06.08 09:08
Оценка:
Здравствуйте, 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);
    }
}


Поехали.

Динамическая линковка (C):
wfrag@fragentoo ~/test/1 $ gcc -O3 -funroll-loops -finline-functions dosum.c -o libdosum.so -shared
wfrag@fragentoo ~/test/1 $ gcc -O3 -funroll-loops -finline-functions -L. -ldosum test4.c 
wfrag@fragentoo ~/test/1 $ LD_LIBRARY_PATH=. ./a.out 10 1000000000
l = 451808768
48.170000


Статическая линковка (C):
wfrag@fragentoo ~/test/1 $ gcc -O3 -funroll-loops -finline-functions dosum.c -o libdosum.so -c
wfrag@fragentoo ~/test/1 $ gcc -O3 -funroll-loops -finline-functions -L. -ldosum test4.c 
wfrag@fragentoo ~/test/1 $ ./a.out 10 1000000000
l = 451808768
43.780000


"Склееный" случай (C):
wfrag@fragentoo ~/test/1 $ cat test4.c dosum.c  > test4combined.c
wfrag@fragentoo ~/test/1 $ gcc -O3 -funroll-loops -finline-functions test4combined.c 
wfrag@fragentoo ~/test/1 $ ./a.out 10 1000000000
l = 451808768
1.850000


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 с статической/динамической линковкой.
Re[32]: Альтернативные ОС
От: Sheridan Россия  
Дата: 26.06.08 09:16
Оценка:
Ikemefula однажды (26 июня 2008 [Четверг] 13:06) писал в rsdn.flame.comp:

>>> Да. Могу тебя порадовать. Это замечательно работает в пределах _одного_ .c файла.

> S>Помоему инлайнинг внешних функций противоречит самой концепции С/С++, хотя не уверен
> S>Да и с дальнейшей поддержкой тяжко будет.
> А с перформансом то что ?
А куда оно денется. с -O3 соберем.
Что с поддержкой?

> S>Тоесть "давай наперегонки, только я на велосипеде, а ты на карачках"?

> S>Я правильно понял, что С код специально ограничивали от инлайнинга?
> Почему же ? Пусть линкер покажет, как он умеет инлайнить.
Ясно. Тобишь тестировался именно линкер, тогда как со стороны явы тестировался весь комплекс. Замечательно.

--
...belive in the matrix...
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[33]: Альтернативные ОС
От: WFrag США  
Дата: 26.06.08 09:20
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>Ясно. Тобишь тестировался именно линкер, тогда как со стороны явы тестировался весь комплекс. Замечательно.


А теперь загляни в каталог /usr/lib и посмотри сколько там работы для линкера Или посчитай количество .o файлов, скажем, для KDE или Gnome. Всех их связывать будет именно линкер.
Re[12]: Альтернативные ОС
От: Трурль  
Дата: 26.06.08 10:05
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Вобще говоря бинарник с управляемым кодом имеет очень интересное свойство: В нем есть вся информация которая есть в исходниках. За исключением форматирования и комментариев.

WH>Те исходники нам и не нужны.

С другой стороны, при наличии исходников, нам не нужны бинарники с управляемым кодом.
Re[13]: Альтернативные ОС
От: WFrag США  
Дата: 26.06.08 10:44
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>С другой стороны, при наличии исходников, нам не нужны бинарники с управляемым кодом.


Ага. И как быстро будут работать, например, те же глобальные оптимизации? Ты предлагаешь в каждую динамичскую библиотеку вшивать её исходники?

Посмотри, например, на LLVM. Там байт-код как раз для этой цели и используется -- для оптимизаций.
Re[18]: Альтернативные ОС
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.06.08 12:30
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>В локальных оптимизациях JIT находится не в худшей ситуации, чем обычный компилятор. Разве что у него жесткие рамки на скорость самой компиляции.


Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.

WF>А вот в плане глобальных оптимизаций у него есть преимущества.


Это правда. Кроме того, у него есть очевидное преимущество в плане использования результатов профилирования для выборов стратегии оптимизации.

Тем не менее, FAQ про DirectShow есть вопрос, будет ли DirectShow доступен через managed код. Ответ — "нет", по причинам произвидительности. Я думаю, это честный ответ.
Re[19]: Альтернативные ОС
От: WFrag США  
Дата: 26.06.08 12:41
Оценка:
Здравствуйте, Pzz, Вы писали:

WF>>В локальных оптимизациях JIT находится не в худшей ситуации, чем обычный компилятор. Разве что у него жесткие рамки на скорость самой компиляции.


Pzz>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.


Не вижу проблем. Я вон даже пример приводил, где виртуальная функция была заинлайнена. LLVM, насколько я понимаю, именно над своим "биткодом" оптимизации делает.
Re[14]: Альтернативные ОС
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.06.08 12:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

Pzz>>Я в принципе считаю статический контроль невредным изобретением. Позволяющим поймять многие типичные ошибки. В общем, развитие темы warning'ов в компиляторе. Но никакие warning'и не дают вам 100%-й гарантии надежности, а именно она нужна при отказе от защиты памяти времени исполнения.

S>Singularity дает 100% гарантию надежности. В чем проблема?

Вы это повторяете, как мантру.

За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения?

Pzz>>Существует масса экспериментальных ОС, которые прекрасно справляются с исследовательскими задачами в условиях лаборатории. К сожалению, жизнь сложнее тех частных случаев, с которыми так замечательно справляются экспериментальные ОС в лаборатории.

S>Основная проблема современных ОС — высокая стоимость системного вызова. Сингулярити показывает, как ее можно сократить еще примерно на порядок.

Сискол на линухе, который почти ничего не делает (gettimeofday(), например), занимает 1 микросекунду на довольно средненькой машине. Глядя на то, как в линухе реализована обработка сисколов, становится понятно, что его можно разогнать раз в 10, просто аккуратно перекодировав соответствующие места, без необходимости менять архитектуру. У них там в пути несколько сотен строк довольно развесистого сишного кода.

Это я к тому, что мешает использование именно аппаратной защиты. Плохому танцору известно, что мешает.
Re[15]: Альтернативные ОС
От: WolfHound  
Дата: 26.06.08 14:12
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Вы это повторяете, как мантру.

Это ты как мантру повторяешь про невозможность.

Pzz>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения?

Re[10]: Wine
Автор: WolfHound
Дата: 22.06.08
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Альтернативные ОС
От: Cadet  
Дата: 26.06.08 14:20
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Купи мне винду и студию...


По твоим словам в другом топике у тебя дома виста есть . А отладчик можно бесплатный взять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1091>>
Re[26]: Альтернативные ОС
От: Mr.Cat  
Дата: 26.06.08 15:08
Оценка:
Здравствуйте, WFrag, Вы писали:
WF>Так вот, ld/ld-linux (статический/динамический линкер) такой финт провернуть не могут (если неправ -- научите как их заставить ). Потому что информации на момент линковки в .so/.a недостаточно.

А они и не обязаны это уметь. Ибо UNIX-way, и каждый должен своим делом заниматься. Инструменты link-time оптимизации есть. Гуглите по "link-time optimization" (желатьльно с указанием целевой платформы). Вот, например: http://research.ac.upc.edu/pact01/wbt/debray.pdf.
Re[27]: Альтернативные ОС
От: WFrag США  
Дата: 26.06.08 15:24
Оценка:
Здравствуйте, 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 Собственно, там описывается ровно то, о чём я говорю — недостаток информации в объектных файлах и способ это обойти. Собственно, предлагается как раз вшивать в объектники промежуточного кода, который может использовать линкер для оптимизаци.
Re[17]: Альтернативные ОС
От: Ночной Смотрящий Россия  
Дата: 26.06.08 15:33
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Отличие от JIT, насколько я понимаю, заключается лишь в том, что AOT сохраняет результаты компиляции на диск? Т.е., при повторном запуске не надо еще раз перекомпилировать?


Компиляция происходит при инсталляции приложения. И верификация тоже.

Pzz>Однако, не из чего не следует, что качество кода при использовании этой технологии лучше, чем у JIT.


Хуже или лучше, это второй вопрос. Ты тут нам рассказывал про интерпретатор.
&
Re[19]: Альтернативные ОС
От: Ночной Смотрящий Россия  
Дата: 26.06.08 15:33
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.


Вот в том то и проблема, что ты не понимаешь. Текущий JIT уже, к примеру, умеет выкидывать проверки границ массива в цикле.
&
Re[20]: Альтернативные ОС
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.06.08 19:25
Оценка:
Здравствуйте, WFrag, Вы писали:

Pzz>>Тем не менее, в худшей. Я, например, не очень понимаю, каким образом во время JIT можно сделать constant propagation, вынос инварианта из цикла, common subexpression elimination и т.п.


WF>Не вижу проблем. Я вон даже пример приводил, где виртуальная функция была заинлайнена. LLVM, насколько я понимаю, именно над своим "биткодом" оптимизации делает.


Вы не видите проблем как специалист по компиляторам, или как дилетант, не осознающий ограниченности своих знаних?

Я не вижу проблем сделать инлайнинг на уровне ассемблера или байт-кода — вставил нужный код в нужное место, прошелся peephole'м и все дела. Можно даже peephole'м не проходиться, если не знаешь, что это такое

Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.
Re[21]: Альтернативные ОС
От: Cyberax Марс  
Дата: 26.06.08 19:30
Оценка: +2
Здравствуйте, Pzz, Вы писали:

Pzz>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.

А какие проблемы? Строим дерево и делаем анализ. Байткод для этого вполне адекватен.
Sapienti sat!
Re[16]: Альтернативные ОС
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.06.08 19:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

Pzz>>Вы это повторяете, как мантру.

WH>Это ты как мантру повторяешь про невозможность.

Ну да. Вы утверждаете, что в природе существует некоторое чудо. Вполне справедливо, что на вас лежит бремя доказательства. По дефолту чудес не бывает

Pzz>>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения?

WH>Re[10]: Wine
Автор: WolfHound
Дата: 22.06.08


За счет чего осуществляется гарантия того, что программа не вылезет из своей песочницы?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.