Permalänk

Snabbast på sortering?

Man hittar ibland uppgiften på nätet att mergesort och radixsort skulle vara snabbare än quicksort.
Men jag har alltid mätt att quicksort är snabbast. Någon som har sett något annat?

Permalänk
Medlem

Det underlättar om du nämner vilket språk det gäller.

Visa signatur

www.fckdrm.com - DRM år 2024? Ha pyttsan.

Permalänk
Medlem

Frågar du rent allmänt - snabbast sökning? Finns inget svar. Quick sort är generellt bra, men finns bättre sökalgoritmer under specifika förhållanden.

Permalänk
Medlem

Quicksort är snabb, ja. Men i värsta fall, otur eller riggat, så kan den bli O(n^2).

Mergesort är alltid O(n*Log(n)).

Mergesort brukar dock mer minne då den skriver till nya arrayer medan quicksort kan göras på befintlig samling.

Visa signatur

i5-7600k . GTX 1080 . 16 GB

Permalänk
Medlem
Skrivet av Greyguy1948:

Man hittar ibland uppgiften på nätet att mergesort och radixsort skulle vara snabbare än quicksort.
Men jag har alltid mätt att quicksort är snabbast. Någon som har sett något annat?

Vilken som är snabbast för ett specifikt fall beror ju väldigt mycket på exakt hur respektive algortim är implementerad, och för många sorteringsalgoritmer så beror körtiden även på hur indata ser ut.
Vad som är snabbast för att sortera en liten lista på bara ett par hundra tal behöver inte vara snabbast för att sortera en array av ett par hundra miljarder tal. Och vice versa.

Quicksort är t.ex. i genomsnitt en ganska effektiv sorteringsalgoritm, men för vissa indata så kan den degenerera till att behöva O(n^2) jämförelser istället för det genomsnittliga O(n*log n), och då är den inte alls snabb.

Mergesort har många trevliga egenskaper, men kräver temporärt minne som buffert, och finns det inte tillräckligt med RAM så att datorn behöver swappa ´till disk, så blir det plötsligt en väldigt långsam sortering.

Det finns ingen sorteringsalgoritm som alltid är snabbast, utan de bra sorteringsalgoritmerna har alla olika egenskaper och fungerar olika bra i olika situationer.

Permalänk
Medlem

Den här sidan är rätt bra med förklaringar och animationer hur de flesta vanliga algoritmerna fungerar och deras för och nackdelar: https://www.toptal.com/developers/sorting-algorithms

Visa signatur

Data: B650 + 7800X3D + 4080 Super + 64GB (2x32) + 2TB T700 + 850W
Ljud: Cambridge Audio DacMagic + SPL Phonitor 2 + AKG K812
Bild: MSI MAG 274UPF (27" 4K)

Permalänk
Medlem
Permalänk

Bristen på RAM är nog inget stort problem idag men bristen på cache. Raspberry Pi 4 där jag har det mesta av mina data har L2=1MB. Detta drabbar nog mergesort hårdare än de andra. AMD med 32 MB L3 borde gynna mergesort. Radixsort har en annan egenskap som är unik. Sortering av 1 mega 16bitarstal borde gå dubbelt så snabbt som 1 mega 32bitarstal.

Permalänk
Medlem

Som många säger, så beror det ju på lite.

Finns ett cheat sheet som man kan referera till och matcha mot sina parametrar.

https://www.bigocheatsheet.com/

Permalänk

För den som använder Go eller Golang:
http://rosettacode.org/wiki/Sorting_algorithms/Cocktail_sort_...
Här jämför man två algoritmer.

Förutom Go använder jag C, C++, Fortran och Pascal
Om man inte använder egen timer kan man köra time i unix/linux
Då får man hela tiden men att skapa en array och fylla den med slumptal bär ju vara lika för alla algoritmer.

Permalänk
Medlem

Det beror som sagt på vad man vill sortera. Men vad många standardbibliotek använder är introsort, som kombinerar quicksort, heapsort och insertion sort.

Permalänk

Dramatisk försämring av quicksort:
a[i] = 100000 +rand()%20 i stället för a[i] = rand()%200000
Från 49 ms till 2770 ms på 200 000 tal
Mergesort från 133 ms till 119 ms dvs en liten förbättring!

Permalänk
Medlem
Skrivet av Greyguy1948:

Dramatisk försämring av quicksort:
a[i] = 100000 +rand()%20 i stället för a[i] = rand()%200000
Från 49 ms till 2770 ms på 200 000 tal
Mergesort från 133 ms till 119 ms dvs en liten förbättring!

Count sort (som vet att minsta talet är 0 och största är M-1), stabilt men ej in-place:
N=200000 M=20 t=1 ms
N=200000 M=200000 t=1 ms

N=2000000 M=20 t=6 ms
N=20000000 M=20 t=65 ms
N=200000000 M=20 t=851 ms

N=2000000 M=200000 t=10 ms
N=20000000 M=200000 t=180 ms
N=200000000 M=200000 t=2332 ms

Permalänk

Som @perost nämner så är de oftast någon typ av hybrid som används. Har du specifika dataset du har kontroll på men karaktäristiska egenskaper kan de gå att optimera just för dessa. Här är några exempel på hybrida algoritmer. Dock helt klart överkurs om du bara ska sortera något och vill testa skriva en egen algoritm, då kan du hålla dig till de klassiska som nämnts ovan.

Visa signatur

=)

Permalänk
Medlem

Semi-OT, men det första jag kom att tänka på är den här godingen:

Visa signatur

5950X, 3090

Permalänk
Medlem

Varje gång jag skall sortera något tittar jag igenom denna. De har ett gäng för olika metoder

Permalänk
Medlem

@Xerbee: Hahaha, klockren!

Visa signatur

5950X, 3090

Permalänk
Medlem
Skrivet av backfeed:

Semi-OT, men det första jag kom att tänka på är den här godingen:

https://www.youtube.com/watch?v=8MsTNqK3o_w

Herrejösses, jag spolade igenom och tittade på den i minst 40 minuter

Visa signatur

Asus B550E-Gaming / Ryzen 5900X stock / Corsair Vengeance 32GB 3600 MHz CL18 /
ASUS TUF 4080 Gaming OC / Samsung 980 PRO 2TB PCI-Ev4 + 2TB WD Black NVME PCI-Ev3 / Corsair RM850x v2 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / Phantek P500A / Arctic Cooling LF II 240mm / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X
Ownit > Bahnhof