1 |
Am 10.01.2014 14:05, schrieb Igor: |
2 |
> Hello Patrick, |
3 |
> |
4 |
> Friday, January 10, 2014, 4:39:59 PM, you wrote: |
5 |
> |
6 |
>> No, Python isn't slow. |
7 |
>> Bad code is bad. You can write bad code in any language. |
8 |
> |
9 |
> Are you sure? Take a look here: |
10 |
> |
11 |
> http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=python3&lang2=gpp&data=u32q |
12 |
> |
13 |
> of course these stats are all so fake, and you may not belive them. |
14 |
> |
15 |
> I've been using C/C++ since school it's fast, even bad code is working fast. |
16 |
> |
17 |
> I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms |
18 |
|
19 |
You do realize, that we are not doing math (read: number crunching) here? |
20 |
|
21 |
And again: What is needed is streamlining the algorithms (discussion on |
22 |
that already started as far as I could notice). An algorithm in O(n³) is |
23 |
always¹ worse than O(n). The constant factor added by the language |
24 |
difference is of no interest. |
25 |
|
26 |
> It's crazy that you're even trying to state it. Take a look at what |
27 |
> Python is producing in disasm and then look at it in G++. |
28 |
|
29 |
For a larger project, it often is more important to have readable and |
30 |
maintable code opposed to getting the last bit of performance. And |
31 |
Python is _far_ more readable and concise than C or C++ (imho). Due to |
32 |
lack of typechecking, I'm not so sure when it comes to maintainability |
33 |
though (there are test suites of course). |
34 |
|
35 |
- René |
36 |
|
37 |
¹ For a large enough n. |