HomeVideos

Dear XQC

Now Playing

Dear XQC

Transcript

195 segments

0:00

All right, so this video is for XQC. If

0:01

you're not XQC, stop watching this

0:04

video. All right, Mr. QC, I saw you

0:06

watching some sorting algorithms. I'd

0:08

always knew you were a bit of a computer

0:09

science boy. You know, they always say

0:11

computer science is the third highest

0:13

skill ceiling, second being Overwatch,

0:15

first one being Rocket League. Now, I'm

0:17

somewhat of a computer scientist myself.

0:19

And while watching that video of you

0:21

looking at sorting algorithms, I

0:23

realized you got a little bit of

0:24

misinformation, but you also got a

0:26

couple things really correct. First,

0:28

let's actually talk about the thing you

0:29

got right.

0:31

>> Wait, how?

0:36

That's slow. That is so bad.

0:38

>> Okay, so what you were looking at is

0:40

insertion sort. Insertion sort is bad,

0:42

but the reason why it's bad, you kind of

0:44

guessed to the whole scanning of the

0:46

arrow. So, how does insertion sort work?

0:48

Well, it's actually pretty simple.

0:50

Imagine you have a big list of numbers.

0:51

Let's just say 2, 8, and one for right

0:54

now. If you run insertion sort, it

0:57

starts on the first one. Well, if

0:58

there's only a list of one number, it's

1:00

always sorted. So, how it works is it

1:02

takes eight and it will walk backwards

1:03

until it hits a number smaller than

1:05

eight. Well, right away, first check,

1:07

two smaller than eight. Okay, these two

1:09

are sorted. Then it gets to one. Now,

1:11

one does the exact same thing. Is one

1:13

smaller than eight? It is. Okay, that

1:15

means we have to swap eight for one. Is

1:17

one smaller than two? Yes, it is. We

1:19

need to swap one for two. And now our

1:22

new list is going to be 1 28. You can

1:24

even see in the video that the height of

1:27

the lines have to go all the way back

1:29

into the position over and over and over

1:32

again. One element at a time,

1:37

>> DUDE. SEE, I TOLD YOU MERGE SWORDS

1:39

FASTER.

1:41

WA WA WA WA wa wa. First off, that's

1:44

some misinformation right there. Okay,

1:46

somebody's been bamboozingly. Whoever

1:48

created that quick sort algorithm, they

1:50

failed you. They lied to your face, my

1:52

friend. Before I show you why quicksort

1:54

is in fact faster than merge sort and

1:56

how they actually work. First, here's

1:58

the code for quicksort right here. Okay,

2:00

a little bit of C, you know, the Lord's

2:02

language. And here's the code for merge

2:03

sort also in C, the Lord's language. I

2:06

made the script actually run a quick

2:08

sort and merge sort on 1,000 long list

2:11

of numbers 1,000 times. And quicksort,

2:14

it does it almost every single time at

2:16

35 34 milliseconds, whereas merge sort

2:19

does it about 50 milliseconds, 51

2:21

milliseconds. So, whoever made that

2:23

merge sort implementation and that

2:25

quicksort implementation, they're just

2:26

not good programmers, okay? They

2:28

probably just generated the code with

2:29

chat jippity just did it all wrong. Chat

2:32

jippity. All right, so how does merge

2:34

sort work? Well, first off, you can

2:36

imagine you have a really long list of

2:37

numbers right here. You split that list

2:40

in twain. Let's pretend we had 1,024

2:42

numbers. The next list, we have two sets

2:44

of 512 numbers. If we split it again,

2:47

we'll have four lists of 256. If you

2:50

keep splitting it in twain, you will

2:52

eventually get to lists of size one. So

2:55

the reason why it's called merge sort is

2:56

right here. We get a bunch of these

2:58

one-sized arrays and now we have to

3:00

combine them. So we're going to take two

3:02

one-sized array. Let's say the other

3:03

side is eight. And we're going to say,

3:05

okay, let's combine these in order. That

3:06

means we're going to first want to take

3:08

the smaller one and then we take the

3:09

bigger one. So we have one and eight.

3:12

Now we're going to have a whole bunch of

3:13

size two arrays. Now we're going to

3:16

combine them each into size four arrays.

3:18

So, let's pretend we have another one

3:19

that has two and seven. Well, then what

3:21

were we going to do? We're going to

3:22

combine it. Okay, we're going to take

3:24

the one from this side. That's a one.

3:25

Then we're going to take this one from

3:26

this side. That's a two. Then we take

3:28

the seven from this side. And then we're

