Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Cython as easy as Python

github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Making Cython as easy as Python

#41

Post by pdabbadabba »

chuckbot wrote: post #18
cbsmith wrote: post #16

"Runcython aims to simplify the process of using Cython without sacrificing scalability." I know this is being a semantic weenie, but I hate when people use scalability when they mean efficiency.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

> And I hate when people use efficiency when they mean speed.

Except they're usually right. "Efficiency" is not just a measure of algorithmic complexity. Something is more efficient if you are able to do more of a desired activity at the cost of fewer resources. The resource in question varies.

Yes, one often in computer science focuses on algorithmic complexity as the resource to be economized on. But time and power are also perfectly reasonable resources to have in mind. In fact, they are the resource that most audiences will naturally assume when they see the word "efficient" standing along, without further explanation.

I think GP is probably wrong to criticize as well -- making code more efficient [or, if you insist, fast] makes it easier to support more users that it could support otherwise. Is the ease with which a system can support an additional user not the very definition of the word "scalability"?

Of course, there are more powerful, and more specialized techniques for improving scalability, but that doesn't mean the author is wrong to suggest that speed improves scalability.

Re: Making Cython as easy as Python

#42

Post by halosghost »

This is great to see! I don't know if it was inspired by runhaskell, but it does appear to be similar. I have to say, this kind of tool is something I have come to feel is incredibly helpful and important for my dev workflow.

I spend most of my time developing in statically-typed, compiled-to-machine-code languages; obviously, one of the major advantages of more dynamic or interpreted languages is the ability to rapidly prototype. This type of tool allows me to quickly prototype something without losing all the power, control and other benefits of my languages of choice (in particular, Haskell these days).

Things like this make me more amenable to python by the day! Keep up the good work!

Re: Making Cython as easy as Python

#43

Post by pathsjs »

vegabook wrote: post #36
pathsjs wrote: post #8

Earlier quoted context omitted.

The problem with the Python ecosystem is that there exist a lot of libraries for scientific computation mostly incompatible with each other (blaze, numpy, numba, numexpr, dask...). Some of them try to reintroduce types in order to compile to native code, thereby losing the advantages of dynamic typing. In short, it is a mess, and everyone is trying to add on this because the existing ecosystem is big and the cost of…

I am intrigued by Nim. Does it have a REPL though? I think an official REPL (not a third party hack) is mandatory for scientific/numerical computing. Ocaml is the only compiled language I can think of which has a credible REPL, officially supported.

It currently does not have a REPL, and that is its main limitation right now. I think it is still suitable for more complex workflows where you would not do it in the REPL anyway - think training a large neural network. I hope something will come after 1.0 is out...

Re: Making Cython as easy as Python

#44

Post by sea6ear »

vegabook wrote: post #36
pathsjs wrote: post #8

Earlier quoted context omitted.

The problem with the Python ecosystem is that there exist a lot of libraries for scientific computation mostly incompatible with each other (blaze, numpy, numba, numexpr, dask...). Some of them try to reintroduce types in order to compile to native code, thereby losing the advantages of dynamic typing. In short, it is a mess, and everyone is trying to add on this because the existing ecosystem is big and the cost of…

I am intrigued by Nim. Does it have a REPL though? I think an official REPL (not a third party hack) is mandatory for scientific/numerical computing. Ocaml is the only compiled language I can think of which has a credible REPL, officially supported.

Some other (somewhat similar) compiled languages with official REPLs include:

  - F#
  - Scala
  - Haskell (repl is a little different compared to regular code)

Re: Making Cython as easy as Python

#45

Post by SixSigma »

vog wrote: post #2

This strategy should be more common! In the source tarball, there should be one main program which you start. The compiling should be an implementation detail of the main program. The same for web applications. I never liked the idea of reintroducing a separate build (concat/minify/compress) process whenever the sources change. Instead, the production mode should be as simple as the debug mode: When the main page is…

Better to use a file system based file change monitor and a makefile. Statting your file system for changes on every request adds to latency.

Re: Making Cython as easy as Python

#46

Post by [deleted] »

vog wrote: post #2

This strategy should be more common! In the source tarball, there should be one main program which you start. The compiling should be an implementation detail of the main program. The same for web applications. I never liked the idea of reintroducing a separate build (concat/minify/compress) process whenever the sources change. Instead, the production mode should be as simple as the debug mode: When the main page is…

[deleted]

Re: Making Cython as easy as Python

#48

Post by cbsmith »

chuckbot wrote: post #18
cbsmith wrote: post #16

"Runcython aims to simplify the process of using Cython without sacrificing scalability." I know this is being a semantic weenie, but I hate when people use scalability when they mean efficiency.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

I didn't mention complexity. I said efficiency.

Re: Making Cython as easy as Python

#49

Post by tadlan »

pathsjs wrote: post #20
shoyer wrote: post #14

Earlier quoted context omitted.

> The problem with the Python ecosystem is that there exist a lot of libraries for scientific computation mostly incompatible with each other (blaze, numpy, numba, numexpr, dask...). I actually disagree completely with your specific examples. These projects have mostly orthogonal goals and are actually quite compatible with each other -- they all speak NumPy arrays. In fact, three of them (Blaze, Numba and Dask) are…

I am not quite sure. Let me be more specific. Dask requires you to encode computations as a graph explicitly, essentially forcing you to write an AST manually. This means that you are sidestepping the normal language mechanisms to encode program flow, and doing so is essentially incompatible with anything else. Moreover, it does not use numpy arrays - it uses its own internal format that you can convert to a numpy ar…

Numba has loop fusion, runtime, and soon multithreading parallel vectorized functions. How is that c like?

Re: Making Cython as easy as Python

#50

Post by tadlan »

andreasvc wrote: post #28
zzleeper wrote: post #4

Earlier quoted context omitted.

I've seen some very impressive Julia libraries that perform almost at the level of C code, so I'm not sure if the gap that Julia needs to fill is that large. Also, a quick question: which one is preferred nowadays, Cython or Numba?

The gap that Julia has to fill in terms of library ecosystem is definitely large. Numba is specific to numeric/array-oriented code. Cython is general-purpose and can also be used to implement e.g. datastructures.

Numba has list, Named tuples, and is working on define your own jit classes.
Post reply on HN