Байт-код vs. нативный код

Tiphon · 08-11-10 06:00:44

petrun пишет:

Если так, то в идеальном мире этим должна ОС заниматься.

Но наш мир - не идеальный. Я говоню .NET (и в статье из ссылки из первого поста говорится про .NET) тк.к. в реальном мире это лучшая и самая широкая реализация на настоящий момент. А гонять сферических коней в вакууме можно в теме про зеленых человечков))

Хотя, пожалуй, одного сферического коня в вакууме я погоняю. Мне кажется, что байткод - штука полезная с точки зрения JIT. Jit - это вообще, на мой взгляд, будущее. Тк.к. обычная оптимизация имеет предел - неизвестное поведение в ран тайме.Далее по уровню должен идти JIT, который делает оптимизацию исходя из опыта работы в рилтайм. Так же, как и с ассемблером, есть моменты, которые машине рассчитать и оптимизировать легче, чем человеку.

Если тебя есть языки, они транслируются в байт код, а из него в нативный с различными оптимизациями. Так вот как раз с точки зрения JIT иметь байткод и потихоньку пересобирать необходимые части - наиболее удобно. Отличное убиение еще и этого зайца.

З.Ы. Это тебе ответы на 11 и 14

ikkunan salvataja · 08-11-10 14:02:20

Zloy пишет:

На тебе на VB

Пашик, ты почто жульничаешь? Ты тогда что говорил? Слова не разрезать, разрезать по пробелам. А этот вариант на тебе:

    cld
    mov ecx,file_length
    mov esi,offset source_file
    mov edi,offset target_file
    xor bl,bl
l0:    lodsb
    stosb
    inc bl
    cmp bl,80
    je l1
    loop l0
    ret
l1:    xor bl,bl    
    mov word ptr [edi],0A0Dh
    add edi,2
    jmp short l0

ЗЫ: Про команду movsb я знаю.

Отредактировано ikkunan salvataja (08-11-10 14:05:09)

Майор Очевидность · 08-11-10 18:22:45

ikkunan salvataja,
вчитавшись в Ваш код, нашёл в нём довольно серьёзный баг.
если в середине 80-символьного "окна" находится хоть один \n, то остаток (меньший по длине, чем 80 символов) не будет дополнен до "полных" 80.

так, при "окне" в 8 символов, текст

абвг
1234567890

будет преобразован так:

абвг
123
4567890

хотя нужно

абвг
12345678
90

на досуге набросал "полную" реализацию, без предусловия, что файл уже загружен в память.
вход: файл с именем из переменной fnm.
выход: stdout.

[SECTION .data];
  len: EQU 50h;
  sym: EQU 0Ah;
  fnm: DB "/dev/urandom"
  buf: RESB len;
  DB sym;

[SECTION .text];
  MOV RBX, fnm;
  XOR RCX, RCX;
  MOV RAX, 5;            <-- SYS_OPEN
  INT 80h;

  MOV RSI, RAX;
  MOV RDX, len;
  MOV RCX, buf;
  STD;

  @loop:
    MOV RBX, RSI;
    MOV RAX, 3;          <-- SYS_READ
    INT 80h;

    TEST RAX, RAX;
  JE @quit;

    LEA RCX, [RDX+1];
    MOV RDI, buf+len-1;
    MOV RAX, sym;
    REPNE SCASB;

    MOV RDI, RDX;
    SUB RDI, RCX;
    CMP RDI, RDX;
    CMOVE RDI, RCX;
    LEA RCX, [RDX+1];
    CMOVE RDX, RCX;

    SUB RCX, buf+len+1;
    NEG RCX;
    XOR RBX, RBX;
    MOV RAX, 4;          <-- SYS_WRITE
    INT 80h;

    LEA RCX, [RDI+buf];
    MOV RDX, len;
    SUB RDX, RDI;
  JMP @loop;

  @quit:
  MOV RAX, 1;            <-- SYS_EXIT
  INT 80h;

Lord_Evil · 08-11-10 18:29:28

Майор Очевидность, пи*ц, дай мне подробную вступительную по asm! Плиз!

