D as a Better C

Re:D as a Better C by messe on Wednesday August 23, 2017 @12:31PM (#15082876)

Python is interpreted, C and C++ are compiled. They target different niches. Python is more focused on ease of use than performance.

Usually when writing scientific code in Python you're going to want to at the very least use numpy. It wraps various C functions for many time consuming tasks.

To get the most out of numpy you're going to have to vectorize you're code, as python's looping constructs are notoriously slow. Instead of writing something like

    for i in range(0, len(v)):
        v[i] = w[i]**2 + w[i]

You'd write something more along the lines of

    v[:] = w**2 + w

[ Parent | on HN ]

Re:D as a Better C by pmoriarty on Wednesday August 23, 2017 @01:03PM (#15083176)

It is up to the implementation of a language whether that language is compiled or interpreted. For instance, there are C interpreters and Python compilers. Neither language is limited to being one or the other. It's just that usually people use C compilers and Python interpreters, but there's nothing inherent in those languages that limits them to those. It's all up to the implementation.

[ Parent | on HN ]

Re:D as a Better C by kibwen on Wednesday August 23, 2017 @01:28PM (#15083373)

This is true, but not always in a useful sense. There exist language features whose semantics are expressly dynamic, and if your language includes those features it will frustrate static compilation. For example, if your language includes `eval` (as Python does), then any precompiled binary would also need to include a complete Python interpreter. This is why efforts to compile Python (and other languages that are traditionally interpreted) often omit such features, and why languages that intend to be compiled tend to forgo them in the first place.

[ Parent | on HN ]

Re:D as a Better C by pjmlp on Wednesday August 23, 2017 @02:47PM (#15084046)

Which is why for me the best way is to be able to choose between JIT/AOT deployments, instead of a plain interpreter.

Maybe one day PyPy will finally become the default option.

[ Parent | on HN ]

Re:D as a Better C by messe on Wednesday August 23, 2017 @01:34PM (#15083427)

> It is up to the implementation of a language whether that language is compiled or interpreted.

While that's perfectly true, it didn't seem necessary to go into it.

[ Parent | on HN ]

Re:D as a Better C by no_wizard on Wednesday August 23, 2017 @01:48PM (#15083548)

This seems like it would be great for a list comprehension.

I believe the main appeal to using comprehensions is that it speeds up the iteration process at run time so wouldn't a list comprehension be just as useful here if not more so then?.

You could also use the functools and itertools library for really fast iterations, possibly, depending on what it is you are trying to achieve.

If you are specifically talking lists (arrays) why not use Deque? It is set matched and python saves run time by automatically knowing each value will be a finite forward sequence

[ Parent | on HN ]

Re:D as a Better C by innocenat on Wednesday August 23, 2017 @02:15PM (#15083765)

But would that be faster than numpy? numpy in typical setup would use SIMD or other math kernel (mkl, blas, etc).

[ Parent | on HN ]

Re:D as a Better C by lima on Wednesday August 23, 2017 @02:39PM (#15083964)

It wouldn't.

Pure Python code is never going to out-perform a low-level optimized C library. Especially not when comparing iterative vs vectorized code.

[ Parent | on HN ]

Re:D as a Better C by no_wizard on Wednesday August 23, 2017 @06:05PM (#15085624)

Oh no of course not. Sorry I must have missed something here. I was speaking specifically of iterating over/with values. Numpy is optimized for this kind of thing. Though you can help yourself out and make sure you python code is also optimized by using comprehensions and itertools I would suppose

[ Parent | on HN ]