AndyY тоже не хотел обидеть, просто большая сила С++ проявится в работе с большими/сложными структурами, куча в памяти(звязанные списки и т.п.) и сложная логика/отношения. В простой сортировке 32битных чисел Олег тебя уделает...

AndyY
ты файл выложи для сортировки

Цитата

Я так и не понял, строки сортируем или числа "разной размерности"

есть массив "5,45687,-25,589,6,45369712698,"
ну и надо по возрастающей числа расставить

Цитата

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

придумал я тут на досуге алгоритм
использует особенности hex представления числа, оригинальность и секорость гарантированы

p.s.
ну так че "быструю сортировку" пишем ?

Это сообщение отредактировал(а) oleg1973 - 31.7.2004, 13:51

итак, я написал. скажем так - это текст практически неоптимизированный вручную, раскрыл только очевидные вещи. все остальное ложиться на компилер.

встречайте и тестите:
sortlib.zip - бинарник
sortsrc.zip - сорец.

сама сортировка, как договаривались, в .dll.

о командной строке:
sorttest.exe /random <необязательное число> - нагенерячить выборку, по умолчанию 500000 значений. выборка - белый шум.
sorttest.exe /normal <необязательное число> - аналогично, но приближена к нормальному распределению.

жду ответа от олега.

PS сортировка поддерживает отрицательные числа, но не генерячит их. Ибо лень.

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

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 =)

[Offtop]
-=::BlackCat::=-
Включи транслит!!!!!!!!
А то вообще не понять о чём ты говоришь
[/Offtop]
Спасибо за внимание.

Дрон
ego u menja netu admin wirezal, k nemu pritenzii

Топик тонет, Мож с нами со всеми поделитесь результатами, а?

Это сообщение отредактировал(а) Girder - 5.8.2004, 13:02

а вот и я, пардон за задержку дела были
кароче прога AndyY делает все за 80 мс (у меня п4-2000 512 рам XP)
мой вариант делает за 10 мс (тоже без оптимизации )
вывод как говорится на лицо
для теста вам понадбится values.dat из набора AndyY

саму прогу брать тут
файл

Забавно.

1. нагенерил значения:
sorttest.exe /random 10000000 - получилось в районе 60 мегов
2. запускаю сортировку oleg1973
3. она сортирует 0 (!) ms и записывает файл файл 3 мега)))

мой вариант сортирует примерно секунду (размер, естественно, совпадает).

так что там с поддержкой?

кстати, не понимаю, почему dll экспортит кривую точку входа - моя прога ее не кушает, а разрешению GetLocalTime я не доверяю, как и GetTickCount()

AndyY

Цитата

1. нагенерил значения: sorttest.exe /random 10000000 - получилось в районе 60 мегов 2. запускаю сортировку oleg1973 3. она сортирует 0 (!) ms и записывает файл файл 3 мега)))

так как я тестил с values.dat 500000 значений оно с ними и работает
а меньше 10 мс не отследиш

Цитата

кстати, не понимаю, почему dll экспортит кривую точку входа - моя прога ее не кушает, а разрешению GetLocalTime я не доверяю, как и GetTickCount()

твоя прога все кушает
но не пишет результаты моей длл в файл а вылитает
видимо при компиляции и оптимизации прэкта ты чета намутил там и возврат данных в твоей длл происходит не через EAX как положено по конвенции
моя же длл возвращает указатель на отсортированый массив именно через EAX


з.ы.
проверил с 10000000
260 мс

Это сообщение отредактировал(а) oleg1973 - 6.8.2004, 13:21

Да... как я и ожидал. Не та задачка для сравнения.

Мож еще какую задачку замутите, для сравнения

Girder
это бесполезно
если взять асм листинг проги AndyY
то увидим конструкции типа
mov ecx, DWORD PTR [eax+edx*4]
и
cmp eax, DWORD PTR _threshold$[ebp]

а это есть тормоза
Добавлено @ 13:34
для тех кто хочет померятся письками
предлогаю реальный конкурс, где проявится не только умение компилятора но и програмера
будем писать упаковщик данных, картинку у примеру возмем 1024х768х24 bit
ну и будем ее паковать
желательно переплюнуть Rar по размерам выходного файла и по времени

Да это понятно.

Согласен на все 100%, что код написанный(так скажем правильно) на асме всегда объиграет компилятор.

Но есть задачи. которые в откомпилированнов виде(всмысле только оснавная функция),несмотря на чуть больший размер по сравнению с кодом написанном полностью на асме, может быть более производителен, если конечно человек пишуший на асме не обратит внимание на некоторые нюансы. Ну типо что проц тратит дополнительное время на переход от выполнения 32битной инструкции к примеру к 16 битной ну и наоборот. При этом в компиляторе это как правило учтено. Чуть больше переходов при реализации на асме, а компилятор, сам понимаеш старается их минимизировать. Ну даже в этом разница Call $4f1243 или Call edi. Ну и т.д.

Я надеюсь что ты понял меня oleg1973

Girder
не нада смешивать 32 и 16 бит и все будет ок