| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Флейм > asm vs C/C++ |
| Автор: oleg1973 29.7.2004, 12:47 |
| и так AndyY предложил устроить компитейщн "написание алгоритма сортировки" и выяснить наконецто давно всех мучающий вопрос "а будет ли на асме оно быстрее работать?" Андрей я принимаю предложение что и как будем сортировать? чем будем подсчитывать циклы? (вопрос важный, разные утили по разному себя ведут) как вы наверно догадалисть я буду писать на асме, а AndyY на с/с++ ну если еше желающие будут, велком как говорится |
| Автор: _Chingachguk_ 29.7.2004, 13:20 |
| А где можно прочесть про условия Вашего спора ? PS AndyY может просто позвать библиотечную QuickSort |
| Автор: oleg1973 29.7.2004, 13:23 |
| _Chingachguk_ да условий никаких особых а все началось тут http://forum.vingrad.ru/index.php?showtopic=26291&st=45&unread=#entry191272 |
| Автор: Sardar 29.7.2004, 13:28 |
| Сортировка это просто... Лучше пусть каждый сделает контейнер/множество принимающий строки и выдающий их в специальном отсортированном виде. Что бы было понятно, SQL запрос: select distinct * from.... order by поле,поле,поле; И того в контейнер будут поступать структуры: {int, строка, строка, строка}, а выдавать контейнер будет множество этих структур, отсортированных по полям заданным в аргументах. Приниматся будут 10.000 структур, из которых 500 уникальных. В задаче присутствует как сортировка и поиск, так и возможность хорошенько подумать над задачей |
| Автор: AntonSaburov 29.7.2004, 13:50 |
| А давайте. Сортировка предлагается следующая: Сортировка методом "Быстрая сортировка" строки длиной по 50 символов. На вход функции подается указатель на массив из строк. А мы посмотрим |
| Автор: chipset 29.7.2004, 14:03 |
| Тогда уж заодно и на шарпе Вот будет весело если он победит |
| Автор: oleg1973 29.7.2004, 14:08 | ||
согласен призы какие? чем скорость замерять будем? |
| Автор: AntonSaburov 29.7.2004, 14:15 | ||
Запускаем функцию и меряем время до и после. Массив можно большой - миллион строк, чтобы было что замерить. В принципе компутер не важен - можно получить относительные величины. |
| Автор: oleg1973 29.7.2004, 14:25 | ||
и на это время вырубим вындос? и все приложения? rdtsc оно не только тики одного процесса будет считать тогда уж грузится с дискетки в реал моде досе вырубать прерывания и тестить |
| Автор: Guest 29.7.2004, 14:45 | ||
Да ну, одна задача с достаточно большим числом аргументов и время будет более-менее ok. Я тут недавно изучал стойкость md5 и сортировал по ~2^25 строк ;) |
| Автор: _Chingachguk_ 29.7.2004, 14:46 |
| Черт, подписаться забыл ;) PS АСМ победит. |
| Автор: AndyY 29.7.2004, 14:55 |
| oleg1973 Предупреждать же надо. Еле топик нашел. Вот и значения для сортировки. Читать будем из файла values.dat (в зипе http://awin-lib.narod.ru/values.zip). Если 10000 мало для теста производительности, нагенерю еще. Сравнивать будем разницу тиков проца до и после сортировки. Проверим скажем на intel и amd, хотя думаю что разница будет незначительно. Добавлено @ 15:02 во наспамили поскольку речь идет о программировании под винду, считаю всякие дос моды излишеством. Пускаться должно как отдельный win32 процесс, комп особо ничем занят быть не должен. Считаем только тики сортировки, время чтения файла - пофигу. Повторюсь - я утверждаю, что у асма не будет особых преимуществ по быстродействию в сравнении с release оптимизированным по скорости msvc. Добавлено @ 15:04 AntonSaburov Я вообще-то сгенерил файло для сортировки чисел, но пофигу - можно и строки сортировать. Возможно Олегу даже проще будет - не надо atoi писать |
| Автор: GrayCardinal 29.7.2004, 15:26 |
| 10000 маловато будет. в линухе sort выдает 0.12 секунд (загрузка проца 61%) на атлоне не хилом. разрешите поучаствовать ? представителем Си под Линукс ? |
| Автор: maxim1000 29.7.2004, 15:43 | ||
насколько я понял, никто и не спорит, что ассемблер будет быстрее говорят, что он будет ненамного быстрее... здесь как-то очень быстро, без всякого анализа был сделан выбор алгоритма, а, между прочим, от этого все и зависит одно дело - алгоритм с кучей организационных инструкций, всякие там if, while и т.д., и т.п. совсем другое - серьезный вычислительный алгоритм с кучей умножений, сложений ... последние алгоритмы, обычно, очень хорошо ложатся на ассемблер при чем, при увеличении сложности алгоритма эффективность кода, сгенерированного компилятором C++, по сравнению с написанным вручную (только грамотно, конечно) будет падать P.S. было бы интересно так же узнать время написания ПО |
| Автор: oleg1973 29.7.2004, 16:03 | ||
| 10000 мало давай ченить окола 100000 и числа посерезней типа
Добавлено @ 16:05 кому файло? 100000 элементов 430 кб в архиве |
| Автор: RA 29.7.2004, 16:15 |
| Господа, а почему сортировка? Может лутче на поиск слова в файлах по маске *.* ? |
| Автор: Girder 29.7.2004, 16:22 |
| maxim1000 ты прав - задача явно не та. Лудше бы определитель матрицы, размерность так 9х9, посчитали через рекурсию. При этом размерность каждой ячейки: Word, а ответ рекурсивной функции DWord(или там PWord, QWord, TByte). - лудше конечно PWord(6 байт) или TByte(10 байт). Разница в размерности выбранно специально. Вот тогда и проявится: насколько грамотно работает компилятор. |
| Автор: Monty 29.7.2004, 16:39 | ||
Это уже от диска будет зависить |
| Автор: Sardar 29.7.2004, 18:12 |
| Загрузка с дискетки и прочие инкубаторские условия не допустимы, ИМXО. Если сортировать, то не числа, а строки по алфавиту в любом направлении. Нет ничего хуже супер результатов надуманных задач, ИМXО. |
| Автор: RA 29.7.2004, 18:50 | ||||
Ну дык протестим всё это на твоём диске |
| Автор: Fantasist 29.7.2004, 20:19 |
| От компилятора тоже будет зависить. Где-то на RSDN видел статью - там компилятор от Intel при работе с float значениями уделал всех остальных в десятки раз. |
| Автор: -=::BlackCat::=- 29.7.2004, 20:23 |
| Могу предоставить своиь комп для тестирования.... самому очень интересна скорость, мой комп описан здесь. http://forum.vingrad.ru/index.php?showtopic=21448&view=findpost&p=145831 |
| Автор: Monty 29.7.2004, 21:17 | ||||||
Радмин, ты не понял |
| Автор: Дрон 30.7.2004, 01:41 | ||
| Может вам будет интересно, но помнится я сам проводил подобное сравнение. Взял алгоритм возведения чисел в целую степень и давай баловаться. Простая (сделанная прямо по алгоритму) реализация на Си проигрывала в ВОСЕМЬ раз такой же на ассемблере. Потом я подумал-подумал и по-всякому ухитряясь переписал на Си так, что получилось всего лишь в 1,3 (примерно, сейчас я уже не помню) раза медленнее ассемблера. Может, конечно, можно ещё где-то улучшить. Процедуру на асме можете глянуть тут: http://forum.vingrad.ru/index.php?showtopic=21898 А на Си вот тут:
|
| Автор: oleg1973 30.7.2004, 02:18 | ||
тоже идея ну так и будем все трепатся или выдумаем задание? я предлогаю массив на 100000 элементов разделенных там чемнить , запятой к примеру элементы разной размерности (byte word dword ) задача сортануть по возрастащей к примеру алгоритм кому какой больше по душе, язык програмирвания тоже нужно сделать dll с одной единственной функ которой передастся адрес массива и его размер длл должна сделать сортировку и вернуть адрес на отсортированый массив который основная прога в файл сохранит при данном размере массива можно будет секундомером засикать я такой массив в ворд засунул, замену символа задал на П4-2000 +512 рам достаточно долго работал |
| Автор: Дрон 30.7.2004, 02:21 |
| Лучше всего засекать время по GetProcessTimes() |
| Автор: maxim1000 30.7.2004, 10:52 | ||
если хотите сравнивать мастерство программиста - пожалуйста если хотите сравнивать возможности языков - алгоритм должен быть одинаковым |
| Автор: AndyY 30.7.2004, 16:21 | ||
| maxim1000 Сравниваем возможности программиста, естественно. При использовании различных языков программирования. Кто какой алгоритм знает - тот такой и реализует. oleg1973 сегодня напишу если ничего срочного не будет. в dll - ок. Я так и не понял, строки сортируем или числа "разной размерности". Файл в формате - числа, разделенные '\n'. итак, точка входа - такая:
сорцы, естественно сюда - чтобы все могли покомпилять. Sardar Girder и другие: Мы писать будем сортировку. Если есть желание сравнивать что-нибудь другое - никаких проблем, пишите, сравнивайте. |
| Автор: Girder 30.7.2004, 20:53 |
| AndyY извени, не хотел обидеть. Просто алгоритм, точно не тот. Возможно(но не на все 100%) ты проиграеш. При этом программисту на асм-е, гораздо больше ошибок можно допустить(в реализации), чем тебе. Но комилятор, не так глуп(как многию думают), я сам много раз учился на откампилированной программе. По этому и предложил другой вариант, где малейшия ошибка при написании программы на асм-е приведет к проигрышу oleg1973. Но честно признаюсь, при правельном подходе, компилятор(любой) всегда проиграет. Удачи Вам обоим(AndyY и oleg1973). |
| Автор: p0s0l 30.7.2004, 21:44 |
| Если разные алгоритмы - то это абсурд... Если дальше развить такую идею, то может тогда уж лучше будет, если Олег будет сортировать строки, а AndyY умножать матрицы ? Просто может получится так, что Олег сделает пузырьковый метод, а AndyY какой-нибудь супер-пупер быстрый алгоритм. И в итоге получится, что асм - медленнее... Или почему бы не сравнить задачи, где можно юзать MMX или SSE ? Как там себя будет чувствовать ЯВУ ?... PS: IMHO, лучше засекать время через QueryPerformanceCounter... |
| Автор: Sardar 30.7.2004, 22:12 |
| AndyY тоже не хотел обидеть, просто большая сила С++ проявится в работе с большими/сложными структурами, куча в памяти(звязанные списки и т.п.) и сложная логика/отношения. В простой сортировке 32битных чисел Олег тебя уделает... |
| Автор: oleg1973 31.7.2004, 13:36 | ||||
| AndyY ты файл выложи для сортировки
есть массив "5,45687,-25,589,6,45369712698," ну и надо по возрастающей числа расставить
придумал я тут на досуге алгоритм использует особенности hex представления числа, p.s. ну так че "быструю сортировку" пишем ? |
| Автор: AndyY 3.8.2004, 01:24 |
| итак, я написал. скажем так - это текст практически неоптимизированный вручную, раскрыл только очевидные вещи. все остальное ложиться на компилер. встречайте и тестите: http://awin.spb.ru/downloads/sortlib.zip - бинарник http://awin.spb.ru/downloads/sortsrc.zip - сорец. сама сортировка, как договаривались, в .dll. о командной строке: sorttest.exe /random <необязательное число> - нагенерячить выборку, по умолчанию 500000 значений. выборка - белый шум. sorttest.exe /normal <необязательное число> - аналогично, но приближена к нормальному распределению. жду ответа от олега. PS сортировка поддерживает отрицательные числа, но не генерячит их. Ибо лень. |
| Автор: AndyY 3.8.2004, 14:53 |
| так что у народа с написанием? даже жаль что такой топик завял. генерите выборки, читайте файлы - и вперед. |
| Автор: -=::BlackCat::=- 3.8.2004, 15:26 |
| AndyY wi tut pisali chto eto dolvolnataki gestokie nagruzki na komp budut, nu ja predlogil swoi dlja experementow, no poka chto ne prog ne faila sortirowki ne widno. PS: andy wigu silki na twoju progu.... gdems progu ot olega plus, dawaite libo eshe genirotor dopishite libo failik daite, ne w rcuhnuju ge nam eto delo nabiwat =) |
| Автор: Дрон 3.8.2004, 16:55 |
| [Offtop] -=::BlackCat::=- Включи транслит!!!!!!!! А то вообще не понять о чём ты говоришь [/Offtop] Спасибо за внимание. |
| Автор: -=::BlackCat::=- 3.8.2004, 17:03 |
| Дрон ego u menja netu |
| Автор: Girder 5.8.2004, 13:02 |
| Топик тонет, Мож с нами со всеми поделитесь результатами, а? |
| Автор: oleg1973 6.8.2004, 12:42 |
| а вот и я, пардон за задержку дела были кароче прога AndyY делает все за 80 мс (у меня п4-2000 512 рам XP) мой вариант делает за 10 мс (тоже без оптимизации вывод как говорится на лицо для теста вам понадбится values.dat из набора AndyY саму прогу брать тут http://digilander.libero.it/oleg1973/main.rar |
| Автор: AndyY 6.8.2004, 12:57 |
| Забавно. 1. нагенерил значения: sorttest.exe /random 10000000 - получилось в районе 60 мегов 2. запускаю сортировку oleg1973 3. она сортирует 0 (!) ms и записывает файл файл 3 мега мой вариант сортирует примерно секунду (размер, естественно, совпадает). так что там с поддержкой? кстати, не понимаю, почему dll экспортит кривую точку входа - моя прога ее не кушает, а разрешению GetLocalTime я не доверяю, как и GetTickCount() |
| Автор: oleg1973 6.8.2004, 13:07 | ||||
AndyY
так как я тестил с values.dat 500000 значений оно с ними и работает а меньше 10 мс не отследиш
твоя прога все кушает но не пишет результаты моей длл в файл а вылитает видимо при компиляции и оптимизации прэкта ты чета намутил там и возврат данных в твоей длл происходит не через EAX как положено по конвенции моя же длл возвращает указатель на отсортированый массив именно через EAX з.ы. проверил с 10000000 260 мс |
| Автор: Girder 6.8.2004, 13:25 |
| Да... как я и ожидал. Не та задачка для сравнения. Мож еще какую задачку замутите, для сравнения |
| Автор: oleg1973 6.8.2004, 13:30 |
| Girder это бесполезно если взять асм листинг проги AndyY то увидим конструкции типа mov ecx, DWORD PTR [eax+edx*4] и cmp eax, DWORD PTR _threshold$[ebp] а это есть тормоза Добавлено @ 13:34 для тех кто хочет померятся письками предлогаю реальный конкурс, где проявится не только умение компилятора но и програмера будем писать упаковщик данных, картинку у примеру возмем 1024х768х24 bit ну и будем ее паковать желательно переплюнуть Rar по размерам выходного файла и по времени |
| Автор: Girder 6.8.2004, 13:54 |
| Да это понятно. Согласен на все 100%, что код написанный(так скажем правильно) на асме всегда объиграет компилятор. Но есть задачи. которые в откомпилированнов виде(всмысле только оснавная функция),несмотря на чуть больший размер по сравнению с кодом написанном полностью на асме, может быть более производителен, если конечно человек пишуший на асме не обратит внимание на некоторые нюансы. Ну типо что проц тратит дополнительное время на переход от выполнения 32битной инструкции к примеру к 16 битной ну и наоборот. При этом в компиляторе это как правило учтено. Чуть больше переходов при реализации на асме, а компилятор, сам понимаеш старается их минимизировать. Ну даже в этом разница Call $4f1243 или Call edi. Ну и т.д. Я надеюсь что ты понял меня oleg1973 |
| Автор: oleg1973 6.8.2004, 13:59 |
| Girder не нада смешивать 32 и 16 бит и все будет ок |
| Автор: Girder 6.8.2004, 14:07 |
| Ясно дело!. Это я так для примера. Иногда по быстроте напишеш смешанный код, ну а потом его приходится оптимизировать. Вот я и надеялся что по спешки ты можеш ошибится. И увидеш что плохой(не подумай что это я на твой счет) програмист пишуший на асме реализует хуже задачу, чем программист пишуший на языке высокого уровня |
| Автор: GrayCardinal 6.8.2004, 14:12 |
| от нечего делать замутил прогу сорта этих чисел... на си под Линукс и простую, пузырьковую... получилосьв районе 110мс (500 тыщ значений). Атлон 1.8 |
| Автор: oleg1973 6.8.2004, 14:19 |
| я не смотрел особо исходник Анди но факт в том что его sorttest.ехе передает а качастве параметра указатель на массив 16 битных значений, я естестно их в 32 перевожу, как у него сортировка идет я не знаю, тормоза еше и изза этого точно есть |
| Автор: AndyY 6.8.2004, 14:23 |
| oleg1973 не понял такого: qsort: mov esi,[adr] mov ecx,500000 не удивительно что сортируется не то что надо к вопросу о поддержке асм программ |
| Автор: Girder 6.8.2004, 14:24 |
| oleg1973 понял. AndyY проверь настройки компилятора и код. |
| Автор: oleg1973 6.8.2004, 14:27 |
| AndyY яж те сказал на 500000 сделана либа лень было хотя могу и пофиксить но это как то мало к делу относится |
| Автор: AndyY 6.8.2004, 14:27 |
| кстати если поставить первое число -100 - тоже gpf |
| Автор: oleg1973 6.8.2004, 14:31 |
| AndyY и че ты хочеш от проги за 30 мин написаной? ты лучше не баги у меня ищи а алгоритм свой шливуй и оптимизируй |
| Автор: AndyY 6.8.2004, 14:32 |
| Girder не понял что мне проверять. я написал работающую прогу. олег - нет (ему было лень) о чем дальше может идти разговор? сравнивать нечего. |
| Автор: Girder 6.8.2004, 14:33 | ||
|
| Автор: GrayCardinal 6.8.2004, 14:40 |
| Упс... Ошибочка вышла... Не сортила у меня ничерта (забыл проверить [quote]будем писать упаковщик данных, картинку у примеру возмем 1024х768х24 bit ну и будем ее паковать[quote] формат картинок ? простой pixmap по три байта на пиксель или по четыре (навроде BMP-шки где лишний ноль) ? Кто картинок нагенерит ? |
| Автор: Girder 6.8.2004, 14:44 |
| GrayCardinal выбирай http://wallpapers.bynet.ru/index.shtml |
| Автор: GrayCardinal 6.8.2004, 14:55 |
| Так что - пишем архиватор BMPшки типа 1024*768*24 с оптимизацией по скорости ? Ограничением на вирт. память 256 мб |
| Автор: oleg1973 6.8.2004, 15:47 |
| Анди ты можеш говорить все что тебе угодно факты вот ради интереса протестил на п2-350 384 рам вын98 500000 элементов ![]() Добавлено @ 15:48 GrayCardinal давай 1024*768*24 бита (RGB) и по скорости и по размеру выходного файла создай тока топик новый |
| Автор: AndyY 6.8.2004, 16:14 |
| oleg1973 написать программу которая выводит сообщение sort time 110ms - конечно, несложно. Сложность в том, чтобы программа при этом еще и работала. На этом обсуждать тему лично с вами мне стало неинтересно. all Хотелось бы увидеть работающую реализацию сортировки. Может, кто справится на асме? Или на C#? |
| Автор: oleg1973 6.8.2004, 16:25 |
| AndyY а что исходники которые прилагаются слабо компильнуть? или нехватает чегото? а наезжать без понтово мы все умеем |
| Автор: oleg1973 6.8.2004, 17:22 | ||||
| и так специально для тех кто не имеет fasm берем тут архив http://digilander.libero.it/oleg1973/main.zip в архиве 2 исходника и файл fasm.zip, распаковываем на диск С открываем исходник жмем F9 получаем откомпилированый файл если будете распаковывать компилер в папку отличную от C:\fasm поправте в файле fasm.ini строку [Environment] Fasminc=C:\fasm\include указав в ней путь к папке с инклудами так как Анди есть фома неверущий в исходнике sort.asm обавлена строка
которая ждет пока в структуре stime элемент wMilliseconds не будет равен 0 после этого запускает процедуру сортировки после возврата из проц делается снова
и сравниваются 2 значения wMilliseconds разница между ними есть примерное время выполнения проц сортировки Анди , поражения надо признавать с гордостью, а не пытатся чета там доказать |
| Автор: Chingachguk 6.8.2004, 17:59 |
| AndyY Я полагаю, Вы неправы в выборе таких методов спора. Если это что-то значит, то я могу сказать из опыта своего общения с oleg1973 следующие слова: он вряд ли способен на жалкий фальшивый мессджбокс. |
| Автор: -=::BlackCat::=- 6.8.2004, 21:18 |
| ochen ohota wmeste s wami potestit eto delo, tolko vot gde mne value.dat wzjat ja ne ponjal =( |
| Автор: AndyY 8.8.2004, 19:46 |
| Chingachguk Я утверждаю, что разрешение GetLocalTime не хватает для измерения интервалов времени порядка десятка мс. All Кроме того, сортировка Олега не работает с отрицательными значениями и выдает неверный результат для количества элементов != 500000. Если второе сделано по невнимательности, то первое - сильное упрощение задачи. Как иллюстрацию приведу "супербыструю" сортировку для чисел в интервале 0-65535. Качайте http://awin.spb.ru/downloads/sorttest.zip и http://awin.spb.ru/downloads/sortlib.zip. Обгоняет реализацию для dword в 10 раз |
| Автор: oleg1973 9.8.2004, 01:22 | ||||
AndyY
меньше 10 мс не отследиш, а 10 и более запросто ну а если хочеш дальше мерятся письками, давай писать под realmode там можно с точностью до такта посчитать
ну не нада отмазки искать всем кроме тебя было изначально ясен результат то что у меня стоит 500000 фиксирвано на скорость АЛГОРИТМА не влияет сделать вариант для отр. чисел - 5 мин работы по любому спор был о СКОРОСТИ АЛГОРИТМА РЕАЛИЗОВАНОГО НА РАЗНЫХ ЯЗЫКАХ а не о удобстве и наворотах программы кстати твои файлы не качаются |
| Автор: AndyY 9.8.2004, 09:02 |
| правильные линки: http://awin.spb.ru/downloads/sortlib.zip http://awin.spb.ru/downloads/sortsrc.zip oleg1973 по поводу измерения времени - бред полный. разрешение подобных функций порядка 10-15 мс и есть, так что мерить этим можно где-то от 100-200 мс (с погрешностью 10% поддержку сортировки нормальных DWORD таким методом не сделать никак - памяти не хватит, не надо разводить флейм про "5 минут". 500000 зашитое на скорость конечно не влияет, но не дает проверить вашу реализацию на большой выборке, а в совокупности с разрешением таймера - не дает сравнить быстродействие. |
| Автор: oleg1973 9.8.2004, 11:14 | ||||||
твоя прога и моим и твоим способом 80 мс показываеь такчто не будем лохматить бабушку
|
| Автор: AndyY 9.8.2004, 11:46 |
| Олег, я совершенно не понимаю личных наездов в обсуждении в общем-то небезинтересной темы. Я предложил считать время тиками - неужели на асме сложно это реализовать? -0xffffffff - это ненормальный DWORD, для справки. Нормальные DWORD я и сортировал в первой версии, а вы - WORD (хотя и предлагали обратное). Тем способом, который реализовали вы - сортировать массив DWORD невозможно. Хорошо, забьем, я тоже реализовал сортировку WORD, она естественно на порядок быстрее. Жду результатов сравнения - у меня нет медленной машины и возможности скормить вашей программе большую выборку для теста. |
| Автор: oleg1973 9.8.2004, 16:58 | ||||
AndyY
интересно а чтоже это?
ошибаетесь уважаемый AndyY разговор заходит в тупик если ты хочеш продолжить, велком сюда http://forum.vingrad.ru/index.php?showtopic=27525&st=0 тут и скорость и извилины нужны |
| Автор: AndyY 9.8.2004, 23:41 |
| oleg1973 нормальный dword - от 0 до 0xffffffff, или один разряд отдается на знак. про использования алгоритма - покажите, как вы будете размещать массив размером 4 гига, или не выдавайте голословных утверждений. разговор закончится, когда вы сделаете нормальное измерение времени в вашей программе, либо увеличите объем выборки в десяток раз, либо запостите сюда результат сравнения быстродействия наших программ на медленном компе. кстати, у меня есть подозрение что с++ реализация обгоняет вашу "сделанную за полчаса". У меня быстродействие для word поднялось в 10 раз, а вы говорили всего о 8кратном преимуществе. к сожалению проверить вашу программу на своем компе я не могу. |
| Автор: oleg1973 10.8.2004, 14:41 |
| AndyY хорошо шас напишем и вовсе не нада 4гб на массив а dword это 4 байта по любому и CPU на знак как то наплевать, несуществует для него отр. значений ну а насчет измерения времени ты не прав,меряется одинаково как твоим так и моим способом |
| Автор: -=::BlackCat::=- 10.8.2004, 15:19 |
| AndyY u tebja tam w proge mona uwelichit kolichestwo geniracii? da eshe gelatelno chtonibud po slognee, a ne to doli sekundi ne interesno, nado bi chto nibud chto na 10-15 sekund, da i chtob proc pri etom polnostju naprjagli |
| Автор: AndyY 10.8.2004, 15:28 | ||||||
| oleg1973 дык нет ничего легче запостить текущие результаты - алгоритм у нас сейчас один и тот-же. вот и сравним в чистом виде скорости с++ и асм. и положим конец флейму о ручной оптимизации. Измерение времени: вот такой код
Угадаем, что будет в output? Думаете разница в 1mc? неправильно:
на моем компе моя сортировка выполняется 4 мс, ваша пишет что 0 (читай, меньше 15). нет ведь ничего проще использовать это:
и получим результат, на 99% близкий к истине (утилизация проца в районе 99%) Добавлено @ 15:31 -=::BlackCat::=- можно конечно. только функция олега ест only 500000 значений и не значением больше. у меня ест все. пробовать так: sorttest /random 1000000 Добавлено @ 15:33 -=::BlackCat::=- можно конечно. только функция олега ест only 500000 значений и не значением больше. у меня ест все. пробовать так: sorttest /random 1000000 |