Disqus - Latest Comments for headius

Re: Speeding up Ruby by rewriting C… in Ruby

headius — Fri, 20 Dec 2024 00:37:33 -0000

Very nice article!

Worth mentioning, however, that some language runtimes will optimize these benchmarks down to almost nothing, proving nothing about actual application performance (unless your app is all loops adding numbers or inefficient fibonacci number generation). In addition, there's no consideration for startup time or warmup time on optimizing runtimes. JRuby, for example, performs significantly better than CRuby with YJIT... but only if some time is given for it to warm up in a single process.

I encourage you to look at the many other comprehensive language benchmarking suites, like the Benchmarks Game, which have years of improvements in the benchmarks and various strategies for minimizing startup and warmup time.

Re: Great One Beast boss fully restored thanks to new Bloodborne mod

headius — Mon, 21 Sep 2020 00:48:18 -0000

Epic... Should have kept it in!

Re: The Ruby Spec Suite Compatibility Report

headius — Mon, 29 Jun 2020 21:48:31 -0000

Thanks for all your work to help add and update the specs in the Ruby Spec suite. It has been great to see so many new tests coming in, and that's in large part due to your efforts.

The Ruby Spec suite offers a somewhat limited view of compatibility. Many parts of Ruby are poorly tested, and there are often entire classes and libraries that have no tests at all. Of the tests that do exist, many just permute hundreds or thousands of minor variations of behaviors that are rarely used. While many specs have been added to clarify behaviors for users, a large part of them do not reflect behaviors that any user will ever see.

The specs also tend to favor features that are new or currently in the process of being implemented, and can be weak on features that have existed for a long time. That happens because most of the specs that exist were added in service of implementing Ruby (both standard and alternative), and so they necessarily have a strong bias toward the features those implementations actually support.

In JRuby's case, we only have two full-time developers, so we must be pragmatic about how we use our time. While we do add specs when we come across untested behavior, we have not focused our primary development efforts on passing any particular test suite. The vast majority of time spent working on JRuby is spent addressing the compatibility and performance issues that actual users report, and when those issues expose a gap in testing, we add new specs.

The bottom line is that we usually focus on issues that actually affect our users... we implement the "Ruby" that Rubyists actually use. As time permits we work toward passing more of the Ruby Specs and the CRuby test suite, but simply passing tests is not our primary motivator.

A few notes on your methodology here:

The Ruby Spec pass rate on JRuby is misleading. We often fix or update Ruby features without updating the related spec tags. We periodically sweep out passing tags, but we are cautious in doing so since some APIs behave differently across platforms (and so they may have been tagged due to one problematic platform). Nearly every time we approach a set of specs to improve compatibility, we find out that some or all of the existing tags were fixed long ago. The pass rate described here is certainly not our true pass rate and it has been some time since we made a concentrated effort to pass tests just to pass tests.

The pass rate for CRuby tests (as reported by our CI run) is also not useful as a compatibility metric. We only run a subset of specific CRuby test cases, focused primarily on the core APIs. There are many tests in CRuby that are duplicated in the Ruby Specs, many that test pure-Ruby standard libraries (which we believe should not need to be run if the core APIs they use are compatible), and many more we do not run because they are specific to CRuby.

Re: Optimizing Ruby Lazy Initialization in TruffleRuby with Deoptimization

headius — Tue, 31 Mar 2020 14:07:06 -0000

Well done! It's pretty nice that you have this level of control over branch profiling.

Maybe it is worth pointing out, for clarification, that JRuby already has this optimization because most JVM JIT compilers will elide rarely-followed branches when they emit assembly code. For this lazy initialization example, Hotspot's C2 compiler does not emit either the computation or the assignment code into assembly.

I wish we had more direct control over how the JVM profiles branches, but I'm glad to see it's doing the right thing for JRuby in this case.

Re: The Murder Of My Beloved IPA And The Rise Of The Great Pretender

headius — Fri, 10 Jan 2020 13:06:29 -0000

I don't have a preference but cans are lighter than bottles and many places ban glass containers (campgrounds, swimming pools). Bottles also let in flavor-damaging light. Unfortunately most beer cans are still lined with BPA.

Re: The Murder Of My Beloved IPA And The Rise Of The Great Pretender

headius — Fri, 10 Jan 2020 12:26:37 -0000

Yards seems to have several IPAs...which one is it that you like?

https://untappd.com/YardsBr...

Re: The Murder Of My Beloved IPA And The Rise Of The Great Pretender

headius — Fri, 10 Jan 2020 12:24:10 -0000

I can guarantee you that I would not gush over a box of Coors Light, regardless of how blind the test is.

