7 ms·

From https://rubyllm.com/#have-great-conversations https://rubyllm.com/#have-great-conversations # Stream responses in real-time chat.ask "Tell me a st

From https://rubyllm.com/#have-great-conversations https://rubyllm.com/#have-great-conversations # Stream responses in real-time chat.ask "Tell me a story about a Ruby programmer" do |chunk| print chunk.content end

jupp0r 2y ago
This will synchronously block until ‘chat.ask’ returns though. Be prepared to be paying for the memory of your whole app tens/low hundreds of MB of memory being held alive doing nothing (other than handling new chunks) until whatever streaming API this is using under the hood is finished streaming.
- andrewmutz 2y ago
  Threads?
  - jupp0r 2y ago
    Rails is a hot ball of global mutable state. Good luck with threads.
    - andrewmutz 2y ago
      The default rails application server is puma and it uses threads
      - jupp0r 2y ago
        Yes, it does. Ruby has a global interpreter lock (GIL) that prevents multiple threads to be executed by the interpreter at the same time, so Puma does have threads, they just can’t run Ruby code at the same time. They can hide IO though.
        andrewmutz 2y ago
        The GIL is released during common IO operations like the HTTP requests that power LLM communication
        jupp0r 2y ago
        The Rails documentation has lots of info about this: https://guides.rubyonrails.org/tuning_performance_for_deployment.html https://guides.rubyonrails.org/tuning_performance_for_deploy... Concurrency support is missing from the language syntax and this particular library as a concept. This is by design, to not distract from beautiful code. Your request will make zero progress and take up memory while waiting for the LLM answer. Other threads might make progress on other requests, but in real world deployments this will be a handful (<10). This server will get 10s of requests per second when something written in JS or Go will get many 1000s. It’s amazing how the Ruby community argues against their own docs and doesn’t acknowledge the design choices their language creators have made.
kyledrake 2y ago
That looks good, I didn't see that earlier.

jupp0r 2y ago

This will synchronously block until ‘chat.ask’ returns though. Be prepared to be paying for the memory of your whole app tens/low hundreds of MB of memory being held alive doing nothing (other than handling new chunks) until whatever streaming API this is using under the hood is finished streaming.

andrewmutz 2y ago
Threads?
- jupp0r 2y ago
  Rails is a hot ball of global mutable state. Good luck with threads.
  - andrewmutz 2y ago
    The default rails application server is puma and it uses threads
    - jupp0r 2y ago
      Yes, it does. Ruby has a global interpreter lock (GIL) that prevents multiple threads to be executed by the interpreter at the same time, so Puma does have threads, they just can’t run Ruby code at the same time. They can hide IO though.
      - andrewmutz 2y ago
        The GIL is released during common IO operations like the HTTP requests that power LLM communication
        jupp0r 2y ago
        The Rails documentation has lots of info about this: https://guides.rubyonrails.org/tuning_performance_for_deployment.html https://guides.rubyonrails.org/tuning_performance_for_deploy... Concurrency support is missing from the language syntax and this particular library as a concept. This is by design, to not distract from beautiful code. Your request will make zero progress and take up memory while waiting for the LLM answer. Other threads might make progress on other requests, but in real world deployments this will be a handful (<10). This server will get 10s of requests per second when something written in JS or Go will get many 1000s. It’s amazing how the Ruby community argues against their own docs and doesn’t acknowledge the design choices their language creators have made.

kyledrake 2y ago

That looks good, I didn't see that earlier.