claird at starbase.neosoft.com (Cameron Laird) writes: > Yes, I get a factor of between 100 and 300 for empty loops, but, as > soon as they do anything useful, the multiple drops down to a range > more like ten--definitely not a hundred. Are you telling me that you can implement an FFT in Python (without using any C extensions) that runs within an order of magnitude of the speed that an optimized C implementation would? I wouldn't be too surprised if you could do one that runs 50 times slower, but I *would* be highly surprised if you could get it down to 10. Please don't make too much out of my statements -- I'm quite aware that for many things the performance limitations are irrelevant, and that when they are not that they can often be eliminated by using C extensions or clever use of Python's built-in higher level data types. The dream of the Self people, however, is that someday soon everything can be done in-language in a very high-level, orthogonal, and dynamic language without ever paying much of a performance cost. |>oug
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4