3 ms·

I don't have it anymore, but it was something stupid like: import time start = time.time() list = [] for i in range(10000000): list.app

I don't have it anymore, but it was something stupid like: import time start = time.time() list = [] for i in range(10000000): list.append(i) sum = 0 for item in list: sum = sum + i print(time.time() - start) I am not superduper python expert, but I know that arrays/lists are the stupidest thing you can use so that's why I did stupid things with them. So before someone posts more optimized version the code was suppose to be shit since I assumed that the compiler would optimize it. I expected the binary to essentially be 1. start = time.time() 2. pre-populated list since it should be constant e.g. list = [1,2,3,...] or completely remove it since it is not used anywhere 3. pre-filled sum since it too is constant or same as above, removed since it is not used anywhere 4. getting second time.time() and printting the difference But there was no compilation time optimization. Granted this wasn't promised, but I just assumed it was in there since it is compiling.

emmelaich 5y ago
Maybe it was the size of the list. Have you tried xrange?
- nextlevelwizard 5y ago
  No and I won’t. There is no reason why the compiled code shouldn’t optimize both loops away since they do nothing. And in any case it should at least be faster if it doesn’t optimize the code away. And I am fairly sure xrange() is not in Python3
scbrg 5y ago
This is where Python being dynamic makes things like this hard. You have no idea what range does, as that name may point to any user defined object by the time the code is being executed. So no, I don't think it can "optimize both loops away". Come to think of it, you don't particularly know what sum = sum + i is doing either. There could be an __radd__ implementation in whatever your custom range spits out that indexes the WWW, renders a Mandelbrot or whatever. And yes, of course overloading range and __radd__ that way would also be considered stupid, but if the loops were optimized away, it wouldn't be a drop in replacement for Python.
- nextlevelwizard 5y ago
  the compiler can literally see that the `list` variable is only used to generate the `sum` variable and that the `sum` is never used. Since the `sum` is never accessed by anyone it can be optimized away and now since the only accesser of `list` is gone it too can be optimized away. Thus both loops most certainly CAN and SHOULD be removed from the final compiled code. Only reason Python can't do it is because it is not compiled, so it has to actually run through the code at runtime and see what happens. This is basic static analysis and any other compiler for any other language would do this. This is literally why we have keywords like `volatile` in compiled languages. I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. If we can't trust the functions in standard library then what is the benefit of compiling the code?
  - scbrg 5y ago
    > I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. I'm sure it knows what the standard range() function does. It just doesn't know that that's the standard range function you use when the code is being run. Any Python program is also a module. Any module can be imported. Any imported module's global namespace is unknown at the time you write the program. Imagine I have your code, above, in a module called nextlevelwizard, and I write my own little progam as this: import builtins def myrange(n): cur = 0 while cur < n: print(cur) yield cur cur += 1 builtins.range = myrange import nextlevelwizard Now, suddenly, your loop has a side effect. Side effects cannot be "optimized away" - the whole point of programs are generally to produce some sort of side effect! This is a silly example, of course, but the dynamic nature of Python means that it really is very hard to skip steps you assume are irrelevant.
    - nextlevelwizard 5y ago
      Expect the compiler should import whatever module you are using and analyze that module's code just like in any compiled language. Even in the example you gave it could replace the loop with a bunch of print calls since the result (yields) do nothing. Compilers are hard.

emmelaich 5y ago

Maybe it was the size of the list. Have you tried xrange?

nextlevelwizard 5y ago
No and I won’t. There is no reason why the compiled code shouldn’t optimize both loops away since they do nothing. And in any case it should at least be faster if it doesn’t optimize the code away. And I am fairly sure xrange() is not in Python3

scbrg 5y ago

This is where Python being dynamic makes things like this hard. You have no idea what range does, as that name may point to any user defined object by the time the code is being executed. So no, I don't think it can "optimize both loops away". Come to think of it, you don't particularly know what sum = sum + i is doing either. There could be an __radd__ implementation in whatever your custom range spits out that indexes the WWW, renders a Mandelbrot or whatever. And yes, of course overloading range and __radd__ that way would also be considered stupid, but if the loops were optimized away, it wouldn't be a drop in replacement for Python.

nextlevelwizard 5y ago
the compiler can literally see that the `list` variable is only used to generate the `sum` variable and that the `sum` is never used. Since the `sum` is never accessed by anyone it can be optimized away and now since the only accesser of `list` is gone it too can be optimized away. Thus both loops most certainly CAN and SHOULD be removed from the final compiled code. Only reason Python can't do it is because it is not compiled, so it has to actually run through the code at runtime and see what happens. This is basic static analysis and any other compiler for any other language would do this. This is literally why we have keywords like `volatile` in compiled languages. I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. If we can't trust the functions in standard library then what is the benefit of compiling the code?
- scbrg 5y ago
  > I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. I'm sure it knows what the standard range() function does. It just doesn't know that that's the standard range function you use when the code is being run. Any Python program is also a module. Any module can be imported. Any imported module's global namespace is unknown at the time you write the program. Imagine I have your code, above, in a module called nextlevelwizard, and I write my own little progam as this: import builtins def myrange(n): cur = 0 while cur < n: print(cur) yield cur cur += 1 builtins.range = myrange import nextlevelwizard Now, suddenly, your loop has a side effect. Side effects cannot be "optimized away" - the whole point of programs are generally to produce some sort of side effect! This is a silly example, of course, but the dynamic nature of Python means that it really is very hard to skip steps you assume are irrelevant.
  - nextlevelwizard 5y ago
    Expect the compiler should import whatever module you are using and analyze that module's code just like in any compiled language. Even in the example you gave it could replace the loop with a bunch of print calls since the result (yields) do nothing. Compilers are hard.