4 ms·
They said they work on machine learning and data engineering, which means they are very likely using very optimized native code libraries with Python bindings.
by dralley 6y ago
They said they work on machine learning and data engineering, which means they are very likely using very optimized native code libraries with Python bindings. Go's FFI story has a lot of overhead, so it's actually not inconceivable that Python could be faster for their specific needs.
- throwaway894345 6y agoHis first paragraph suggests he was making a general comment, but I agree that if you’re doing very specific things like calling into optimized libraries then its not much of a problem; however, if you have to call into those libraries O(n) or worse, which is often the case, then you’ll very likely lose all or most of the performance you gained due to marshaling costs (not sure how these marshaling costs stack up to Go FFI, but in ago you would just write optimized Go in this situation—e.g., move allocations out of the hot path, make sure critical paths are inlined, etc—which isn’t an option available to Python developers). But yes, if your use case is calling into an optimized C library O(1) (and you have a high degree of confidence that it will never be worse than that) then Python will work fine (or rather, you won’t be fighting with performance, but you’ll still have to deal with package management, poor documentation, huge binaries, etc).