mdedetrich commented on PR #2156: URL: https://github.com/apache/pekko/pull/2156#issuecomment-3261920824
> 1. Is that true? then why it's not the 1st of the JVM in [2024-04-13 i9-13900KF (32) @ 5.500GHz, 64G RAM LesnyRumcajs/grpc_bench#441](https://github.com/LesnyRumcajs/grpc_bench/discussions/441) ? I don't know, I would have to look into it. I am saying that the co-routine compiler transformations are well known and understood and they just translate to raw JVM bytecode statements `jsr`/`goto`, you can't really beat that. Even though its not really used, scala had its own coroutine plugin as part of the compiler and it also did the same. As you said, coroutines are slower if they have to interact with blocking Java code and kotlin-grpc might be doing that. On the other hand, if you have a purely async non blocking implementation like akka/pekko then it should be as fast, if not faster and actually your benchmarks show that akka/pekko grpc is just as fast as java vertx and the fact that java vertx is not meaningfully faster than akka/pekko grpc actually shows how Loom is not that fast as Loom has full runtime support in the JVM where as pekko/akka does not, as it implements actors as a library. If JVM implemented actors natively, then pekko/actor would be much faster, moerso than loom. There are lots of tricks that you can use to make actors very fast which Erlang does but cannot be done with akka/pekko as we don't have full JVM support (we however might be able to make actors even faster with newer versions of JVM as they are giving us more tools). > 2. it will require a Dispatchers.io to run the blocking code, let kotlin to handle old java file and Socket, its slow. Sure if you need to interact with old blocking Java code it will be slower, the solution here is to not write/use blocking code. Thats why akka/pekko itself was written completely with async in mind and also why its as fast as java vertx 😉 > 3. what's the color your function problem is a no for me; that's why Loom is much better than kotlin one. True, I am just saying there are tradeoffs. If you don't want to deal with the color function problem then you can use loom, I am just saying not everyone is in that boat. > 4. Akka/Pekko will be slow if it's been blocked than loom, the only way is running the dispatcher with Loom. > > We are using Kotlin at work, some part of our server and our ios and android sharing the same codebase, but on server side, mostly using Java 21 nowadays. We are going on a bit of a tangent here though, my point is that not everyone who uses akka/pekko is using loom and akka/pekko is not a loom only API design. As I said, I don't have issues with making an API specific for loom users if it makes their life simpler from an API perspective, its just that we need to check for that because if you don't happen to be using loom then the code will just deadlock and thats a terrible user experience. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
