I can't speak for the algorithm used for Deep Blue, but I'm going to try and explain the improvements in chess programming. Speed is the greatest improvement. Deep Blue used multi-processor dedicated computers, so a comparison isn't really possible.
https://chessprogramming.wikispaces.com/ is a great source, but it's hard to navigate.
There are 3 main functions that are tweaked to improve a chess engine are the evaluation, move generation, and search functions.
Evaluation is the hardest to program, as there are many exceptions to the rules. With hard drive space getting cheaper, the eval function allows for more exceptions to be evaluated.
Move generation, along with making and unmaking a move, consumes a lot of memory because it has to be preformed so many times. The most common generation functions are mailbox, bitboard, 0x88, 8x8, extended boards (10x10, 10x12), and a predetermined move array/table (*I use an indexed move table). Current opinion is that bitboards are the faster, and using magic bitboards speed this by up to 30%. Dr. Robert Hyatt, professor and creator of cratfy chess engine, claims no significant speed increase.
The early search function was the primitive min-max functions. Basically were you try to maximize the score of the side to move and minimize the opponent's score. Alpha-Beta was the first improvement. They reduced the number of moves being searched by transposition table, cut-off values, aspiration windows, and history heuristics. These are depth-first searches. There is also the internal iterative deepening search which tries to search the "best" move(s) the deepest hoping that searching other moves will prove to be fruitless.
NOTE: My index table.
GNUChess and Jester both use an index array to generate their moves. They initialize the engine by filling array with possible moves. The take the six pieces and compute the legal moves that are available from each square. So each piece had a [64][8] array. I took this idea and compressed it to two indexes and a table. The table holds a value which tells if the 16 moves are possible, one index holds the offset of the move, and the other holds the mask.
offset[] = {-8, -1, 1, 8, -9, -7, 7, 9, -17, -15, -10, -6, 6, 10, 15, 17};
mask[] = {1, 2, 4, 8, 16, 32, 64, 128, 256, ...};
Then the generation of a sliding move is as easy as looking up the validity of it's mask in it's allowable offsets against the move table.