Автор Тема: Сложенщики, умноженцы и такты (Прочитано 14458 раз)

Watson · « : 26 Сентябрь 2006, 18:08:10 »

Раздел: "Здесь мы делимся информацией, опытом, навыками"
Тема: Хелп!!!! Умножение на 2!!! Проблемы с семеркой!!
Новичок: Уважаемые завсегдатаи. Юзаю таблицу умножения на 2. Все вроде нормально, но почему-то 7 на 2 не умножается. Помогите, пожалуйста! Как правильно умножить 7 на 2?
Гуру1: Таблица умножения на 2 - АЦТОЙ!!!! Юзай таблицу умножения на 5!!! Таблица умножения на 5 - рулит!!!
Новичок: А там как реализовано умножение 7 на пять?
Гуру1: RTFM!!!!
Новичок: Дай ссылку на TFМ, пожалуйста..
Гуру1: www.google.com
Гуру2: Мой тебе совет - снеси нафиг двойку. Поставь семерку. А если железо старое то троечку. Самое то. У меня семерка стоит.
Гуру3: Достали ламеры уже со своими дурацкими вопросами! Таблица умножения на 7 тоже ацтой. Я пользуюсь сложением и никогда не имел проблем. Пока у тебя семерка умножает на два у меня десять раз сложить две единицы успевает.
Гуру1: Слышь, ты гуру3, сам ты отстой. На фиг две единицы - человек тебя спрашивает как УМНОЖИТЬ 7 на 2.
Гуру2: Сложение - мастдай!!!! Сложенщики - тупые.
Гуру3: Гуру1, ты дурак что ли? Сделать (1+1)+(1+1)+(1+1)+(1+1)+(1+1)+(1+1)+(1+1) - тебе не позволяет религия?
Гуру2: гыгыгы))) Ламо!! 2*7 - и все!
Новичок: Гуру2 И сколько будет, а? То что надо!
Гуру2: RTFM, lma0.
Гуру3: Гуру2 , за базар ответишь!! В реале слабо сказать мне это?
Гуру2: Сложеньщик тупой! Не переноси виртуал в реал! Сиди и мастурбируй на свое сложение!
Гуру3: Все! Достал! Я знаю твой ай-пи! Тебе капец!!!
Гуру1: Не устраивайте тут срачь.
Гуру3: Я и твой айпи знаю!!! Диалапщик. гыгыгыгы... великий магистр умножения на диалапе!
Новичок: 7 на 2 как умножить-то??
Гуру1: Вали отсюда, ламер ушастый! Иди книжки читай! Твой уровень - сложение!
Гуру3: СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!СЛОЖЕНИЕ-РУЛИТ!! УМНОЖЕНИЕ-ОТСТОЙ!!!!
Гуру2: Куда смотрит модератор!!!!!!

Din

Кстати, да. Поддерживаю...(echo 7+7 | bc) рулит :lol:

user_anonymous

;D ;D ;D
Вообще этот пост мне что-то очень напоминает... Давайте будем стараться не быть похожими на этих гуру

Din

Цитата: user_anonymous от 27 Сентябрь 2006, 10:05:47

;D ;D ;D
Вообще этот пост мне что-то очень напоминает... Давайте будем стараться не быть похожими на этих гуру

У нас вот так, имхо:
- сложение рулит, потому что не все микроконтроллеры способны выполнить mul, в таком случае арифметические операции реализуются через сложение.
-очень редко так бывает. В настоящее время любой контроллер обладает универсальным АЛУ, а иногда и аппаратным умножением
-но при универсуме (наиболее распространенный вариант) 7+7 выполнится быстрее чем 7*2. Потому лучше здесь использовать сложение.
...можно продолжать

Доказываешь? Аргументируй.

В споре рождается истина...иногда

mef

собственно достаточно зайти на любой irc-сервер на канал #linux и спросить что лучше ставить слаку, генту или дебиан будет тоже самое

Сомневающийся_В_Unix

Цитата: Din от 27 Сентябрь 2006, 12:07:12

-но при универсуме (наиболее распространенный вариант) 7+7 выполнится быстрее чем 7*2. Потому лучше здесь использовать сложение.

Хм... А я то думал, что современные процы выполняют несколько операций подобных sin(x) за такт....

Watson

Цитата: mef от 27 Сентябрь 2006, 12:08:07

собственно достаточно зайти на любой irc-сервер на канал #linux и спросить что лучше ставить слаку, генту или дебиан будет тоже самое

Во-во - я после прочтения сего приколе переключился на форум посвещённый процам. Первый попавшийся пост настолько хорошо вписался в общую стилистику, что показалось, что читаю продолжение.... :blink:

