> больше данных гоняется по шине памяти

Кстати выполнение копирование большого куска памяти выполняется в 2 раза быстрей за счет в 2 раза большей разрядности регистров общего назначения. Происходит это не так уж и редко, тотже запуск приложения это по сути fork()+exec(), fork() копирует всю память приложения, такие дела.

>>30422
реальные измерения в студию, пожалуйста.

>>30423
Тестовая программа для x64:

#include <stdlib.h>

int main(void)
{
 int64_t* in;
 int64_t* out;
 in=(int64_t*)malloc(1073741824);
 out=(int64_t*)malloc(1073741824);
 int i;
 int j;
 for (i=1;i<100;i++) for (j=1073741824/sizeof(int64_t);j;j--) out[j]=in[j];
 return 0;
};

Для 32 бит int64_t был заменен на int32_t для чистоты эксперимента обе программы были собраны с -static, компиляция 32битной версии проводилась 32битным компилятором. Результат замера для 32 бит:

real    1m37.091s
user    1m35.354s
sys     0m1.740s

Для 64 бит:

real    1m14.646s
user    1m13.009s
sys     0m1.628s

Выполнялось все на одной машине.

>>30427
Nice job, bro.
Правда двукратной разницы я тут не вижу.
Кстати, разница может быть обусловлена двукратной разницей в количестве итераций цикла.

Интересно было бы посмотреть на статистику каких-нибудь реальных приложений. Все же на таких простых примерах оптимизатор работает превосходно и поэтому из железа вытягивается все, что только можно, а вот в реальных сложных приложениях такая оптимизация сложнее реализуема, поэтому, возможно, даже такой разницы мы можем не увидеть.

>>30434

> разница может быть обусловлена двукратной разницей в количестве итераций цикла

Именно этим она и обусловлена. 64 битный процессор за одно и тоже количество операций копирует в два раза больше данных.

> Правда двукратной разницы я тут не вижу.

Вполне естественно - значения переменных-счетчиков тоже хранятся в памяти и тоже считываются/пишутся при каждой итерации цикла.

> оптимизатор работает превосходно

Я без оптимизации собирал.

> даже такой разницы мы можем не увидеть

Вполне естественно, ведь реальные приложения это не только копирование памяти. Разницу производительности можно прикинуть по тому, какие операции преобладают и/или занимают больше всего времени. Например на чтении/записи HDD разницы никакой не будет, поскольку жесткий диск даже не подозревает, в каком режиме работает процессор.

Собрал с -Os и ручками свел внутренний цикл к виду

.L3:    
    movl    (%esi,%edx,4), %eax
    movl    %eax, (%ebx,%edx,4)
    decl    %edx
    jne     .L3

и

.L3:   
    movq    (%rbx,%rdx,8), %rax
    movq    %rax, (%rcx,%rdx,8)
    decq    %rdx
    jne     .L3

соответственно. Результаты получились ну совсем внезапными:
для x64:

real    1m7.272s
user    1m5.992s
sys     0m1.284s

для x86:

real    1m8.740s
user    1m7.476s
sys     0m1.268s

При всем при этом для x86 начальное значение %edx было 268435456, для x64 %rdx устанавливался в 134217728. Я что-то упустил в этой жизни?

...побайтовое копирование все того-же гига памяти:

real    1m13.918s
user    1m12.665s
sys     0m1.260s

Я совершенно точно что-то не понимаю в этой жизни.

На старом процессоре разница между побайтовым и почетырехбайтовым копированием как и положено состовляет 3-4 раза. Наверное не все еще потерянно.
Может кто-нибудь хочет протестировать у себя такое чудо?

чтобы можно было говорить с уверенностью хоть что-то, нужно дизассемблировать. С включенным (пусть и не на полную) оптимизатором и не такое возможно. При чем на сколько я знаю некоторые вещи оптимизатор делает по умолчанию (это делает кодогенератор и называется это не оптимизацией, а "избежание излишней пессимизации"): скажем в твоем коде на C скорее всего не было никакого индекса типа int, вместо этого скорее всего был указатель, который и изменялся (да, здесь это не так важно, но в случае с многомерными массивами - важно).

>>30462
Как тогда объяснить что написанное на ассемблере побайтовое копирование памяти по скорости выполнялось всего-лишь на 10% медленней копирования памяти 8байтными кусками?

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

>>30463
я же тебе и говорю, что не факт что он вполнял побайтовое копирование. Ассемблер или не ассемблер, думаю, оптимизатор все равно работает (хотя на асме я не работал, поэтому точно сказать не могу. Но не вижу логичной причины ему не работать).

