Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Skyrunner]

This is just a guess, but I think it's very possible that that's a design issue rather than something inherent to Python. Have you tried profiling your program to find the bottlenecks?

[Arx]

It's very definitely inherent to Python. My mother was at one stage working through the Project Euler problems, and a lot of them she was struggling with because Python wasn't solving them in under a minute. It's optimisable, but you have to optimise C and C-based languages a lot less.

[Skyrunner]

How do you know without seeing Hat's code, though? For all you know, it might be blocking somewhere, or some incorrect design like (wild example) iterating over an unsorted list to find stuff.

[Arx]

Fair enough. Performance in Python does tend to brick-wall pretty easily, though.

[miauw62]

Python is interpreted, isn't an interpreted language almost always slower than a compiled language? (Especially if the compilers are as advanced as those of C and C++ are)

[Skyrunner]

Yes, but it's also possible that merely changing a design will speed it up by orders of magnitude. Rewriting things in a different language is usually a last-resort.

[Reelya]

Not when you're talking about interpreted languages. If it's some toy problem, sure, but if you want it to scale you need to run on bare metal code eventually.

[Uristides]

The problem with passing a char[4][8] as a char ** is that a two-dimensional static-sized array is not implemented as a (char *)[], with pointers for each actual string. it's actually implemented as a single char[32] and the compiler converts all your indexes to that. So the "under the hood" implementation is actually different to manually making a (char *)[4]  then assigning each (char *) to a memory location containing a string. This version shows how it works (tested with VC++ 2012).
[...]

orz, sorry for that then ed boy. Thanks for explaining where I went wrong Reelya.

[Skyrunner]

Not when you're talking about interpreted languages. If it's some toy problem, sure, but if you want it to scale you need to run on bare metal code eventually.

While I disagree, I don't think this discussion can end without an "Agree to disagree" sort of deal...

[Reelya]

It's not a matter of opinion though. Benchmarks of the best-known Python implementation are much slower than the best-known c++ ones:

http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=python3&lang2=gpp&data=u32q

For some algorithms, the fastest-known Python implementation is ~100 times slower than c++. So in other words, you don't use Python for anything that needs CPU cycles. Stuff that doesn't do any processing and has plenty of idle time won't hurt to run in Python though.

[Skyrunner]

But I'm not comparing Python to C++.

What I (meant to) said is

It may be possible that algorithm optimizations will be as good as switching to C++, relatively.

Consider:

Python/Bad algorithm, time 10000
Python/Optimizaed algorithm, time 1000
C++/bad algorithm, time 1000
C++/good algorithm, time 100

I don't doubt that C++ is faster than Python, but I'm saying that you should consider optimizing your code theoretically before switching to C++. It's also less work than rewriting a system in a new language.

edit: Maybe the optimized algorithm is only x2 faster. But there's still the relative productivity of fixing an algorithm compared to rewriting your entire code in another language. :I

[Reelya]

But optimizing something twice is wasted effort. Optimizations that work well in Python will have to be undone to make it a good C++ program. It makes a lot more sense to port a non-optimized easy to understand version then optimize it in c++. If you're after maximum performance with minimal work, this is the way to do it. And a program that computes astronomical simulation data - you can always find a use for higher performance.

[alexandertnt]

It may be that the code in question is not efficient. For example, it could be some horrible brute-force pathfinding algorithm that could simply be replaced with a Python A* implementation. Rewriting the brute-force code in C++ will still be slower than the A* python code for any significant sized problem, and it is possible that the size of the problem is still sufficiently small that it can be solved by the Python A* code fast enough to be acceptable. (I think that Skyrunner was referring to something like this, optimising the algorithm, not the code (I think?)).

(It is EnigmaticHat and their complete-mystery game we are talking about, right?)

[Skyrunner]

Yes, that was what I meant to say My lack of communication skills is going to bite me later..

[EnigmaticHat]

I wanted to learn C++ anyway guys, this was just a convenient excuse.  No need to have an argument about it.

Anyway, I'm working on two games, one of which is my main project that I'm fairly certain can be made exclusively in Python (it currently runs decently on my fairly shitty laptop, and tech is only going to get better over time).  It started in the Roguelike Development Megathread but now is more of a TBS game than a roguelike.  The other one, which is more me dicking around to see what I can do than a serious project I intend to finish anytime soon, involves generating terrain maps for alien planets:

Spoiler: like this one (click to show/hide)

This one took only about 2 seconds to generate, most of which is defining the damn province borders (which I have still not perfected, you'll notice a bunch of tiny provinces in other provinces).

The problem is two-fold.  First, this map is supposed to be one of many across a larger galaxy, and secondly, the game draws each map pixel by pixel so that I can do things like different mapmodes and highlighting provinces.

Now, do you know how many frames per second you get when you ask python to generate arrays with tens of thousands of entries and then draw a map based on them pixel by pixel?  Less than one.  Not good.