open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: ing Lag: Module Lag - Why Not All Bugfixes Are A Good
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 3 4 5 6 [7]

Author Topic

Ban Doga
Posted - 2010.09.03 18:49:00 - [181]
 

Originally by: CCP Veritas
Originally by: Yehat Quan
<stuff>


Hi there.

I at first felt like going point by point with you, but I think there's a deeper point I can touch on that covers most everything.

I've been a professional C/C++ programmer for the better part of a decade, and was raised on it early. I know the performance difference between Python and C. I know, deeply and exactly, why that difference exists.

I've also done game development in C++, and am very familiar with the maintenance nightmare that such a codebase can become after many years of disjoint development by a shifting team with shifting focus. The tradeoff between speed of execution and ease of maintenance and extension is not as simple as you make it out to be.

There's a time for reworking code from a higher level language to a lower level language. It used to be dropping into ASM from C, now it's droping into C from something higher level. That time has always been after you've cut away the unnecessary computation and poor design models. From what I've seen so far with Eve, we're not at that point yet. If we had one little tight loop that was consuming most of the time, you'd have to hold me back from pulling it over to C-side. That's simply not the situation we're in, however.


Yes, premature optimization is the root of all evil.
But then someone might come along and ask if optimizing years old code is still premature.

But I wanted to ask something else:
Did you see the GIL talk at the PyCon 2010?

I was really shocked to see 50 million decrements of a numeric variable took over 5 seconds.
I did the same in Java (still an interpreted language, although with a compilation step before execution and optimization while running) on my notebook (pretty comparable to the MacBook used in the talk) and it completed in less than 5 milliseconds. So roughly 1000 times as fast.

Is Stackless Python just as slow as that?

And yes, that's not a benchmark for real-world performance at all, but factor 1000 is just too much to ignore IMHO.

Yehat Quan
Gallente
Posted - 2010.09.04 13:19:00 - [182]
 

@Ban Doga: the reason Java is that much faster in that test is because the JIT compiles the loop into native machine code. Why thatīs faster, see below...

@CCP Veritas:
Originally by: CCP Veritas

I've been a professional C/C++ programmer for the better part of a decade, and was raised on it early. I know the performance difference between Python and C. I know, deeply and exactly, why that difference exists.



Then you are aware of the fact that depending on how badly the interpreter is able to optimize, you will have a function call for every mathematical operation that SHOULD have been a CPU instruction, right? In best case, that is the difference between a CPU register access and main memory access. In worst case you have to insert the overhead for pulling some data from a data segment, then jumping into the code area that implements math, and then pushing back the data into main memory, for every single operator. In 1996, on a 80486 that needed 500 cycles to multiply, with an ISA bus, the difference was at least 4x. With current CPUs and all their caching, pipelining and predictive branching crap this can easily account for the factor 200-1000 people see.

I just sure as hell hope you donīt have a database access somewhere in the module loop ;-)

Originally by: CCP Veritas

I've also done game development in C++, and am very familiar with the maintenance nightmare that such a codebase can become after many years of disjoint development by a shifting team with shifting focus. The tradeoff between speed of execution and ease of maintenance and extension is not as simple as you make it out to be.



You are right, there is probably no way to emulate stackless features in C++.
However, I would be interested how much you actually use the stackless features, and how large the memory (or anything, for that matter) savings are. Because having a maximum of 1500 concurrent users on a server really does not showcase any performance advantages you might have gained by using Stackless, and if you donīt need it, PyPy JIT might save you.

Also, isn`t using a model where you have to control yielding by hand and fine-tune the yielding behaviour empirically much closer to using Assembler then to a high-level language that supposedly is less work for the programmer?

Originally by: CCP Veritas

There's a time for reworking code from a higher level language to a lower level language. It used to be dropping into ASM from C, now it's droping into C from something higher level.



To be honest -- and I know there is a huge community ready to stone me to death after I say that -- I have trouble regarding Python as a higher-level language than C++.

- You can only find type errors by running your program. You know what other language has this "feature"? Assembler. It just doesn't fail quite as gracefully.

- I can't think of anything short of the stackless feature that you can do in Python that you can't do with a library like Boost in C++. Including garbage-collection. So what exactly makes python high-level, the pseudocode-like syntax, or the interactive environment?

If it is the latter, there are enough C++ IDEs nowadays that can tell you that you mistyped the variable name or you're doing an assignment with two different types that you don't really need a crummy interactive command-line... Sure, exploratory programming is great, especially with things that have too little documentation to be useful otherwise, but we are talking a serious big-a** "for money" game development project -- don't you guys write documentation for your code?

Python was invented in 1990, when C++ compilers were slow, lack of compilation seemed like a good idea, and the CPU time for a MUL instruction was comparable to a function call. Nowadays, for any project that is not monolytic (like using a cr.pton of templates all stuffed into header files) AND enormously large, recompilation times are negligible -- run times just aren't.

Ban Doga
Posted - 2010.09.04 15:48:00 - [183]
 

Originally by: Yehat Quan
@Ban Doga: the reason Java is that much faster in that test is because the JIT compiles the loop into native machine code. Why thatīs faster, see below...



Well that surely helps a lot, but even when forcing the JVM into pure interpreted mode (-Xint) it still completes in under 0.5 seconds.

Liang Nuren
Posted - 2010.09.15 16:58:00 - [184]
 

Originally by: Yehat Quan
...


So I was recently working on some Project Euler problems, and I was browsing the forums after completing one of them. I figured I'd see what kind of performance I was missing... turns out lots of people had their C solutions completing on the magnitude of 12-16 hours. Mine, written in Python, ran in four seconds for much much larger values of N.

Algorithm is everything.

-Liang


Pages: 1 2 3 4 5 6 [7]

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only