Re: The Murder Of My Beloved IPA And The Rise Of The Great Pretender

headius — Fri, 10 Jan 2020 12:22:57 -0000

Sour beer is not infected beer. There are many varieties of yeast like Brettanomyces that produce more acidic output as part of natural fermentation.

And sour beer is far from "the coming thing." It's very popular and there are many breweries that specialize only in sours.

The only thing I agree with is that American beer is definitely not what you want if you want tasteless beer.

Re: The Murder Of My Beloved IPA And The Rise Of The Great Pretender

headius — Fri, 10 Jan 2020 12:17:27 -0000

Harpoon IPA is a decidedly American-style IPA. English IPAs are the maltier ones, especially in comparison to American IPA.

The Goose IPA you lament is actually an English-style IPA.

New England-style IPAs, those hazy juicy wonders, are a very recent and popular addition to the IPA family. As another commenter mentioned, they cover up some of the resiny aspects with juicy aromas. This is mostly achieved by putting a big load of hops into secondary fermentation, where it adds aroma but not bitterness.

Goose IPA is not a New England-style.

There's a wide range of IPAs now: English, American, West Cost, New England, Milkshake, Black, and the hoppy style has even spread to lagers and dark beers with India Pale Lager being one of my favorites.

So I'm not really even sure what it is you are looking for. Seems like you're just dumping on every IPA style that doesn't conform to your definition of IPA...which is actually a standard (and still widely produced) American IPA, not the original English IPA you claim.

Re: How TruffleRuby's Startup Became Faster Than MRI

headius — Fri, 26 Apr 2019 09:33:18 -0000

Thanks for pointing all of that out, Kevin and Benoit! Indeed, you did make clear that this is just hello world startup, and as we all know the biggest challenge is yet to be solved: getting the tools Rubyists typically use to also start up as fast or faster than MRI. What you have managed to do so far is still very exciting and we'll be looking at native-compiling JRuby once RailsConf is over. I'm hopeful we can match these numbers, and also bring fully native-compiled Ruby into that equation to help solve the larger tooling story. Looking forward to cooperating on this with you and the Graal folks!

Re: How TruffleRuby's Startup Became Faster Than MRI

headius — Thu, 25 Apr 2019 21:08:47 -0000

Isn't claiming that "TruffleRuby's startup became faster than MRI" rather misleading? It's only faster for the narrow case of simple scripts that don't load gems, and in my measurements locally it's usually not even faster for those cases. You and I both know that when Ruby users think of startup time, they're thinking of things like Rails, Rake, Gem, Bundler, and none of those scenarios are faster on TruffleRuby at present.

Re: TruffleRuby Native: Fast Even for Short Scripts

headius — Thu, 25 Apr 2019 20:13:31 -0000

JRuby's JIT (to JVM bytecode) can also inline across Ruby and Java, and achieves very good performance as a result. You don't have to write everything in Ruby if the runtime can optimize across languages, which the JVM can do.

Re: How TruffleRuby's Startup Became Faster Than MRI

headius — Thu, 25 Apr 2019 19:58:11 -0000

The ahead-of-time numbers for booting TruffleRuby are very good to see, and we're looking forward to precompiling JRuby as well.

However, I'm confused about your assertion that TruffleRuby starts up faster than CRuby.

The TruffleRuby "-e" numbers are basically equivalent to running CRuby without RubyGems loading at startup, correct? So if you compare apples to apples here:

[] /tmp $ rvm use ruby-2.6.2 Using /Users/headius/.rvm/gems/ruby-2.6.2 [] /tmp $ GEM_PATH=. time ruby -e 1 0.09 real 0.07 user 0.01 sys [] /tmp $ GEM_PATH=. time ruby --disable-gems -e 1 0.02 real 0.01 user 0.00 sys [] /tmp $ GEM_PATH=. time ruby -S gem --version 3.0.3 0.14 real 0.10 user 0.03 sys [] /tmp $ rvm use truffleruby Using /Users/headius/.rvm/gems/truffleruby-1.0.0-rc15 [] /tmp $ GEM_PATH=. time ruby -e 1 0.07 real 0.02 user 0.01 sys [] /tmp $ GEM_PATH=. time ruby -S gem --version 3.0.3 3.42 real 4.85 user 0.27 sys

Is it really fair to say TruffleRuby starts up faster than CRuby?

Re: Nioh isn’t ‘Dark Souls’ Enough

headius — Tue, 28 Feb 2017 19:29:49 -0000

Agreed on both points. I'm maybe 50% through the game (judging by how many Kodama I've found) and the slow trickle of new enemies is a big downer. And like you say, the level design is nowhere near that in Souls or Bloodborne; they're mostly flat, mostly just rat mazes with a few rooftop or underground shortcuts. A couple areas do stand out, like the castle of spiders and the "Three Gods" area, but most of the time I feel like I'm wandering around someone's back yard Japanese garden.