>>30464
где гарантия того, что асм на выходе будет совпадать с бинарным кодом?

Кстати, не мог ли оптимизатор заточить все это под всякие SSE инструкции?

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

>>30465

> Ассемблер или не ассемблер, думаю, оптимизатор все равно работает (хотя на асме я не работал, поэтому точно сказать не могу. Но не вижу логичной причины ему не работать).

Ассемблерный код получается уже на выходе оптимизатора, в этом легко убедится, задав разные параметры оптимизации и сравнив ассемблерный код на выходе.

> где гарантия того, что асм на выходе будет совпадать с бинарным кодом?

Хочешь сказать что компилятор берет код с потолка, причем ради разнообразия при каждом своем запуске придумывает новый способ компиляции, просто for lulz? Запусти компиляцию одного и тогоже приложения десять раз подряд и после каждого раза проверяй md5sum выходного файла. Если компилятор с фантазией, ты сам, думаю, знаешь что получится.

> под всякие SSE инструкции?

Как ты себе это представляешь? SSE заточен под операции с плавающей точкой. Или может у тебя есть идеи, как это можно реализовать лучше предложенного ассемблерного кода?

извините за откровенную тупизну, но можно ли на машину с 32-битным процессором ставить 64-битную ОС, и если да то стоит ли это делать?
ламмер-кун

>>30468

> можно ли на машину с 32-битным процессором ставить 64-битную ОС

Нет, нельзя.

>>30467

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

Действительно, только что прочитал, что gcc проталкивает все asm вкрапления без изменений в gas. Хотя на мой взгляд, хорошо было бы и его оптимизировать, но учитывая, что мало кто пишет на асме, это неважно.

>Хочешь сказать что компилятор берет код с потолка, причем ради разнообразия при каждом своем запуске придумывает новый способ компиляции, просто for lulz? Запусти компиляцию одного и тогоже приложения десять раз подряд и после каждого раза проверяй md5sum выходного файла. Если компилятор с фантазией, ты сам, думаю, знаешь что получится.

Спасибо, кэп, об этом мы догадываемся.
А что если gas проводит какую-то платформо-зависимую оптимизацию? В этом случае дизассемблированный код будет отличаться от ассемблерного. (Делает ли он это, я не знаю, но это просто пример)

>Как ты себе это представляешь? SSE заточен под операции с плавающей точкой. Или может у тебя есть идеи, как это можно реализовать лучше предложенного ассемблерного кода?

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

>>30470

> А что если gas проводит какую-то платформо-зависимую оптимизацию?

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

> Ну там же есть команды пересылки чисел пачками, они бы и пригодились тут.

Представь себе ситуацию: человек на современной машине пишет код для какого-нибудь устройства с архитектурой i386, транслирует его на своей машине, запускает на целевой и вдруг оказывается что там напихано куча MMX и sse* инструкций и даже если бы оно и заработало, то делало бы совсем не то, что должно.

>>30471

>Ассемблерный код это просто несколько более человеческий вид машинных команд, именно поэтому и возможно дизасемблирование. Вся оптимизация происходит ДО выдачи ассемблерного кода. Олсо ассемблер сам по себе является платформо-зависимым языком.

Справедливо для интелловского синтаксиса, но не вполне справедливо для AT&T.

>Представь себе ситуацию: человек на современной машине пишет код для какого-нибудь устройства с архитектурой i386, транслирует его на своей машине, запускает на целевой и вдруг оказывается что там напихано куча MMX и sse* инструкций и даже если бы оно и заработало, то делало бы совсем не то, что должно.

Кто же знает, с какими параметрами ты транслировал. Олсо, я ничего не утверждал, а только сделал предположение.

>>30472

> но не вполне справедливо для AT&T

Есть процессоры, для которых это может быть оттранслировано, есть для которых нельзя это оттранслировать. А AT&T это просто синтаксис, хотя с ним тоже далеко не понятно, как например именовать например 15й регистр общего назначения.

бамп

>>33108
ты бы хоть что-нибудь постил от себя, ну там оценку треду давал, или- почему бамп. ну или тёр бы их хоть за собой.

>>30438
Кстати, твой код можно оптимизировать, если развернуть цикл (то есть выполнять в несколько раз больше операций за одну итерацию, но уменьшить количество итераций). Такие оптимизации часто делает компилятор, возможно, и этот раз не исключение.

>>33138
Смысл такой оптимизации? Наблюдаемая картина как раз таки сводится к тому, что код исполняется приблизительно одинаковое время вне зависимости от количества итераций и соответственно обращений к памяти.

