← Back to context

Comment by bawolff

6 months ago

If we are talking 1000x more latency, that is a pretty hard sell.

Something that normally takes 30 seconds now takes over 8 hours.

Its like, python can be 400 times slower than C++, but people still use it.

  • If Python devs/users had to actually use all pure Python libraries, no C bindings or Rust bindings, no RPC to binaries written in faster languages, it would get dropped for a ton of use cases, absolutely including its most prominent ones (machine learning, bioinformatics, numeric analysis, etc.).

    • It would probably especially include those before most others. The best thing about Python IMO is the FFI and the ecosystem built around it.

  • Yeah, because people use python when it doesn't matter and c++ when it does (including implicitly by calling modules that are backed by c implementations).

    That is not an option with FHE. You have to go all in.

    • Yes but with FHE it also depends on the use-case and how valuable the output is and who is processing it and decrypting the final output.

      There are plenty of viable schemes like proxy re-encryption, where you operate on a symmetric key and not on a large blob of encrypted data.

      Or financial applications where you are operating on a small set of integers, the speed is not an issue and the output is valuable enough to make it worth it.

      It only becomes a problem when operating FHE on a large encrypted dataset to extract encrypted information. The data extracted will need to offset the costs. As long as companies don't care about privacy, this use-case is non-existent so its not a problem that its slow.

      For military operations on the other hand, it might be worth the wait to run a long running process

  • For compute, which is a small part of things computers do. Many things are I/O and network bound.

    I’m not at all a fan of Python, but perf is the least of my concerns with it.