Din

Цитата: Сомневающийся_В_Unix от 27 Сентябрь 2006, 15:55:37

Хм... А я то думал, что современные процы выполняют несколько операций подобных sin(x) за такт....

Вы в топик пишете? Если да, то еще укажите точность синуса, соответствующую вашим запросам. Хотя... тоже хочу такой проц

Вас наверное в заблуждение ввело наличие команды FPU fsin. Современные процы разбивают инструкцию x86 на несколько унифицированных операций которые и исполняются за такт. В моем P4 вроде бы 2 функциональных устройства с плавающей точкой и 3 целочисленных АЛУ которые могут выполнить при определенных условиях 3 операции (uops) за один такт. Только выполнить. . Если наша переменная X, не в кеше первого уровня то еще и на чтении куча времени потеряется...короче ладно, FPU команда fsin будет разбита, грубо говоря, на 20-100 uops в зависимости от точности...sse2 наверное быстрее.

Продолжая спор с самим собой...

Если отойти от контроллеров и взять наши десктопные процы, то здесь исполнение инструкций mul и add займет лишь один такт. Однако mul даст задержку в случае если она находиться в цепочке зависимостей...и не помню сколько тактов

Добавил: сорри за много буков

Din

Продолжаем разговор так сказать

Евгений, до меня дошло, вы про аппаратный синус в процах видеокарт говорили. От него уже отказались: много транзисторов - мало толку. Даже попользовать на программном уровне не успели...
www.ixbt.com/video2/nv40-part1.shtml

Сомневающийся_В_Unix

Цитата: Din от 27 Сентябрь 2006, 18:32:09

Продолжаем разговор так сказать

Евгений, до меня дошло, вы про аппаратный синус в процах видеокарт говорили. От него уже отказались: много транзисторов - мало толку. Даже попользовать на программном уровне не успели...
www.ixbt.com/video2/nv40-part1.shtml

Да тут ХЗ....
Счас вот ставил тесты на своем компе. На C# писал.

Код: [Выделить]

Utils.PerfCounter pc = new Utils.PerfCounter();
            pc.Start();
            for (int i = 0; i < 1000000; i++)
            {
                double d = Math.Sin(i);
            }
            float f = pc.Finish();
            MessageBox.Show("Прошло " + f.ToString());

Класс PerfCounter тут
Получилось на вычисление 1 синуса 3 такта процессора. У меня "устаревший" AMD Athlon 3000+ 1.81 Ггц.
А что говорить про новые процы Intel?

Сомневающийся_В_Unix

Причем замена

Код: [Выделить]

double d = Math.Sin(i);на

Код: [Выделить]

Int32 i1 = i + i;Не делает результат исполнения более долгим.
Плюс система должна еще выполнять цикл :slow:

Сомневающийся_В_Unix

И побочный эффект эксперимента, скорость выполнения программ, написанных на C# вообще больше скорости выполнения программ написанных на ASM.
Если конечно участок кода требует интенсивных вычислений. Программа на C# пройдет через 2 оптимизирующих компилятора, последний из которых сгенерирует минимальное количество самых быстрых машинных инструкций для того процессора, на котором исполняется!

Din

Цитата: Сомневающийся_В_Unix от 27 Сентябрь 2006, 19:04:14

Класс PerfCounter тут
Получилось на вычисление 1 синуса 3 такта процессора. У меня "устаревший" AMD Athlon 3000+ 1.81 Ггц.
А что говорить про новые процы Intel?

На самом деле точное количество тактов очень трудно посчитать из юзерспейса - от прерываний никуда не дется, а кроме того усугубляют ситуацию невыровненный код, промахи в кэш, исключения... Поэтому эксперименты из третьего кольца в винде могут дать лишь приблизительную оценку скорости выполнения. Вот если бы был какой-нибудь системный вызов для этого... Я так понимаю что ваш класс PerfCounter есть обертка вокруг rdtsc. Если можете взгляните в дебагере. На masm замер выглядит так:

Код: [Выделить]

      xor eax, eax
         cpuid                    
         rdtsc                           
         mov dword ptr res, eax         
         mov dword ptr res+4, edx    
         xor eax, eax
         cpuid

Судя по документации PerfCounter возвращает время в секундах. Проверьте внимательно свой результат. А быть может вы видите мат. запись вида 3.04011E+008 и неправильно ее интерпретируете. К тому же в вашем коде надо бы разделить результат на количество проходов цикла, дабы получить среднее количество тактов. Вы получаете общее.

