e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
pawnbox has quit [Ping timeout: 260 seconds]
rueben has quit [Ping timeout: 260 seconds]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 264 seconds]
johnsonch is now known as johnsonch_afk
sandelius has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
yfeldblum has quit [Remote host closed the connection]
prasunanand has quit [Ping timeout: 244 seconds]
pawnbox has quit [Ping timeout: 260 seconds]
pawnbox has joined #jruby
rsim has joined #jruby
rsim1 has joined #jruby
rsim has quit [Ping timeout: 252 seconds]
yfeldblum has joined #jruby
Hobogrammer has quit [Quit: WeeChat 0.4.2]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
yfeldblum has quit [Remote host closed the connection]
bjfish2 has quit [Quit: bjfish2]
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
rsim1 has quit [Ping timeout: 252 seconds]
pawnbox has quit [Remote host closed the connection]
yfeldblum has quit [Ping timeout: 250 seconds]
yfeldblum has joined #jruby
shellac has joined #jruby
prasunanand has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
sandelius has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yfeldblum has quit [Ping timeout: 250 seconds]
yfeldblum has joined #jruby
vtunka has joined #jruby
sandelius has joined #jruby
pawnbox has joined #jruby
shellac has joined #jruby
<sandelius>
we're starting a new app soon at work and people are promoting node (we need concurrency). I dont tho and want to present a better option. How does jruby compare against node? concurrency and performance.
<kares>
sandelius: hey! one might say that basically its a different approach
<kares>
node is single threaded "callback"-style concurrency while JRuby is traditional thread-style concurrency
<kares>
maybe you need to think in terms of node vs jruby+ a library of choice e.g. concurrent-ruby, celluloid or basically any actor library on the JVM
pawnbox has quit [Remote host closed the connection]
<sandelius>
kares ok so jruby does not run each request inside of a "fiber" or "process" like elixir does?
pawnbox has joined #jruby
<kares>
sandelius: you mean web request?
<sandelius>
kares yeah, sry should've mentioned that first :)
<kares>
sandelius: it does at that is the actual win compared to MRI
<kares>
if you're doing a web app every request will run in its own thread
<kares>
there's no GIL in JRuby so it will be concurrent (compared to MRI)
<kares>
sandelius: you can pretty much assume it will work as Java except that no Java is needed to be worried about :)
<sandelius>
kares well that sounds kinda amazing then we get real concurrency and even parallelism? why do not more ruby folk use jruby instead of moving to other more concurrent languages than ruby?
<kares>
if you only need concurrent serving of requests than your choice should be pretty much around libraries and ecosystem
<kares>
sandelius: yes that is correct
<kares>
maybe cause its not that hipster as elixir these days :)
<kares>
also ruby devs are pretty much rails devs so they likely to move away from rails
<sandelius>
kares I came for rails 5 years ago but stayed for ruby :)
<kares>
sandelius: so you understand - Rails folks hit the limits of the framework so they look elsewhere
<kares>
limits - pretty much sanely managing large code-base apps
<sandelius>
akares that's just sad...
<kares>
sandelius: you likely won't find 'fair' comparison of node vs jruby performance
<kares>
one would need to have a similar non-trivial app build in both
<sandelius>
kares but they're comparable atleast?
<kares>
sandelius: yes - e.g. one ~ way to compare would be :
<kares>
http://vertx.io/ which is kind of like node "server" for the JVM if you're into that style of programming
<kares>
there's jubilee server for JRuby built on top of Vert.x
<sandelius>
kares nah then I rather use regular jruby/puma. I read some stuff about jruby+truffle. Is that somethign that's coming in a future version?
<kares>
sandelius: yes its usable but parts such as talking to DB of OpenSSL don't work currently
<kares>
that is the next big thinkg for truffle folks to deliver - not sure how far they are in emulating the MRI C-API
<sandelius>
kares what does that mean for jruby? will it be even faster? alot?
<kares>
if you hang around I am sure someone will answer
<chrisseaton>
sandelius: we hope it will be a lot faster yeah, but it's not ready yet
<kares>
sandelius: that depends on the Ruby code and you will also have to use a different VM called Graal instead of JVM
<chrisseaton>
kares: not when JDK 9 comes out! We're integrated into that now
<sandelius>
chrisseaton kares so jruby's future is bright then :)
<chrisseaton>
It's certainly getting an immense financial investment from oracle - team of five here now
<sandelius>
chrisseaton that's amazing! concrats too you all and thanks for all the hard work
<kares>
chrisseaton: good to hear - did not know its definite for JDK 9. thanks!
<kares>
sandelius: yes certainly JVM's future seems bringht and polyglot. but you can use any Java libraries with JRuby seamlessly even today :)
yfeldblum has quit [Ping timeout: 250 seconds]
etehtsea has joined #jruby
<sandelius>
do you guys have any good ideas on how one would warm up the jvm when deploying?
<etehtsea>
hi everybody. is there some recommendations how to decrease jit warmup? I tried compile.mode=FORCE and didn't see any noticeable changes.
<etehtsea>
@sandelius lol
<sandelius>
:)
<etehtsea>
didn't see your question
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
skade has joined #jruby
<kares>
etehtsea: believe that's going to be better in 9.1.3 or later (forced compilation AOT)
<kares>
in general would try tuning the JVM on jruby's end you could try setting the threshold lower
<etehtsea>
kares I'll try, thanks!
drbobbeaty has joined #jruby
<kares>
seen heavy concurrent apps do pre-warmup requests before going production
<kares>
generally I do not like to share any J_OPTS advise as people tend to than blindly set those - it depends on app really
<etehtsea>
I've already added pre-warmup requests. Possibly I should request all available endpoints
<kares>
etehtsea: than you need to do perf testing as you do change J_OPTS
<etehtsea>
kares is threshold number affecting with FORCE mode or only with JIT?
<kares>
etehtsea: probably both in your case
etehtsea has quit [Ping timeout: 240 seconds]
etehtsea has joined #jruby
<etehtsea>
@kares is threshold number affecting with FORCE mode or only with JIT?
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<etehtsea>
and is jit.codeCache still a thing nowadays? setting this opt to a dir did nothing after start/stop
<kares>
both modes since FORCE doesn't really force AOT compilation - for code cache not sure - look at the sources
yfeldblum has joined #jruby
<kares>
also I meant more real world warmup but that Rack warmup thing is cool - just make sure its running several times. not sure about its effect if the real requests trigger a different execution path
ebarrett has joined #jruby
<chrisseaton>
etehtsea: some of those jit options aren't wired up to anything any more
etehtsea has quit [Ping timeout: 244 seconds]
etehtsea has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]