Lets turn it around: Is there an example where speed and scalability are different?
Well, actually there are a lot of such examples. For instance consider the idea of caching data in shared memory. This is very fast. But the second you've done it with something that has to remain consistent across requests, you can't have 2 webservers any more. You're fast, but can't scale. (Don't laugh, I know of a number of websites that made this mistake at some point in their history. http://www.kuro5hin.org/ and http://slashdot.org/ are two good examples.)
Concurrency and locking issues provide lots more examples. Having fewer locks over large things is much faster than having lots of little locks. But you get less concurrency. For a toy website, MySQL with MyISAM is fine - lock whole tables. Row level locking as done in Oracle, PostgreSQL or MySQL with INNODB is much slower, but it scales.
I know that you think that this is "just another type of speed", but it really isn't. If a critical lock somewhere deep in a database is operating at 95% of maximum capacity, there is basically no visible effect on performance from the lock contention. At 101% of capacity, your database falls over. The characteristic failure mode isn't that you get slower as the request rate increases. It is that you max out your capacity and then crash if you try to go faster. I've been there, and it isn't fun.
Now with all of this said, there is a large, obvious, connection between speed and scalability. Suppose that you are comparing 2 languages, one of which runs twice as fast as the other. You can scale the slow one - just run twice as many boxes. But now you need twice as many database connections. Holding those connections open consumes resources, so you need a bigger database. And so on.
Therefore the faster environment can frequently push off the point at which you start encountering other scalability issues. But speed and scalability are not at all the same thing.
Well, actually there are a lot of such examples. For instance consider the idea of caching data in shared memory. This is very fast. But the second you've done it with something that has to remain consistent across requests, you can't have 2 webservers any more. You're fast, but can't scale. (Don't laugh, I know of a number of websites that made this mistake at some point in their history. http://www.kuro5hin.org/ and http://slashdot.org/ are two good examples.)
Concurrency and locking issues provide lots more examples. Having fewer locks over large things is much faster than having lots of little locks. But you get less concurrency. For a toy website, MySQL with MyISAM is fine - lock whole tables. Row level locking as done in Oracle, PostgreSQL or MySQL with INNODB is much slower, but it scales.
I know that you think that this is "just another type of speed", but it really isn't. If a critical lock somewhere deep in a database is operating at 95% of maximum capacity, there is basically no visible effect on performance from the lock contention. At 101% of capacity, your database falls over. The characteristic failure mode isn't that you get slower as the request rate increases. It is that you max out your capacity and then crash if you try to go faster. I've been there, and it isn't fun.
Now with all of this said, there is a large, obvious, connection between speed and scalability. Suppose that you are comparing 2 languages, one of which runs twice as fast as the other. You can scale the slow one - just run twice as many boxes. But now you need twice as many database connections. Holding those connections open consumes resources, so you need a bigger database. And so on.
Therefore the faster environment can frequently push off the point at which you start encountering other scalability issues. But speed and scalability are not at all the same thing.