Майор Очевидность · 08-11-10 18:34:14

Gentoo, проверь ПМ.

ikkunan salvataja · 08-11-10 19:11:03

Майор Очевидность пишет:

вчитавшись в Ваш код, нашёл в нём довольно серьёзный баг.

Это не баг, было условлено что преобразуется именно одна длинная строка, т.е. никаких 0A и 0D внутри нет, посему проверка на это и не делалась.

Майор Очевидность · 08-11-10 19:27:40

ikkunan salvataja,
а. тогда звиняюсь.
просто у Павла в коде есть открытие файла, вот и подумал, что нужен файл из строк.

petrun · 08-11-10 19:33:08

Tiphon пишет:

Но наш мир - не идеальный. Я говоню .NET

Вы Знаете, я NET. мало щупал. По виду от явы принципиальных отличий нет.Те же несколько Яп используют одни классы, тот же джит.
Возможность использовать cpp соминтельна, там совсем другой cpp.

Tiphon пишет:

Хотя, пожалуй, одного сферического коня в вакууме я погоняю. Мне кажется, что байткод - штука полезная с точки зрения JIT. Jit - это вообще, на мой взгляд, будущее. Тк.к. обычная оптимизация имеет предел - неизвестное поведение в ран тайме.Далее по уровню должен идти JIT, который делает оптимизацию исходя из опыта работы в рилтайм. Так же, как и с ассемблером, есть моменты, которые машине рассчитать и оптимизировать легче, чем человеку.
Если тебя есть языки, они транслируются в байт код, а из него в нативный с различными оптимизациями. Так вот как раз с точки зрения JIT иметь байткод и потихоньку пересобирать необходимые части - наиболее удобно. Отличное убиение еще и этого зайца.

На мой взгляд вы несколько идеализируете.Да, ест ьмоменты в которых джит будет быстрее и даже значительно быстрее.Это и частое выделение-освобождение памяти и возможность применения методик суперкомпиляции, и кодогенератор под конкретный ЦП. Но от проигрыша, вызванного необходимость работать быстро тоже никуда не деться. Как пример - для полноценного анализа потоков данных комманд очень неплохо иметьобщую таблицу псевдонимов указателей, что в джитах мало реально, там код кусками компилится. Для распаралеливания на уровне циклов неплохо иметь общий граф(ну да, в общем виде неразрешимо ж)) зависимостей данных. Ну и так далее. Какая-то часть этих методик может быть реализованна, но многие требуют обратной связи между оптимизатором трехадресного кода и кодогенератором.

ikkunan salvataja · 08-11-10 19:53:26

Майор Очевидность пишет:

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

А Пашик вначале вообще просил по словам не резать, только в промежутке между ними.

Gentoo пишет:

пи*ц, дай мне подробную вступительную по asm! Плиз!

Выдаю первый листинг с комментариями.

     std ;направление цепочечных команд справа-налево. 
      mov edi,offset begin_of_string+80 ;устанавливаем edi на участок памяти с файлом +80 байт
      mov esi,offset end_of_string ; esi на конец этого файла в памяти.
      mov al," " ;грузим в al код пробела
      mov bl,0Ah ;грузим в bl код конца строки.
l0:     mov cx,80 ;требуемая длина строки в cx
      repne scasb ; сканируем участок памяти, на который указывает di справа налево (std вначале программы)
; до первого совпадения со значением в al, количество сканируемых ячеек в cx, при каждом сравнении di и cx
;уменьшаются на единицу      
      or cx,cx ;проверяем cx на равенство 0
      jz stl ; и если 0 передаём управление по адресу stl
      mov    [di],bl ; прописываем в ячейку памяти на которую указывает di значение в регистре bl, т.е. конец строки
      add edi,80 ; прибавляем к регистру edi 80 
      cmp di,si ; проверяем не больше ли он регистра si, т.е. достигнут ли конец проверяемого участка.
      jae    er ; если больше или равно управление по адресу er
      jmp l0 ;иначе переход на l0