That said, this is the first action RPG I've played that compares to Soulsborne when it comes to the pace of action and mechanics of fighting. Witcher 3 came close, but maneuvering is cumbersome and actions take too long to perform. Not so with Nioh; fights are lightning quick, hit boxes and invincibility frames are palpable, and strategies endless.

I just wish there were more variation in enemies and more interesting levels in which to have those fights.

Re: Data Serialization Comparison: JSON, YAML, BSON, MessagePack

headius — Fri, 11 Nov 2016 02:32:41 -0000

I too would be interested in a comparison with the various *buffer projects.

Re: Try Not To Die: An Overview of ‘Castlevania’ For The NES (1986)

headius — Mon, 26 Sep 2016 19:34:23 -0000

You want to talk hard...try playing through it again after beating it. Every stage has the equivalent of medusa heads, there's more enemies in general, and everyone hits harder. I've beaten Castlevania many times, but never have I completed the second quest. That's oldschool hard.

Re: Here's Why The Microsoft Corporation (MSFT) Xbox One Scorpio Will Absolutely Own The PlayStation 4 Pro

headius — Mon, 26 Sep 2016 19:26:21 -0000

This. Totally this. PS4 Pro is going to have a full *year* on Scorpio.

Also, yes, it also does 4k gaming. The rumors about upscaling-only were pre-announcement. They will auto-upscale 1080p, but games can choose to run 4k. From their own FAQ:

Q: What resolutions does PS4 Pro support?
On 4K TVs, games are capable of running at up to 4K (3840 x 2160 pixels, also known as “2160p”) resolution.

Honestly though, I think most folks looking for real 4k gaming are going to stick with a PC for the foreseeable future.

Re: [Manga-Downloadr] Improving the Crystal/Ruby from bursts to pool stream | AkitaOnRails.com

headius — Wed, 08 Jun 2016 17:47:42 -0000

This benchmark is so short it's extremely unlikely that the JVM has warmed up at all. JRuby's results are probably way off from hot performance.

Re: Sidekiq for Crystal - Mike Perham

headius — Fri, 27 May 2016 18:24:04 -0000

Ok, I managed to get it to run, but the hiredis extension doesn't load properly on JRuby 9k. So with pure-Ruby everything, JRuby beats MRI: 5778 jobs/sec versus 4879 jobs/sec.

With the native hiredis adapter working it should be much higher.

Re: Sidekiq for Crystal - Mike Perham

headius — Fri, 27 May 2016 18:19:46 -0000

What about JRuby performance? Doesn't it already run Sidekiq significantly faster than MRI?

Re: What's your Dark Souls strategy?

headius — Sun, 10 Apr 2016 21:08:55 -0000

I think my strategy has been similar. Stock build to start, get a feel for the game, and then tweak a new character to actually complete it. Sometimes it's my third or fourth character before I get the build just right.

However I'm also a terrible player...I spend most of my levels on health and stamina until I get a feel for the game and can properly dodge and parry attacks.

I will say that Bloodborne has made me a MUCH better DS player. I can usually go without a shield altogether now, relying on dodging and parrying tactics. Having two free hands makes things much more interesting.

Re: What's your Dark Souls strategy?

headius — Sun, 10 Apr 2016 21:05:32 -0000

Ain't that the truth. I've yet to get through it without cheesing the casters with bow and arrow.

Re: Performance Improvements in JRuby 9.0.3.0

headius — Fri, 23 Oct 2015 18:16:45 -0000

We are hoping to get all define_method cases to be as fast as reasonably possible. Those that capture state will always have some loading overhead, but we're also going to explore the possibility of lifting known static values out of the surrounding scope (e.g. if we can see that define_method does not modify a captured value, we use it directly and don't carry around the captured state). Stay tuned!

Re: Darth Vader In Unreal Engine 4 Sure Is Pretty

headius — Fri, 02 Oct 2015 10:47:11 -0000

What's up with the excessive particle effects? I hope the final game won't have that, because it's super distracting.

Re: The sad state of web app deployment

headius — Fri, 18 Sep 2015 17:57:12 -0000

I'll jump in and mention that for bundling application + dependencies + runtime together, you at least have the option of JRuby. A single zipfile and you can have just about everything your app needs to execute in one box. Folks ship some pretty gigantic Ruby and Rails apps as a single file using JRuby. All the target machine needs is a JVM.

Of course, that doesn't address the other aspects like setting up and migrating databases, opening ports, etc, but it helps.