>>33115
но он не услышал, он думал дыша- "и жить хорошо, и жизнь хороша!"

>>33239
Откуда столько уверенности в том, что в действительности там делается? Еще раз говорю, нужно дизассемблировать.
Но вообще-то, раскручивание циклов - известный метод оптимизации.

Олсо, где-то во время отладки недавно наткнулся на sse ускоренное копирование (memcpy). Так что эту оптимизацию отбрасывать не нужно.

>>35948
Описание и результаты эксперементов были приведены выше. Вместе с ассемблерным кодом.

Вот давно думаю, переходить на 64битную систему или нет. В 64 будут медленнее работать 32-битные приложения, куча проблем со сборкой софта, отдельный геморрой с вайном, флэшем, скайпом. При том, что 64битный софт у меня итак нормально работает в 32битной системе.

>>35962
Лично для меня единственный смысл использовать 64-битную систему - тестить свои приложения на работоспособность. Иного смысла я не вижу (во всяком случае для десктопа).

>>35962
Использую 64бит генту на одном из серверов. Субъективно работает несколько быстрее 32бит, хотя и памяти ест несколько больше. Думаю что причина прироста производительности - дополнительные регистры процессора. Проблем со сборкой серверного софта не замечал, все собирается так-же легко и непринужденно как и на 32бит. Десктопный софт не использовал, хотя не думаю что там что-то будет криво собираться. Олсо под 64битной системой совершенно спокойно стартуют 32разрядные приложения, если они собраны со статической линковкой. А вообще - сделай бекап системы и попробуй, если не понравиться - откатишься назад.

>>35971
Я использую много проприетарного софта, в том числе под вайном. Его, увы, не пересоберешь.

В данмаку с переводом в вайне я уже не поиграю в 64битной оси. А SWR и Hisoutensoku вообще не пойдут.

>32-bit Linux only. 64-bit platforms will fail, unfortunately, due to the DLL injection used. If you have an alternate functioning method I'd like to hear it.

Также проблемы с wineasio в 64-битной системе, без этого Cubase не будет работать нормально.

>>35977
А если собрать 32битный вайн?

>>35979
То он будет ощутимо тормозить в 64-битной системе. У вайна и без того очень сложно транслируются достаточно бредовые конструкции (я о реализации dx).

>>35977
у меня 64-гента на десктопе, ничего не делаю, а всё есть. ну а акнепроблемы с вайном не встречал, вообще его почти не использую.

>>35990
хотя обычная тохота в общем-то нормально работает.

Я был бы готов бороться за 64битную систему, если бы это давало ощутимые преимущества. К сожалению везде, где мне не хватает производительности - проприетарно.

>>35993
Серьезного прироста производительности при переходе на 64 битную ОС не будет, так что вполне можешь и на старой остаться, много не потеряешь.

Вобщем, на данный момент имеет смысл ставить 64-битную ОС только в том случае, если у тебя >64 гб ОП.

>>36044
Или если нужно много работать с 64 битными переменными или если нужны 64битные счетчики.

>>35984
Собственно случайно нагуглилось:

> То он будет ощутимо тормозить в 64-битной системе.

Либо воспользуюся гентой с multilib
http://www.gentoo.org/doc/ru/gentoo-amd64-faq.xml#multilib
Либо поставь 32битную систему в отдельный каталог и запускай то, что тебе нужно в 32битном режиме через chroot. В последнем случае снижения производительности не должно быть. Недостаток - откушаются лишние 1,5-3 гигабайта на винчестере.

>>36423

>http://www.gentoo.org/doc/ru/gentoo-amd64-faq.xml#multilib
>http://www.gentoo.org/doc/ru/
>ru

бамп

еще один дежурный бамп

На данный момент у g++ под x64 код С++ выходит на порядок медленне (1.5 - 2 раза) по причине другой модели памяти и обработки исключений. Поэтому от перехода на x64 могут быть только лишние проблемы.

>>48703
Можно линк на пруф? Поделюсь с упортыми коллегами.

>>36423

> Недостаток - откушаются лишние 1,5-3 гигабайта на винчестере.

А так же откушается солидно оперативки, для того чтобы держать в памяти 2 версии одной и той же либы.

>>48706
http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3946676

>>48711
Так это личные проблемы MinGW, и то пока DW2 не допилят для своих нужд.

>>48714
Ну да, и что?
Я же не говорю, что эта проблема никогда не будет решена.

>>48717
Да, но, увы, линукс-кунам это по тангенту.