4 ms·

The C-compatbility story works both ways. I usually roll my eyes when people talk about making dynamic lanuages fast -- what's the point? In those cases where

The C-compatbility story works both ways. I usually roll my eyes when people talk about making dynamic lanuages fast -- what's the point? In those cases where speed matters - use static language. As a result there is little incentive to use something like PyPy (although PyPy does have other nice features in addition to raw speed). But on the web there is a point. Unless you can use HTML alone, you have to use JavaScript -- and you can't just plug in a module that you wrote in C.

cmdrfred 10y ago
Can't you? Maybe not today, but soon. https://webassembly.github.io/ https://webassembly.github.io/
static_noise 10y ago
It's about managing your resources. You can simply buy the fastest processor for cheap money. You can buy systems with many cores or even build a cluster for considerable money. But you can not buy time. Developing python applications in many cases is much quicker than developing comparable applications in C++, C or Assembler. Therefore it makes a lot of sense for many companies to choose tools with quick development time to get the product running and care for performance later. Since there may be so much code be written in python, it cannot simply be converted into a faster language since most critical parts are already accelerated using the proper libraries provided by the language ecosystem. Porting a complex application to another language in many cases is a really hard problem and might even not be possible to be done in smaller steps. Therefore we need every bit of performance we can squeeze out of python. The whole world will gain from that. If we manage great strides like JavaScript it would be glorious!
- cmdrfred 10y ago
  Also soon enough (if we aren't there already), fast hardware will be so cheap that the speed of execution at least for end user applications will rarely be a factor. Sure that database application you wrote in C is measurably faster, but can a human being detect the difference? More and more the response will be no.
  - weberc2 10y ago
    In the last 5 years, clock speeds have stagnated. Hardware innovation has revolved around increasing cores and improving power efficiency. Unfortunately, Python and most other dynamic languages are poorly suited to take advantage of parallelism, so your C database can only get faster, but your Python database will not.
    - pcwalton 10y ago
      Honestly, the vast majority of languages are bad at parallelism. Dynamic vs. static doesn't have much to do with it. Task-parallel multicore (like goroutines and Web Workers and the like give you) is only a small fraction of what it means to "take advantage of parallelism", and if you're only using that (as opposed to SIMD, GPUs, concurrent data structures, work-stealing, etc.) then you are likely to see disappointing speedups in practice. This is especially true in the last 5 years, which contrary to your post has seen a shift away from multicore task-parallel hardware (core counts are not increasing) and toward data-parallel hardware (wider SIMD lanes, better on-board GPUs, APU architectures, etc.)
      - weberc2 10y ago
        You're missing the point. There's "suboptimal parallelism", and then there's "no parallelism". Python and many other dynamic languages fall into the latter category.
        BuckRogers 10y ago
        I'd call Python optimal parallelism. I prefer the scaling by instance method of Node and Python over the old ways- writing multithreaded Java apps. People can knock themselves out writing stuff like that if they want to. But my purposes have been well-served scaling by spinning up instances per-core. For me, explicit pthreading should never be done except with systems software. In which case you're going to be using a systems language like C, C++ or Rust anyway. Not the oddball middletier stuff that isn't high or low level like Go, Java and C#.
- weberc2 10y ago
  Assembler isn't statically typed, and C and C++ are particularly bad examples of productive static languages. Go is a much better example, but it disproves your thesis that dynamic languages are more productive than static languages (I have 6 years of Python experience and 3 years of Go experience, and Go is at least as easy as Python for small, single-threaded code bases and it scales much better with team size, code volume, and thread count).
  - BuckRogers 10y ago
    Yeah, but Go is 20-50% less productive, depending on who you ask. From my experience I'd say it's at least 25% less productive than Python. Not horrible but I think 25% is a minimum value and a quarter of your time adds up. I don't think it's worth the trade off once you consider every language has its warts, Go has its own problems.
    - weberc2 10y ago
      That's not been my experience, and I'm a Python developer by trade. Python simply doesn't scale well with code size, team size, performance requirements, etc. Go's biggest problem is a lack of generics, which means that in some cases, you have to fall back to duck typing. So the worst case is no worse than Python's best case.
      - BuckRogers 10y ago
        My largest Go project has been 40KLOC, after which I felt that Python would've been at least 25% more productive. The next-step isn't Go. It's Elixir. Or Rust if you need a systems language.
weberc2 10y ago
By that logic, why optimize anything? Just use the thing that's out there that's already faster. Clearly some people think there's a benefit to dynamic languages (I'm not one of them), and they'd like to preserve that benefit while minimizing the performance impact.
Animats 10y ago
Python connecting to C is used mostly to attach to large C objects that do something complicated, like OpenSSL. Math inner loop intensive things like numpy could potentially be optimized up to C speed by PyPy. (At least if you could create an array of a fixed type in Python.)