er:  ret ; возврат из процедуры.
stl: call print_message_string_to_long ; вызов условной процедуры сообщения об ошибке.
      ret ; возврат

Lord_Evil · 08-11-10 20:20:28

ikkunan salvataja, спасибо. Сохраню покурю, мб поумнею smile

Tiphon · 08-11-10 21:55:24

petrun пишет:

По виду от явы принципиальных отличий нет.

Идейно они похожи. Но реализации различаются и чем дальше, тем больше. В начале было, что давайте не устраивать C# VS Java. Поддерживаю. Я говорю, что лучше, а что хуже.
Но про разницы в реализациях идей

www.codeproject.com/KB/dotnet/clr.aspx#_java_program
www.25hoursaday.com/CsharpVsJava.html#conclusion2k7 (2007 года статья - старьё!)

petrun пишет:

... Но от проигрыша, вызванного необходимость работать ...

Всегда в таких случаях есть некие "оптимумы".

petrun · 08-11-10 22:15:12

Tiphon
Я тоже не устраиваю срач, я говори, что в контексте "байткод" это одно и то же.

Tiphon пишет:

Всегда в таких случаях есть некие "оптимумы".

Да.И, по моему мнению, в общем слуучае оптимум не за JIT.

Tiphon · 08-11-10 22:18:05

Это ты передернул фразу.

petrun пишет:

оптимум не за JIT

А за чем?

petrun · 08-11-10 22:20:52

Tiphon пишет:

А за чем?

По отношению быстродействия к скорости разработки - ФЯ компилирующиеся в натив.
P.S haskell - крайний случай, не приводите его в пример.

Отредактировано petrun (08-11-10 22:21:20)

Tiphon · 08-11-10 22:32:49

petrun пишет:

ФЯ компилирующиеся в натив

И где тогда такие ФЯ?
Что дают ФЯ по сравнению с байт кодом?
Т.е. что мешает байт код скомпилировать в нативный так же оптимально, как Фя?

petrun · 09-11-10 01:22:29

Tiphon
Ну вы сравнили теплое с мягким. Имелось в виду просто "нативный код". А ФЯ - для скорости разработки.
А скомпилировать байткод в нативный много что мешает. Хотя-бы eval.

Отредактировано petrun (09-11-10 01:22:55)

Tiphon · 09-11-10 03:29:32

petrun пишет:

Хотя-бы eval.

Это ты байткод с интерпретаторами попутал? С какого перепугу в C# будет эвал?

Mike22 · 10-11-10 11:35:58

Не вдаваясь подробно в срач, хочу отметить, что в оригинале автор лукавит насчет сравнительных трат памяти. Ruby - это совсем не типичное решение.

Форум StopLinux

Объявление

#26 08-11-10 06:00:44

Re: Байт-код vs. нативный код

#27 08-11-10 14:02:20

Re: Байт-код vs. нативный код

#28 08-11-10 18:22:45

Re: Байт-код vs. нативный код

#29 08-11-10 18:29:28

Re: Байт-код vs. нативный код

#30 08-11-10 18:34:14

Re: Байт-код vs. нативный код

#31 08-11-10 19:11:03

Re: Байт-код vs. нативный код

#32 08-11-10 19:27:40

Re: Байт-код vs. нативный код

#33 08-11-10 19:33:08

Re: Байт-код vs. нативный код

#34 08-11-10 19:53:26

Re: Байт-код vs. нативный код

#35 08-11-10 20:20:28

Re: Байт-код vs. нативный код

#36 08-11-10 21:55:24

Re: Байт-код vs. нативный код

#37 08-11-10 22:15:12

Re: Байт-код vs. нативный код

#38 08-11-10 22:18:05

Re: Байт-код vs. нативный код

#39 08-11-10 22:20:52

Re: Байт-код vs. нативный код

#40 08-11-10 22:32:49

Re: Байт-код vs. нативный код

#41 09-11-10 01:22:29

Re: Байт-код vs. нативный код

#42 09-11-10 03:29:32

Re: Байт-код vs. нативный код

#43 10-11-10 11:35:58

Re: Байт-код vs. нативный код

Подвал форума