How is bitslicing faster? I have read a paper on Bit Slicing and Lightweight crypto but cannot understand how bitslicing makes encryption scheme faster.

Please can someone explain with an example exactly how bit slicing makes the code faster (even a single xor example will suffice)? Can bitslicing be applied to any encryption scheme?
Bitslicing is a technique where computation is:

Reduced to elementary operations (called gates) with a single bit output (typically NOR, XOR, and similar like OR AND NAND NXOR, often with further restriction to two inputs), rather than operations on words or integers spanning several bits.
Executed in parallel, with as many simultaneous instances (on a single CPU) as there are bits in some register kind, performing NOR, XOR.. simultaneously on all bits of such registers.

Doing 1 generates a large number of gates: XOR of two $n$-bit words requires $n$ gates; for $n&gt;1$ their addition modulo $2^n$ requires $5n-6$ gates; each 8-bit S-box lookup in AES SubBytes requires about 128 gates; on the other hand rotations, arbitrary bit shuffling, selection or expansion requires no gate.
Doing 2 implements $w$ gates per instruction manipulating $w$-bit registers, and most of the speedup (if any) comes from that parallelization by a factor of $w$ (caveat: the effective $w$ can't be larger than the number of computations to perform simultaneously). Increasingly many embedded CPUs support $w=32=2^5$, CPUs with AVX instructions even support $w=256=2^8$. Most importantly, bitsliced code is immune to cache-related side channels (including timing). As a bonus, it is extremely linear, that makes efficient scheduling of data accesses easier, and there's no branching delay.
On the downside of bitslicing: Most importantly, making $w$ simultaneous operations do not match all workloads! For a single large file and common modes of operation of a block cipher, only CTR (or the flawed ECB) is fully usable (CBC and CFB are usable for decryption only, OFB is unusable). Also, the code is large and relatively complex; conversion from normal to bitsliced form of arguments (and back for results) requires bit transposition, which adds some significant overhead; lots of intermediary results or state data that would fit in registers or L1 cache in a normal implementation, do not.
In principle, any cryptographic calculation performed on multiple instances can be bitsliced. However many operations natively handled without bitslicing are unlikely to gain any speed benefit; this includes anything too simple (like the proposed XOR), or with grossly inefficient translation to gates (like modular multiplication, or looking up large arbitrary fixed tables, or sizable dynamic tables), or where the execution flow has too many paths. Refer to Ilmari Karonen's answer for a more detailed classification. And again, we need to be in a position to make several computations in parallel!
The archetypal example of a real cipher where bitslicing can have a speed benefit is (3)DES, as pioneered by Eli Biham's A fast new DES implementation in software (in Proceedings of FSE 1997).

Anything much simpler than DES that I could construct to show the benefit of bitslicing would be far from real-life; so I take as example a purely software implementation of (single) DES, with pre-computed subkeys, on a CPU with like a dozen general-purpose 128-bit registers, 128-bit (cache) memory accesses, for encryption of 128 blocks (1024 arbitrary bytes; I ignore optimizations possible in CTR mode).
A traditional (non-bitsliced) implementation goes:

for each of the $w$ blocks

transform the input block into two 32-bit halves L and R per Initial Permutation (IP, a bit transposition)
for round $r$ from 1 to 16

load the 48-bit subkey for round $r$ into a register K
for S-box $s$ from 8 to 1

make an appropriately rotated copy or R
XOR that with K
keep the low 6 bits of that
use that as the index to load the $s$th S-table, consisting of $64=2^6$ values each 32-bit (implementing the S-box and part of permutation P, hence the wide output); that step often dominates the cost and can be the target cache-related side channels
XOR that into L
shift K to the right by 6 bits for the next S-box


exchange R and L


transform the two 32-bit halves R and L into the output block per IP-1



The S-box loop is customarily unrolled (as well as at least two consecutive executions of the round loop, which makes the exchange essentially free), thus cost is dominated by the numbered steps. We can suppress 1 out of 8 steps 1 and 6. So a good approximation of the cost (ignoring IP and IP-1 for now) is $w$ times 16 times: 9 memory loads (8 of which indexed) and about 38 other simple operations.
Bitsliced DES suppresses the outer block loop, replacing it with operations on $w=128$-bit at each step manipulating block-dependent data:

transform the 128 input blocks (each 64-bit) into 64 memory words (each 128-bit) each holding all the bits of the same rank in a block (a bit transposition)
for round $r$ from 1 to 16

load the 48-bit subkey for round $r$ into a register K
for S-box $s$ from 8 to 1

for each of the 6 input bits j of S-box $s$
  a) duplicate the rightmost bit of K into a 128-bit wide register Tj
  b) load the 128-bit memory word holding the appropriate bit of the state
  c) XOR that into Tj
  d) shift K right by one bit
for each of the 4 output bits of S-box $s$
  a) compute that output bit (simultaneously for all the 128 blocks) as a boolean function of T1..T6, into 128-bit register X
  b) load the 128-bit memory word holding the appropriate bit of the state
  c) XOR that with X
  d) store that as the 128-bit memory word holding the appropriate bit of the state




transform the 64 memory words (each 128-bit) into 128 output blocks (each 64-bit) to form the result (a bit transposition reversing the first)

We'll unroll the round loop (if we want fixed addresses for the load/stores other than for the subkeys, we need two versions depending on if $r$ is odd or even). Independently: we can use that 2 out 6 values loaded at step 1a will be reusable for the next (or/and last) S-box, reducing the effective number of loads at step 1b, at the cost of few extra registers.
In step 2a, an S-box is replaced by boolean operations. Using the expressions derived by Matthew Kwan in Reducing the Gate Count of Bitslice DES (ePrint 2000/051), the average cost goes down to 51 boolean operations per S-box, at the cost of requiring some temporary registers, and somewhat undesirable bursts of stores at step 2d.
So a good approximation of the cost (ignoring initial and final transpositions) is 16 times: 65 memory loads and 32 memory writes (none indexed), and about 440 other operations.
Bitslice DES is thus a winner on speed if we ignore the cost of the initial and final transpositions, even if wide operations are somewhat more costly than narrow ones: memory accesses per round are reduced from $9w=1152$ to $97$; other operations from $38w=4864$ to $440$. That tenfold improvement (for $w=128=2^7$) outweighs the extra cost of the transpositions (which anyway is moderately higher than the cost of $w$ times IP and IP-1: in the end, the same amount of data is transposed). With careful coding, bitslice DES might be faster including for $w=32=2^5$.