cmdrfred 10y ago

Can't you? Maybe not today, but soon. https://webassembly.github.io/ https://webassembly.github.io/

static_noise 10y ago

It's about managing your resources. You can simply buy the fastest processor for cheap money. You can buy systems with many cores or even build a cluster for considerable money. But you can not buy time. Developing python applications in many cases is much quicker than developing comparable applications in C++, C or Assembler. Therefore it makes a lot of sense for many companies to choose tools with quick development time to get the product running and care for performance later. Since there may be so much code be written in python, it cannot simply be converted into a faster language since most critical parts are already accelerated using the proper libraries provided by the language ecosystem. Porting a complex application to another language in many cases is a really hard problem and might even not be possible to be done in smaller steps. Therefore we need every bit of performance we can squeeze out of python. The whole world will gain from that. If we manage great strides like JavaScript it would be glorious!

cmdrfred 10y ago
Also soon enough (if we aren't there already), fast hardware will be so cheap that the speed of execution at least for end user applications will rarely be a factor. Sure that database application you wrote in C is measurably faster, but can a human being detect the difference? More and more the response will be no.
- weberc2 10y ago
  In the last 5 years, clock speeds have stagnated. Hardware innovation has revolved around increasing cores and improving power efficiency. Unfortunately, Python and most other dynamic languages are poorly suited to take advantage of parallelism, so your C database can only get faster, but your Python database will not.
  - pcwalton 10y ago
    Honestly, the vast majority of languages are bad at parallelism. Dynamic vs. static doesn't have much to do with it. Task-parallel multicore (like goroutines and Web Workers and the like give you) is only a small fraction of what it means to "take advantage of parallelism", and if you're only using that (as opposed to SIMD, GPUs, concurrent data structures, work-stealing, etc.) then you are likely to see disappointing speedups in practice. This is especially true in the last 5 years, which contrary to your post has seen a shift away from multicore task-parallel hardware (core counts are not increasing) and toward data-parallel hardware (wider SIMD lanes, better on-board GPUs, APU architectures, etc.)
    - weberc2 10y ago
      You're missing the point. There's "suboptimal parallelism", and then there's "no parallelism". Python and many other dynamic languages fall into the latter category.
      - BuckRogers 10y ago
        I'd call Python optimal parallelism. I prefer the scaling by instance method of Node and Python over the old ways- writing multithreaded Java apps. People can knock themselves out writing stuff like that if they want to. But my purposes have been well-served scaling by spinning up instances per-core. For me, explicit pthreading should never be done except with systems software. In which case you're going to be using a systems language like C, C++ or Rust anyway. Not the oddball middletier stuff that isn't high or low level like Go, Java and C#.
weberc2 10y ago
Assembler isn't statically typed, and C and C++ are particularly bad examples of productive static languages. Go is a much better example, but it disproves your thesis that dynamic languages are more productive than static languages (I have 6 years of Python experience and 3 years of Go experience, and Go is at least as easy as Python for small, single-threaded code bases and it scales much better with team size, code volume, and thread count).
- BuckRogers 10y ago
  Yeah, but Go is 20-50% less productive, depending on who you ask. From my experience I'd say it's at least 25% less productive than Python. Not horrible but I think 25% is a minimum value and a quarter of your time adds up. I don't think it's worth the trade off once you consider every language has its warts, Go has its own problems.
  - weberc2 10y ago
    That's not been my experience, and I'm a Python developer by trade. Python simply doesn't scale well with code size, team size, performance requirements, etc. Go's biggest problem is a lack of generics, which means that in some cases, you have to fall back to duck typing. So the worst case is no worse than Python's best case.
    - BuckRogers 10y ago
      My largest Go project has been 40KLOC, after which I felt that Python would've been at least 25% more productive. The next-step isn't Go. It's Elixir. Or Rust if you need a systems language.

weberc2 10y ago

By that logic, why optimize anything? Just use the thing that's out there that's already faster. Clearly some people think there's a benefit to dynamic languages (I'm not one of them), and they'd like to preserve that benefit while minimizing the performance impact.

Animats 10y ago

Python connecting to C is used mostly to attach to large C objects that do something complicated, like OpenSSL. Math inner loop intensive things like numpy could potentially be optimized up to C speed by PyPy. (At least if you could create an array of a fixed type in Python.)