>> Mohit Singh: Okay, yes. It's a pleasure to have Thomas tell us about the scheduling
problem, which is I guess one of the four, or three of the four, remaining open problems from
Garey and Johnson, so the problem is really old, and Thomas is going to tell us something new
on it.
>> Thomas Rothvoss: Yes, thanks. I think technically speaking, we're not going to completely
close it, but anyway, thanks for getting up so early. This isn't the time for everybody in the
room. Okay, yes, this is ->>: I just want to say that there are only five of us in the room, so you could talk to us a little
more personally.
>> Thomas Rothvoss: Okay. Okay, I will try to address the audience more personally. Thank
you, James, for asking the first question before I start. Okay, so this is joint work with Elaine
Levey, who is also at UW. Okay, so this is the problem I want to talk about. You have some
unit size jobs, so you have some jobs that have processing length 1, and the jobs have precedence
constraints, so you have to process, let's say, this job, before you can start any of those jobs here.
And I give you M machines. They are all identical. The goal is, you want to schedule the jobs in
a nonpreemptive way so that the makespan is minimized, and the makespan is the time that the
last job finishes. Okay? Okay, so just to warm up, let me just explain to you a simple 2
approximation algorithm that's 50 years old and works as follows. You just schedule everything
gradually, so let's say you just select any job that you can select, and you just put it on one of the
machines. Now, there is another job that you can just process, and now you see that, well, in
principle, you have a third machine here, but you don't have a job where all the predecessors are
already completed, so you leave that slot empty and you move on with the next time and with the
next job. So you just do everything gradually, the way you would imagine it makes sense, so
this is how the algorithm would work, and okay. So here you see that while there is this chain,
we didn't pay a lot of attention to that, so we have quite some idle times here, and now this is the
time that the last job finishes. Now, you can see that actually this is the makespan here, so this is
the time that the last job is finishing. You can also see that this is not the optimum solution.
There is this chain of five jobs. We probably should have started this a lot earlier and just work
on the chain all the time, so this is an approximation algorithm, and it definitely does not always
give you the optimal solution. But the claim is this gives you a 2 approximation, so how can you
see this? So first of all, if you stare at the times where there is some idle time, where you didn't
use all of the machines, then why did you do that? Why did you not process this job earlier?
Well, actually, the reason is that there has to be a job that it depends on coming earlier, and that's
actually the only reason why you couldn't schedule this earlier. So to be more precise, there is a
chain that goes over all of the non-busy times, and if you wanted to be formal, you could
construct this chain from the last job. You could wonder, why did I not schedule this guy
earlier? Well, because of this job. Why did I not schedule this guy earlier? Because of this job.
Why did I not schedule this guy earlier? Because of this job, and so on. Now, you can wonder,
if you have a chain, what's the length of the chain? Well, the length of any chain is the lower
bound of the optimum, because also the optimum kind of needs to process the chain somewhere.
Okay, so that's good. So this gives us a bound on the non-busy periods. Actually, bounding the
busy periods is even easier, because you can imagine that even if the optimum would be allowed
to ignore all the precedence constraints, even then, just to process all the jobs, you need at least
that amount of time. Okay? Great. And now you just add things up and you get that the
schedule we're getting has length that was 2 times the optimum. Actually, the algorithm isn't
much better than a 2 approximation. You can be a little bit more careful, and depending on how
large your number of machines is, you can be a little bit better than 2, but if that number goes to
infinity, then the ratio goes to 2, like the approximation ratio of this algorithm. Okay. So we
would like to beat this algorithm, and it's kind of what's like the standard technique in
approximation algorithms? You write on some linear program. So we could do that, and this
might be the natural linear program, like experts would probably call that a time index version.
So let's say you have a variable X(jt), and this variable is going to tell you whether you want to
run the job at time T, and I hope you see that you only need to consider integer times. There are
just integer timeslots. So what would be the constraints? Every job should be scheduled
somewhere. At any time, you can schedule at most M jobs. M is the number of machines you
have, and then you should have some constraint that implements the precedence constraints, so
you should have if some job, I should be finished before J, then it's of the fraction that's finished
until some time T, can't be bigger than the fraction that's scheduled for that other job until time T
plus 1. Okay, good. So this is a fine linear program, but can you beat the gap of 2? No, not
really. It's not hard to come up with some integrality gap construction. Just imagine in this case
I give you two machines, but you could have some kind of blocks of three jobs. Let's say this is
like a long sequence of jobs, and it's kind of the other jobs in the Ith block depend on the I minus
first block, and now the fractional solution that you could construct would be that you can kind
of process all the jobs in the same block in parallel. So this would mean that these three jobs -in an integral solution, you would need 2 time units, but the fractional solution could essentially
schedule this in 1.5 time units. It's nice to observe that in the fractional solution, the support of
jobs can overlap even if the jobs have precedence constraints, so this is something you can't rule
out. That makes the whole thing difficult. So the integrality gap, it's also essentially 2, so if the
number of machine goes, then the gap will tend to 2. So this isn't really going to buy you that
much.
>>: Is there a rounding algorithm based on this?
>> Thomas Rothvoss: You could probably come up with some rounding algorithm. I doubt that
you could beat the simple greedy algorithm.
>> Mohit Singh: But even getting factor 2.
>> Thomas Rothvoss: For this problem, it's extremely hard to not get a factor of 2 in some
sense, so yes, it's probably an exercise. I haven't done it myself.
>>: Is it the same as integral scheduling, but you allow me to start jobs at fractional times?
That's at least what this takes advantage of, right, like 1, 2 and three start at second 2, and then
they go to second 2.5, and then you start 4, 5, 6. I'm just saying, then you sort of can -- at least
for this, you can respect the precedence constraints but just have, be able to ->> Thomas Rothvoss: Is this the same? I don't think so. No, I don't think so. No, I don't think
it's the same. Okay. Good. Okay, so we did see that little 2 approximation algorithm by
Graham, and in fact, it's unlikely that you can beat the 2 in general. So there's a paper by Olah
saying that, well, under some variant of the unique games conjecture, you're not going to -- you
won't be able to beat the factor of 2. That's the question what I'm going to talk about in the next
2.5 hours, but okay. So in scheduling, it does actually make a lot of sense to consider cases like
what happens if the number of machines is a constant, so think of M as being a big constant.
Maybe then we can beat the factor of 2, and there hasn't been much success, actually, so this is
what we want to do. Okay. And Mohit mentioned already that this is -- essentially, this is one of
the four open problems in Garey and Johnson, where now it's maybe three and a half open
problems, now that graph isomorphism is kind of solved.
>>: How do you -- you can beat factor of 2 if M is a large constant, so what's the question?
>> Thomas Rothvoss: If this is -- if M is allowed to grow with input lang, you can't beat 2.
>>: So how are you going to fit a result in between those two bullets?
>> Thomas Rothvoss: I will give you an algorithm, but the running time will depend
exponentially on M, on the number of machines, and there was no such algorithm known before
that's better than 2. Okay. In fact, if you have let's say three machines, it's unclear whether this
is an NP hard problem. There's a nice survey of Schuurman and Woeginger about open
problems in scheduling. It's now 16 years old. A couple of problems have been solved. One of
the problems that has been opened is whether let's say for three machines there is a P test ->> Mohit Singh: Sorry, is [indiscernible] constant hardness node, or no?
>> Thomas Rothvoss: It's not known, no. Like if you have 10 billion machines, it's also open
whether this is NP hard. Yes. And the result I want to talk about here is that actually, you can
take that linear program, you can throw it into your favorite LP or STP hierarchy, and after some
number of rounds, the gap goes down to 1 plus epsilon. That number of rounds is a weird
number that's a little more than poly log, and the epsilon of the M actually goes here into the
hull. Okay, so this gives you also an algorithm that finds the schedule in some kind of weird a
little more than quasi-polynomial running time.
>>: But the [indiscernible] of M is like a pretty big -- because you didn't write it.
>> Thomas Rothvoss: That's like the rule of thumb. It's really an M here and I think times 1
over epsilon squared I think is the dependence here. On the other hand, it's in the exponent.
Good. Okay. Good, so this is what I want to talk about. Okay, so what's the Lasserre hierarchy?
The idea is it's a very general idea. You imagine you have some linear program, let's say with
binary variables. Let's say the set of feasible fraction solutions is K. Now, you want to add in
some more constraints so that your LP becomes better. So what ideally you want to have is that
convex hull of the integer points in K. You're not going to get there, but you can write down
some bigger system, and it's going to be kind of stronger than your original linear program. That
system will depend on some parameter that's called the number of rounds of the hierarchy, and as
you increase the parameter, the hierarchy gets stronger and stronger, and then eventually, after a
number of variables, many durations, it's going to converge to the integral hull. Okay, so many
of you might have seen this already. So the idea is that if this is just a general linear program,
then you -- and T is your number of rounds, then you would just take variables for all subsets of
at most T many variables, and you'd write down some kind of meta variable, which is supposed
to tell you the extent to which all of those variables have to be 1, so you have some extra
variables. This is why it's so-called lift and project, because the extra variables, they give you a
lift, and in particular, you will have your original variables in there. And now you just need to
write down some constraint system that gives you some kind of consistency, and you can do this
explicitly. I don't want to go into details. At this point, I would like to treat the Lasserre
hierarchy as a black box. We know what properties it has. But if you wanted to write down
explicitly the constraints, then you would take your variables. You would throw them into a big
matrix that's called the moment matrix, and then you ask that this moment matrix has to be
positive semi-definite. You also would take all the constraints that you would have and you
would put them together into another big moment matrix, and also that has to be positive semidefinite for a point A constraint.
>>: You say it works with [indiscernible].
>> Thomas Rothvoss: Yes.
>>: So why are you describing the serve?
>> Thomas Rothvoss: Purely hypothetically, imagine one of the authors has a survey on the
Lasserre hierarchy and wanted to copy-paste this. Actually, I find the definition more elegant
than for Sherali-Adams. It doesn't matter. So we're using -- yes, the Lasserre hierarchy has a lot
more power than we need. Okay. I hope that doesn't make you -- doesn't cause you a headache,
okay? We're not using any kind of fancy polynomial-whatever power here. Okay, good. James
doesn't look convinced, just for the record. For the people who can't see ->>: I'm trying to follow, so I want to be prepared.
>> Thomas Rothvoss: Okay, okay, okay. Imagine this is Sherali-Adams. Imagine for yourself
this is Sherali-Adams. It's not going to be any different, the algorithm isn't. Okay, so if that
number of rounds T is a constant, you can solve those systems in polynomial time, and well, for
us, it's not going to be constant. It's going to be that weird somewhat more than poly log term, so
this is going to be, yes, a little bit more than quasi-polynomial. Okay, good.
>>: Okay, and I have one more question. So if 2 minus epsilon was NP hard, then your result
says that the running time on the reduction, okay, assuming that like say [sat] requires
exponential time, your thing says the running time reduction has to be at least something.
>> Thomas Rothvoss: Yes.
>>: Do you have any idea of like ballpark what that is, or it's just some function of epsilon and
M?
>> Thomas Rothvoss: Yes. It's going to be some function. I never figured it out, but you could
have sub-argument in that, yes. Okay. Okay, so the Lasserre hierarchy and the Sherali-Adams
hierarchy, they have some nice properties, which is as follows. If you look at a solution which is
valid for T rounds, and you look at one of the variables that's strictly between 0 and 1, then it's
true that this is actually a convex combination of two solutions, two Lasserre solutions, one
where the variable is 0, one where the variable is 1, and both of those are valid for one round
less. Okay. In particular, a way to reinterpret this is as follows, that if you have a Lasserre
vector, you have a variable that's strictly between 0 and 1, then you can say, oh, I want to have
that this variable is actually 1. So you can what's called -- you can induce on that variable being
1, which geometrically means you're just replacing your Lasserre vector by one of those guys
where the variable is actually 1, and this is going to cost you one record. And we will do this
frequently.
>> Mohit Singh: One or 0?
>> Thomas Rothvoss: Yes, we are doing this with 1. Obviously, the same thing would also
work if you wanted to set the variable to 0, yes. Okay, good. There's one observation that's
worth making that looks trivial, but if you do this conditioning, then the support of your Lasserre
vector is only going to shrink. Now, imagine this would be an actual probability distribution,
and if you induce on some event, then another event that had a 0 probability before is still going
to have a 0 probability. No conditioning will make the probability suddenly positive. Okay,
good. Okay. Fine. So this is -- okay, let me now go to the algorithm, and here is a little bit what
we want to do. So imagine we kind of guess the time that the optimum needs. Let's say this is
capital T, so imagine this is the time horizon. We kind of give this parameter capital T to
Lasserre, and we find some Lasserre solution with a large enough number of rounds, which is
kind of valid for that scheduling LP. And now we want to round that scheduling Lasserre LP,
STP. Okay, so first, if this is the time horizon, let's look at some kind of a binary partition of that
time horizon, so we just partition everything always into two intervals of the same length, and
then obviously we need like log T many levels. And now let's imagine that these are jobs, and
let's look at the support of jobs, so these are times when the Lasserre vector has some positive
probability of scheduling the guy. So they don't have to be intervals. They don't need to be
consecutive to support. Okay. Now, we want to do the following. Imagine for the moment we
kind of assign the jobs to the minimal interval containing all the support. Okay. Now, the idea is
we want to have an algorithm that essentially starts at the bottom of the partition and schedules
the job, so we would like to first schedule the jobs that have a very small support, and then later
add in the jobs where the support was very long, kind of hoping that they had more flexibility.
Okay. Good. Okay, now, this is the actual algorithm. This is the overview of the actual
algorithm. In the first step, we do the following. We look at the first let's say log log N-square,
many of those levels. And we massage the Lasserre vector. By conditioning on certain events,
we will get that the maximum chain of jobs that are assigned to those levels is small, and I will
explain this in a little more detail on the next slide. Let's take this as given for now. Okay.
Now, after we do this, let's say these are the supports of the jobs, and these are the intervals
where they are assigned to.
>>: I missed something very basic. What does it mean, the support of the job?
>> Thomas Rothvoss: These are the time units where this guy is scheduled, so let's say this is JT
where this is positive. This is the support of a job, and now kind of with respect to the current
Lasserre solution.
>>: Is it clear the support will be continuous?
>> Thomas Rothvoss: No, it's not in general.
>>: The figure seems to suggest it.
>> Thomas Rothvoss: The laziness of the person drawing the picture, which is me, suggests that
it would be. I think one's here, here. And then from now on, they just look like intervals, but
they don't have to be. Okay, good. Okay, so it's like, for example, this blue rectangle mean that,
yes, there is some probability that the job is scheduled here, some probability that the job is
scheduled there and so on. Okay, good. So now we want to create some gap here, and we take
log log N levels. It's kind of somewhere in the middle, and we delete all the jobs. We throw
them away. Now, you might be saying that I'm forced to schedule all the jobs, but if I have a
small fraction of jobs that I kind of threw away, I can kind of just insert them at the very end, and
you can just imagine that for every job, you can just insert a private new time for him, and you
can just insert him, and that is -- well, you just paid this extra in the bank spend, but that's not a
big problem. Okay, so as long as we're throwing away only an epsilon over M fraction of the
jobs, we're good. Okay, good. Now, this creates a gap in the sense that now the intervals at the
top are a lot longer than the intervals being down here, and if you do the math, and actually, this
factor is like a poly log term of this thing, and I need that poly log term. That's why I have log
log N levels here. Okay, good. Now, I do the following. I have my Lasserre vector, and please
remember that I did some conditioning, so it's not anymore the original Lasserre vector, but I do
the following. I now recursively run my scheduling algorithm, and I schedule all the jobs in
those bottom intervals. So I go through every of those bottom intervals, and I just schedule the
vectors. I schedule the jobs, and I do this independently for those intervals. And the important
thing is that I have my Lasserre vector, and I give a copy to every of those intervals here, and
now since I do this recursively, there's going to be some conditioning going on here, some
independent conditioning going on there. So I schedule the job.
>>: Tell me, how do you schedule the jobs?
>> Thomas Rothvoss: Recursively.
>>: What does it mean?
>> Thomas Rothvoss: Well, to understand recursion, you first need to understand recursion, but
-- yes, it's an old one. Sorry.
>>: So you're doing that using the property that every point is a combination of ->> Thomas Rothvoss: I would say here -- okay, the algorithm that I kind of here described, I
described it here kind of for the top interval, for the largest possible interval, for the whole time
horizon. But you can imagine, you run the same algorithm that I just described here, you run it
just for that smaller time horizon, and you run it only with the jobs that had the complete support
in here.
>> Mohit Singh: But they're not exact solutions, right? Because I always gave the job to an
[indiscernible].
>> Thomas Rothvoss: Wait, wait, wait. I look at the jobs that have the whole support in here.
And then it looks like the original problem, okay? It's just on a smaller timescale. Okay, good.
So that looks fine, but there is a problem. So there are my top jobs, and now I also have to
schedule the top jobs, and the problem is kind of have to insert them in the gaps that remain, and
there isn't really a reason why this should work, and so what could be the problem? The problem
is that we're doing a lot of conditioning in the Lasserre solution, and this is not necessarily
consistent. So it might be that in any actual integral solution, it's like if you schedule this job at
the end, then in the other interval, you would have to schedule another job kind of at the
beginning or also at the end, so that you can schedule those top jobs in between. So there is
some consistency that we are losing, okay? But it will still be enough, and why does it work?
The reason is that we have decreased the length of the maximum chain among the top jobs, the
jobs that are assigned to the top intervals. Okay, good. Okay. So first thing's first, let's talk
about the first point. What did I want to do? I had those jobs that were assigned to the first poly
log, log N many levels, and I wanted to decrease the length of the maximum chain by
conditioning on certain events.
>> Mohit Singh: So, Thomas, I just want to get some [indiscernible]. Is it clearly for the chain
that's a [small], you have a certain P task or something? Because I don't understand like ->> Thomas Rothvoss: Yes, it is. Because just look at Graham's algorithm. Okay, the bound
here is essentially you get the optimum plus the length of the maximum chain, which is that itself
is bounded by the optimum, but if you give me a better bound on the length of the maximum
chain, you can get something better than 2. Yes, so in particular, from this, you already see that
you only have a major problem if you have long chains, so we're kind of getting rid in some
sense of the long chain problem. Well, they will still exist, but yes. Okay, so what's -- where
were we? We were precisely not here. Okay, this is the thing. Okay, so don't look at the
statement of the lemma that we're going to prove. Look at the picture. So imagine, this is one of
the top intervals, and imagine there are a ton of jobs assigned to it. What does it mean they are
assigned to it? It means their whole support is contained, but the whole support also kind of
contains the separating line between the next top intervals. And okay, now imagine it happens
that some of these jobs has a lot of other jobs dependent on him. So in this case, there's the blue
job, and let's say there are a lot of other jobs dependent on him, but still, the support can overlap.
This cannot be ruled out. Okay, now we do kind of the obvious thing. We spend one of our
Lasserre rounds, and we condition on the event that this job with the [higher] degree is scheduled
in the right-hand side interval, in the right-hand side subinterval. Now, after this conditioning,
all the other jobs that depend on him will also be fully scheduled in that right-hand side interval.
So in some sense, after one conditioning, the support of a lot of jobs actually moves down by one
level, and so now -- well, you just repeat this argument, and the support of jobs always moves
down. You do this often enough. You count how many intervals do you actually have among
the top intervals, and then you get bound on the number of rounds that you're losing, so there is
some little calculation, but this is the basic argument.
>> Mohit Singh: So you are still [indiscernible], so you will know on the current [indiscernible]
combination, where either it is completely scheduled and I do, or not at all.
>> Thomas Rothvoss: Yes.
>> Mohit Singh: So you want to say that I go here or here.
>> Thomas Rothvoss: Yes.
>> Mohit Singh: How about you say and just go here?
>> Thomas Rothvoss: You take one of the variables, and you condition it to be 1.
>> Mohit Singh: But condition [faction] solution might not be a whole [faction] solution. It
might have an objective on it.
>> Thomas Rothvoss: I don't have an objective.
>> Mohit Singh: It's a feasibility problem.
>> Thomas Rothvoss: It's a feasibility problem.
>> Mohit Singh: Okay, good.
>> Thomas Rothvoss: Okay, any other questions? Okay, good. So what I hope I could
convince you is that I could actually -- if you look at the picture, I can actually decrease the
maximum chain length of jobs assigned to the top intervals to something as small as I like. And
that number, while I will lose some number of rounds proportional to that, but I'm good. Okay,
good. Okay, so that's fine. But let me go back to the next thing that we want to do. Okay, so
after I recursively scheduled all the jobs assigned to bottom intervals. Now, the crucial argument
is how do you insert the jobs assigned to top intervals. And now the only thing we know is that
actually, the length of any chain among those jobs is very short, is as short as we like. Okay,
now let's move on with that. Okay, so where is actually the problem? Imagine this is the job
assigned to one of the top intervals, but the job may actually depend on some jobs that are
scheduled in bottom intervals, and it also may have some of those jobs dependent on him. And
the problem is that now we would recursively schedule this guy somewhere in this interval, but
maybe we're scheduling him at the end, and we might schedule this guy somewhere here, but
maybe we schedule him at the beginning, so we don't have any control over that. So in principle,
I can imagine that for my top job, the only way to be safe is that I entered him in some slot that
comes after the end of any interval where a dependent bottom drop was scheduled. Okay? So
you could imagine that I define a release time for this job, and this is on some kind of scheduling
term. I define a release time for this job, which is the end of any interval where a dependent
bottom job is scheduled, and I define a deadline for my top job, which is the beginning of any
interval where -- like the earliest interval where a dependent bottom job is scheduled. Okay.
And now I will try to schedule my top job somewhere between that release time and deadline,
and if you look at the support of the top job, there is a little bit of a problem, because there is
some fraction of its support where I'm now kind of forbidden to schedule the job. Okay, good.
Okay, but here is the claim. The point is that the bottom intervals are a lot shorter than the top
intervals, and the gap is some poly log term. Okay. And I want to essentially schedule the top
jobs, imagine, in two phases. In the first phase, I want to just prove to you that I could schedule
the top jobs if I would be allowed to ignore any precedence constraint other than that I have to
schedule the job between release and deadline. This is what I show in the first phase. In the
second phase, I show that imagine I know that I can schedule the job between release time and
deadline, if I ignore precedence constraints. Now, I can also schedule it with precedence
constraints, knowing that the precedence constraints that I have to respect don't have long chains.
Okay, so let's start with the first argument. If the top jobs wouldn't have any precedence
constraints with each other, what could I do? I claim that then I could actually find a good
assignment, and now this is an easy problem. This is essentially a bipartite metric problem,
where you can imagine that for every top job, there are some slots, some time slots, where you
could schedule the job, and you know that the Lasserre solution, it was a fraction solution for
that bipartite matching problem. The only difficulty is that there are some parts of the fraction
solution are cut off. If you have a matching problem and there is some part in the matching
graph that is cut off, but you can check halts condition and you can just see what is the amount of
edges that I'm losing, and okay. So essentially, the only thing you need to check is the
following. You look at some subset of the top jobs, and you lose what is the neighborhood -what is the size of the neighborhood you're losing. And now the argument is that out of Q
intervals, out of Q bottom intervals, you're only losing two intervals. You're only losing the slots
in two intervals, and the reason is that every of the top jobs must contain one of those
borderlines. And you know that you have one of those borderlines only every Q of those small
intervals. So in particular, it means that you cannot lose more than two bottom intervals in any
of the -- that are contained in one of the top intervals, and I'm not convinced that this is a great
explanation, but I hope you believe that this is not a hard argument. So this is essentially -- it's a
bipartite matching problem. You can bound the number of jobs that you can't schedule anymore
by just looking at halts condition and just counting by how much your neighborhood could
possibly shrink. And here you use that you're kind of talking about intervals. Okay, good. So
this is the first phase. Now, the second phase is this is -- might look familiar to you if you're into
scheduling. Essentially, we're using the earliest deadline for scheduling policy, which is kind of
-- it's a standard thing in scheduling. It's kind of optimal in many settings. It's not exactly
optimal in our setting, but it's good enough, so what is the problem. So imagine these are our top
jobs. These are the jobs assigned to top intervals. Now, what is the setting, we know what we
have left now. We know that the length of the maximum chain is not too long. We can make
this as small as we like. We know that while each of those jobs may have a release time and may
have a deadline, we know that actually the time horizon is partitioned into a not-too-large
number of blocks which correspond to where the top intervals begin and where they end. Sorry,
where the largest of the bottom intervals begins and ends. And we also have some capacity left,
and please, remember that we already scheduled all the bottom jobs recursively, so there are
some slots are left. So you can imagine that there is some kind of capacity curve, and we have to
fill in the top jobs somewhere in the remaining slots. And from the last slide, we do know that if
we would be allowed to ignore any precedence constraint among the jobs, we would be able to
schedule everything. And now the argument is that we can still schedule essentially all of the
jobs, losing only a small number, and there the crucial argument is that the length of the
maximum chain was bounded. Okay. Good. So what is the earliest deadline first algorithm.
Essentially, you sort the jobs according to the deadlines, and now you just schedule them
greedily, and let's imagine the following. If you have a job and its deadline is coming and you
didn't manage to schedule job in one of the slots, then we just throw it away, and we want to
count how many of the jobs did we throw away. Okay, and there's the last slide. And this is
essentially a modification of a standard argument and scheduling, so if you ever look into a
scheduling book, you might find something very similar. So imagine this is the time horizon,
these are blocks, and you only have deadlines at the beginning and at the end of those blocks.
Okay. Now, let's assume for the sake of contradiction that there's some interval where we have
discarded more than K many jobs, and we want to get some bound on K, so let's imagine this is
very, very large, and then we will come to a [indiscernible]. Okay. Good. So for some technical
reason, imagine that the large job that you discarded in this block, it really was the lowest
priority job, and imagine you just delete everything else. The trick is that the earliest deadline
first policy doesn't actually change for all the jobs that came earlier, so that's without loss of
generality. Okay, so we know that this block is kind of overloaded. For some reason that we
don't understand yet, we were throwing a lot of jobs away. Now, let's backtrack and let's see -let's go back to the last block, where we had less than C many idle times, and C was the bound
on the maximum chain length, meaning that actually the block before had more than C many idle
times. And now the crucial argument is if you have a job that we did schedule in one of those
blocks here, then I claim that the deadline could not have been before this point. Because if it
would have been before this point, then it would have been at this point or earlier, and I had
more than C many idle times, meaning I could have scheduled it in here. So the point is, the
observation you should make is -- okay. So let's say in this picture, the maximum -- okay,
imagine the maximum chain length is two, and now here, let's say I have three free slots. Now,
imagine you want to schedule a job, and you want to schedule it as early as possible. Then the
only reason why I cannot schedule him in one of those three slots would be that while he has to
depend on this guy, but why did I not schedule this guy earlier? Well, he has to depend on this
guy. Well, then he has to depend on this guy. So then you can again construct a chain of length
more than C, very similar to Graham's algorithm, to the analysis of Graham's algorithm, and then
you would get a region. Okay, so what happens? So every job that we actually scheduled in this
area, it had release time and deadline here, so it had -- and any of those K jobs that we couldn't
schedule, it has release time and deadline here, and that gives you a bound on K. And the bound
depends on C and that number of blocks here. Yes, I think it should be -- K should be bounded
by PMC, so you know that in no block do you discard more than that many jobs, so you probably
have to multiply that with another factor of P, which is your number of blocks. And that's
actually the end of the whole thing. Okay. So there are some calculations. You just need to
count how many jobs did you throw away in total. You choose the parameters correctly, but
every idea is actually you did see. Okay. Is there any question? Okay. There are actually some
open problems. So it's not so clear whether not a constant number of Lasserre round would be
enough, or Sherali-Adams rounds, or at least an actual poly log number of rounds. So for us, this
is like -- this is M divided by epsilon-squared times log log N, so that's not so nice. Actually,
also nice problem is what happens if you have running times that are not one, but you have
arbitrary running times. Some of the arguments still make sense. Others don't. So that would be
nice, whether one can have some extension here, and that's what I wanted to tell you. Thank you
for listening.
>> Mohit Singh: Questions? What's an important problem?
>> Thomas Rothvoss: For this one? Well, the two approximations. So Graham's algorithm also
works if you have general running times. Two, maybe two minus 1RM, something like that, but
nothing better. Do you have a question?
>>: I had one technical question, because it might be [indiscernible], but somehow you just -why did you need this break of log log N, because I thought you just needed it to break -- you
just need 2 to be large, right?
>> Thomas Rothvoss: Yes, yes.
>>: But 2 could be a large constant, as well, right? K depends on epsilon, or indeed does it need
to depend on N?
>> Thomas Rothvoss: Okay, the problem is how many jobs you throw away, so you want to say
-- you want to throw away like an epsilon or epsilon round fraction of jobs throwing way would
be fine. There is a technical problem, which is that the level where the jobs are assigned, it can
move, because you do the conditioning. And this makes it very hard to only cut a constant
fraction of the jobs, so this is why we had to choose the parameter larger. It does look like a
technical problem. We really thought for some time about it, but we couldn't get rid of it. That's
the reason why there's the log N to the log log N term. It's one of the things where you write it
down, you think, okay, it's not going to take you more than 20 minutes to find a solution, and
two weeks later, you say, ah, let's be happy with it. Yes.
>> Mohit Singh: Any more questions? Okay, let's thank Thomas again.