I just gave this a play since I was really curious what it could do. But it seems like of your python module has imports for other python modules, they get transpiled into Go import statements that look at the grumpy stdlib location. Does anyone have any information on the extend of the support, besides the documented caveats?
>From what I gather, it seems to target the use case of single file executable scripts, in pure python, with only dependencies on the python stdlib or the Go stdlib, and use multithreading as a focus (in order for it to realize the performance benefits). Does that seem correct? If so, can anyone explain a real or hypothetical example of where grumpy is most useful? I can't say I have anything that fits this use case. But I suppose google/YouTube team have a bunch of these concurrent data crunching scripts. Justin On Thu, Jan 5, 2017, 10:54 AM andrey mirtchovski <mirtchov...@gmail.com> wrote: > > It’s also about 2x slower than the original Python. All of this > indirection is necessary to preserve the dynamic semantics of Python. > Basically it’s taking the calls into the runtime that a Python interpreter > would make, and writing them out one after another. > > this single-thread slowdown does appear on the performance graph > published in the article. python historically has had significant > effort thrown behind single-thread/process performance. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
