Warning - I really like Lisp :-)
Actually, Lisp and C++ have the same performance these days:
http://www.lrde.epita.fr/cgi-bin/twiki/view/Publications/200606-IMECS
In Peter Norvig's "Paradigms of Artificial Intelligence Programming" he shows why Lisp was slow in the '60s versus Fortran/COBOL, and how performance has become much better as better compiler theory has developed.
Some, but not all, of the differences:
1. Lisp has automatic garbage collection (like Java, C#, Python, Perl, Ruby, etc.), but C++ asks you to deallocate your own memory. Some benchmarks have shown this makes C++ slower because giving the language runtime control allows it to schedule garbage collection for many objects at the same time, which provides better memory cache performance.
2. Lisp allows you to add keywords to the language (for example, if Lisp did not have "if" you could add it), but you can't do that with C++.
3. Lisp has a prompt where you can try things out, like Python or Ruby, and get immediate feedback. C++ requires you to compile, link and run to get some output and then go back to your code to make changes, then repeat.
4. Lisp allows you to change the definition of a function at any time. For example, while debugging, you can fix the code for a function and recompile and reload that function and then let the program continue running. Microsoft Visual Studio provides a limited version of this for C++, but other compilers do not.
5. Lisp functions can have keyword parameters (like in Perl, Python, etc.) but C++ functions can not. These are useful when you want to allow several options to override the default behavior, but don't want every call to the function to require a lot of parameters. C++ optional parameters only help a little, because if you only want to override the last parameter, you must know (and type) the default value for all of the others.
6. Lisp provides multiple-dispatch generic functions, while C++ member functions can only be dispatched based on the class they're a member of.
To see how Lisp makes 16 out of 23 of the "Gang of Four" patterns much easier or not needed, see
http://norvig.com/design-patterns/
7. Lisp directly supports higher order functions (i.e. passing functions into other functions). See
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
8. Dynamic typing obviates the need for templates. C++ being statically typed, needed to add templates to do some very basic things - but the implementation of templates in different C++ compilers is limited and/or buggy, so many professional C++ programmers are not allowed to use them at work when the code needs to run on different operating systems. By contrast, Lisp lists, hash tables, arrays, etc. can contain anything, or even a mix of different types.
9. Lisp has built-in bignum support. That means Lisp can work with numbers of any size without error. In C++ if you add 2 numbers together, maybe there is overflow and you are not warned.
10. Lisp allows you to create dynamically scoped variables and lexically scoped variables. C++ only allows lexically scoped variables. Sometimes dynamically scoped variables are really useful.
11. Lisp's conditions and restarts system is more flexible than C++ or Java's exceptions. Code in the caller for dealing with the problem can be run by the caller (as in C++), in the code throwing the exception, or anywhere in-between. See this Google tech talk for details:
http://video.google.com/videoplay?docid=448441135356213813&q=engedu
12. The object-oriented system in Lisp is much more powerful than in C++. You can create :before and :after methods that run (duh) before and after the inherited method. etc. etc. which is like Aspect-Oriented Programming (AOP). To add AOP to Java they had to write a pre-processor that could parse Java.
13. The Lisp scanner, parser and compiler are available in your program, so if you want to read input data in Lisp format, you just call the function READ (there are others for parsing strings, files, streams, etc.). I have looked around for a good C++ grammar for converting C++ text into a parse tree, but I have not found anything simple enough to use. I think every language should come with a library for parsing itself as part of the language standard. That makes it easy to write tools like javadoc.