На p4 prescott 3Ghz получаю ~270 тактов для double и ~340 для long double (с++). Многовато конечно, но повторяю это лишь приблизительные результаты, которые могут использоваться для измерения скорости участка кода. Уточнить количество тактов на команду можно в мануалах от производителей МП. Только там сейчас пишут микрокод и унифицированные операции вместо тактов, по крайней в мере на пентиумах. В амд я не разбирался, но думаю там также только uops по другому называются.

Цитата: Сомневающийся_В_Unix от 27 Сентябрь 2006, 21:15:16

Если конечно участок кода требует интенсивных вычислений. Программа на C# пройдет через 2 оптимизирующих компилятора, последний из которых сгенерирует минимальное количество самых быстрых машинных инструкций для того процессора, на котором исполняется!

Естественно, везде в любом языке компилятор пытается выжать максимум. Вот например говорят что реализация алгоритма вычисления синуса с sse2 получается быстрее, но ни один компилятор не станет без прямой команды использовать эти инструкции. Так компилер vc7 просто вызывает fsin как и предполагалось (смотрел в дебаге), не удивлюсь если другие варианты вообще не предусмотрены . Т.е вся ответственность за оптимизацию ложится на плечи программиста. И вы меня конечно извините, но я сомневаюсь что среднестатистический дотнетовец вообще станет задумываться о подобных "мелочах". Лично меня очень увлекают подобные темы и честно говоря приятно удивляет что вы проявляете к этому интерес...

Сомневающийся_В_Unix

Итак, время исполнения 0,001690997 сек.
Делим на миллион(количество операций), получаем время на 1 вычисление.
Полечаем 0,000000001690997 секунд, одно вычисление.
Умножаем на 1810000000(тактовая частота процессора).
Получаем 3,06070457 такта на вычисление.
Повторяю, в .NET всегда будет выбрана лучшая комманда.
1 компиляция - компиляция высокоуровневого языка в MSIL, благодаря этому получаем совместимостимость между разлияными .NET языками. Разные части программы могут быть написаны на разных языках.
2 компиляция(может проходить при инсталяции программы) - компиляция в комманды процессора ситемы. И если есть у меня sse2, то и будет использована она.

Сомневающийся_В_Unix

Хм... Всетаки я малось лопухнулся!
Если объявлять так

Код: [Выделить]

           for (int i = 0; i < 1000000; i++)
            {
              double  d = Math.Sin(i);
            }

То компилятор видит, что d больше нигде не используется генерит вот такие машинные инструкции.