3:30

going to take the eight. And now we have

3:31

an array of size four. And then you keep

3:34

doing this all the way back up. In other

3:36

words, we have to look through every

3:38

single one of the one sized arrays once.

3:42

Meaning, we have to walk the array one

3:43

time or size n or 1024 in this case.

3:46

Then we have to walk through all of the

3:48

size 2 arrays one time. Another n then 4

3:52

8 16 32 64 128 256 and 512. And after

3:56

you've done all of that, that means

3:58

you've walked the size of n log n times.

4:01

Or in other words, we have a running

4:03

time of n login. NOW THIS IS PRETTY

4:05

FAST. OKAY, this is pretty dang fast.

4:07

The thing that makes merge sort slower

4:09

is that when you create say the list of

4:11

two from two ones, you have to create a

4:13

brand new list and then move each number

4:15

up into it. When you create a list of

4:17

four, you have to move each number up

4:19

into it. So you have to keep on creating

4:21

a bunch of memory, a bunch of sublists

4:23

and eventually you have to create n log

4:26

n amount of memory. So this is typically

4:29

why merge sort is just slower. Even if

4:31

you are a novice in the old computer

4:33

science realm, you can see right away

4:35

this is much better than insertion sort

4:37

because insertion sort you could have to

4:39

walk the entire length of the array over

4:42

and over and over again. And my gosh,

4:45

did you see that? I just freehand two

4:48

completely straight lines and then just

4:50

like a little crook just like a little

4:52

bit of one. But quicksort's different

4:54

because you take the same array and you

4:56

just pick a random element out of the

4:58

array. And then you put all the things

5:00

that are smaller than this one that you

5:02

picked on this side and all the things

5:03

that are larger on this side. And this

5:06

one singular element is actually sorted.

5:09

The rest is not sorted. And then you

5:10

take this longer list and this shorter

5:12

list and you do the exact same thing.

5:14

You pick a random number and then you

5:15

put all the smaller elements on one

5:17

side, all the larger elements on the

5:19

other side. But here's the trick. Notice

5:21

that you don't have to create new arrays

5:24

to reconstruct it. Instead, you actually

5:27

sort in place, meaning you don't create

5:30

a bunch of memory. You want to hear

5:31

something weird, though? Quicksort often

5:34

uses insertion sort as the lists get

5:37

really, really small. So if you have a

5:38

list of four items left, instead of

5:40

doing another quick sort list of

5:41

splitting the list, then calling itself

5:43

again, then splitting it again down to

5:45

one, and then regoing back up the tree,

5:48

instead all it does it goes, okay, well,

5:50

I can just sort this list with insertion

5:51

sort because it's actually much faster

5:53

than calling functions cuz it turns out

5:55

swapping just a few indices is actually

5:57

blazingly fast. So is insertion sort

6:00

slow? Yes, it is slow. But is it always

6:02

slow? No. No, it's not. Anyways, I

6:05

thought I'd just give you a little quick

6:06

tip on the old algorithms, okay? The old

6:08

sorting algorithms. Hey, if you ever

6:10

need one explained, next time I'll get

6:12

out the whiteboard, okay? Hey, you want

6:14

dystras? I'll get you dystras, buddy.

6:16

The name is the primogen.

6:19

Hey, do you want to learn how to code?

6:21

Do you want to become a better back-end

6:23

engineer? Well, you got to check out

6:24

boot.dev. Now, I personally have made a

6:26

couple courses from them. I have live

6:28

walkthroughs free available on YouTube

6:30

of the whole course. Everything on

6:32

boot.dev Dev, you can go through for

6:34

free. But if you want the gamified

6:36

experience, the tracking of your

6:37

learning and all that, then you got to

6:38

pay up the money. But hey, go check them

6:40

out. It's awesome. Many content creators

6:42

you know and you like make courses

6:44

there. boot.dev/prime for 25% off.

Interactive Summary

The video explains sorting algorithms, specifically addressing common misconceptions about their efficiency. It clarifies how insertion sort works and why it's considered slow for large datasets. The speaker then corrects the idea that merge sort is faster than quicksort, providing benchmarks that show quicksort's superior speed. He details the mechanics of merge sort, emphasizing its memory overhead due to repeated creation of new lists during merging. Quicksort is then explained as an in-place sorting algorithm, which contributes to its faster performance by avoiding extensive memory allocation. Interestingly, quicksort often employs insertion sort for very small sub-lists, as it becomes more efficient than recursive calls in those specific scenarios.

Suggested questions

5 ready-made prompts