Код: [Выделить]

            {
              double  d = Math.Sin(i);
00000042  nop              
            for (int i = 0; i < 1000000; i++)
00000043  inc         ebx  
00000044  cmp         ebx,0F4240h 
0000004a  jl          00000042

Тоесть нифига не вычисляет синуса

Если попытаться использовать d за пределами цикла

Код: [Выделить]

Utils.PerfCounter pc = new Utils.PerfCounter();
            double d = 0;
            pc.Start();            
            for (int i = 0; i < 1000000; i++)
            {
              d = Math.Sin(i);
            }
            float f = pc.Finish();
            MessageBox.Show("Прошло " + f.ToString());
            MessageBox.Show(d.ToString());

То компилятору деваться некуда и получаем.

Код: [Выделить]

            {
              d = Math.Sin(i);
00000051  mov         dword ptr [esp+2Ch],ebx 
00000055  fild        dword ptr [esp+2Ch] 
00000059  fsin             
0000005b  fstp        qword ptr [esp+20h] 
0000005f  fld         qword ptr [esp+20h] 
00000063  fstp        qword ptr [esp+10h] 
            for (int i = 0; i < 1000000; i++)
00000067  inc         ebx  
00000068  cmp         ebx,0F4240h 
0000006e  jl          00000051 
            }

Всетаки вызывает fsin
И время исполнения становиться равным 0,06334017 сек.
Отсюда 114,6457077 тактов на 1 вычисление синуса в цикле. Всетаки получше 270 и 340....

Din

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:24:22

Итак, время исполнения 0,001690997 сек.

Думаю вы заметили что время меняется и порой значительно...

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:24:22

Умножаем на 1810000000(тактовая частота процессора).

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

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:24:22

2 компиляция(может проходить при инсталяции программы) - компиляция в комманды процессора ситемы. И если есть у меня sse2, то и будет использована она.

Если бы компилятор без спросу использовал инструкции sse2 (у вас есть их поддержка), то на младших моделях процессоров ваша программа перестала бы работать. Как вы думаете должен компилятор принимать подобные решения?

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:53:37

Хм... Всетаки я малось лопухнулся!
Если объявлять так
Код: [Выделить]
for (int i = 0; i < 1000000; i++) { double d = Math.Sin(i); }То компилятор видит, что d больше нигде не используется генерит вот такие машинные инструкции.

У меня нормально сработал этот вариант. Значения приблизительно равны с MessageBox.Show(d.ToString()); и без него.

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:53:37

Код: [Выделить]
{ d = Math.Sin(i); 00000051 mov dword ptr [esp+2Ch],ebx 00000055 fild dword ptr [esp+2Ch] 00000059 fsin 0000005b fstp qword ptr [esp+20h] 0000005f fld qword ptr [esp+20h] 00000063 fstp qword ptr [esp+10h] for (int i = 0; i < 1000000; i++) 00000067 inc ebx 00000068 cmp ebx,0F4240h 0000006e jl 00000051 }

Этого достаточно для вычисления синуса:
004011B2 FILD DWORD PTR DS:[409060] ; загрузили целое число в стек
004011B8 FSIN ;вычислили
004011BA FSTP DWORD PTR DS:[409064] ; извлекли результат из стека

Цитата: Сомневающийся_В_Unix от 28 Сентябрь 2006, 19:53:37

Всетаки вызывает fsin
И время исполнения становиться равным 0,06334017 сек.
Отсюда 114,6457077 тактов на 1 вычисление синуса в цикле. Всетаки получше 270 и 340....

Скорость стоит сопоставлять лишь когда методика измерений одинакова. Время исполнения с вашим кодом у меня приблизительно то же.

На выходных доделаю тестовый код на асме. Проверим по моей методике?

Minoru

хм... Не думал что сообщение Watson'a про Гуру приведёт к такому.

Сомневающийся_В_Unix

Цитата: Din от 29 Сентябрь 2006, 11:06:44

Думаю вы заметили что время меняется и порой значительно...

Естественно меняется.

Цитата: Din от 29 Сентябрь 2006, 11:06:44

Если бы компилятор без спросу использовал инструкции sse2 (у вас есть их поддержка), то на младших моделях процессоров ваша программа перестала бы работать. Как вы думаете должен компилятор принимать подобные решения?

Судя по http://www.dont.ru/AMD-Athlon-64-3000+-Box.id1494.html есть.
Что значит без просу? Программа исполняется на моей машине и с моим процессором. JIT компилятор определит какой у меня проц и сгенерирует инструкции именно для него, на другой машине будут ее инструкции. Мы всегда имеем компилятор на машине, где установлен .NET.

Din

Цитата: Minoru от 29 Сентябрь 2006, 15:31:25

хм... Не думал что сообщение Watson'a про Гуру приведёт к такому.

Мда уж... и тут Остапа понесло как говорится

Цитата: Сомневающийся_В_Unix от 29 Сентябрь 2006, 15:50:50

Судя по http://www.dont.ru/AMD-Athlon-64-3000+-Box.id1494.html есть.
Что значит без просу? Программа исполняется на моей машине и с моим процессором. JIT компилятор определит какой у меня проц и сгенерирует инструкции именно для него, на другой машине будут ее инструкции. Мы всегда имеем компилятор на машине, где установлен .NET.

А на динамику ваших языков я и не обратил внимания... Но код-то здесь (вызов fsin) все-равно одинаков. А его оптимальность я думаю вы уже оценили. Байткод несколько ограничивает возможности оптимизации хотя бы потому что должен быть преобразован к нативному на лету, то есть имеет ограничения по времени компиляции. Компилятор С/С++ будет давать код не хуже в любом случае, а зачастую лучше. Давайте "плюсы" и будем рассматривать в качестве эталона.

user_anonymous

Цитата: Сомневающийся_В_Unix от 27 Сентябрь 2006, 21:15:16

И побочный эффект эксперимента, скорость выполнения программ, написанных на C# вообще больше скорости выполнения программ написанных на ASM.
Если конечно участок кода требует интенсивных вычислений. Программа на C# пройдет через 2 оптимизирующих компилятора, последний из которых сгенерирует минимальное количество самых быстрых машинных инструкций для того процессора, на котором исполняется!

Вот это ЛОЛ ;D
Ни один компилятор, не обладающий искусственным интеллектом НИКОГДА НЕ СМОЖЕТ сгенерировать лучшую программу, чем может написать человек.

Новости:

Автор Тема: Сложенщики, умноженцы и такты (Прочитано 14458 раз)

Watson

Din

Din

Watson

Din

Din

Din

Din

Din