Search
Talks
Keynote: Simple goal. Hard to accomplish
Edit
Summarized using AI

Keynote: Simple goal. Hard to accomplish

Yukihiro "Matz" Matsumoto • June 22, 2017 • Singapore • Keynote

In his keynote speech at the Red Dot Ruby Conference 2017, Yukihiro "Matz" Matsumoto discusses the challenges of achieving seemingly simple goals in software development, particularly focusing on the Ruby programming language. He juxtaposes personal goals, such as being a good father, with professional objectives, like improving Ruby, to emphasize the complexities involved in seemingly straightforward aspirations.

Key Points Discussed:

  • Software Creation and Goal Setting: Matz emphasizes the importance of setting clear goals in software development. He reflects on the personal goal of being a good father and relates it to the challenges faced when aiming to enhance Ruby.

  • Importance of Compatibility: He underscores the significance of maintaining compatibility in Ruby, especially since many applications depend on it. This consideration often complicates efforts to improve the language due to the risks associated with breaking changes.

  • Evolution of Ruby: Matz discusses the historical context of Ruby's development, noting its 25-year lifespan, and the responsibilities that come with its widespread use among developers globally.

  • The Ruby 3x3 Initiative: Matz mentions an ambitious project aimed at making Ruby three times faster, highlighting the technical difficulties of meeting this goal while preserving performance and compatibility. He explains that while micro benchmarks are useful, they can be misleading, and emphasizes the need for practical, real-world benchmarks.

  • Case Studies of Improvements: Matz details advancements implemented over recent years, such as generational garbage collectors and performance enhancements, showcasing progress made towards achieving the speed increase outlined in Ruby 3x3.

  • Introduction of JIT Compilation: Matz discusses the exploration of Just-In-Time (JIT) compilation to meet performance targets. He explains the complexities involved in implementing this technology and how it could help enhance Ruby's speed without compromising compatibility.

In conclusion, Matz reiterates that achieving goals in software development can be deceptively challenging, marked by hidden obstacles and trade-offs. He encourages continuous effort to innovate and improve Ruby, aiming for communal support in the pursuit of excellence in software creation, allowing developers to build great software together.

He leaves the audience with a message that the process of creating successful software is a collaborative journey.

Keynote: Simple goal. Hard to accomplish
Yukihiro "Matz" Matsumoto • June 22, 2017 • Singapore • Keynote

Speaker: Yukihiro (Matz) Matsumoto

Event Page: http://www.reddotrubyconf.com/

Produced by Engineers.SG

Help us caption & translate this video!

http://amara.org/v/8HYW/

Red Dot Ruby Conference 2017

00:00:04.890 good morning morning yeah welcome to
00:00:10.540 Singapore and and welcome to the res our
00:00:16.180 will become 2017 and then this is my I don't know both conference here I don't know both
00:00:24.340 of it may I ask you a question few questions ah how many of you are
00:00:33.640 capable ah almost open thank you how many programmers a little bit less
00:00:42.899 thank you how many of you perceive yourself as
00:00:49.320 creators okay fine okay we fellow creators I'm going to
00:00:56.590 talk about our creating software under setting goals and the result of which
00:01:03.430 will accomplish those goals okay we create software in creating software
00:01:10.860 while the goal my personal goal is now related to
00:01:17.409 software be a good father as a father for children so being a good
00:01:25.180 father is quite simple goal right quite simple goal but as how that is how
00:01:33.189 to accomplish the simple goal I guess being a good father but there are so
00:01:39.159 many reasons to fail like a wrong
00:01:45.070 priority or maybe you know so temper or
00:01:50.500 something like that so there are a me no reason to fail and our software goal is
00:01:56.860 to create great software and that simple
00:02:01.990 but it's kind of hard to create great software we have to define great we have
00:02:09.250 to try very hard to create a great software especially when
00:02:17.200 we have become popular so we have so many burden in the history of the
00:02:23.580 development of software for example we would be our simple goal is make the
00:02:29.890 language better right so our week working there will be core
00:02:35.290 team working very very very very hard to make Ruby language better but sometimes
00:02:43.660 that kind of simple goal is pretty pretty difficult to accomplish because
00:02:51.610 Ruby so cutter so that that's the reason we have so many people here in in the
00:02:57.579 audience and it has Ruby has helped so
00:03:02.769 many developers all over the world in Singapore in United States in Japan of course India or Malaysia or Europe or so
00:03:11.260 many countries so it has has many compatibles probably more than million
00:03:18.970 developers all over the world and in it besides that Ruby had survived for 25
00:03:28.750 years like you know it's quite rare for
00:03:33.970 software project to survive more than 20 years but the internal Ruby is about 25
00:03:41.139 years so there's so many software were written in Ruby so you write something
00:03:47.560 really you rise of many there are tons of software within really so in that
00:03:54.519 sense so compatibility models were worthy because even the slightest
00:04:00.519 slightest change even the teeny bit of the compatibility breakage would break
00:04:07.769 thousands of software so we need compatibility in fact really has a lot
00:04:15.340 of technical gaps example so I am a mere human so in design Ruby I made some
00:04:23.080 mistakes or got a source of them so I
00:04:28.810 sometimes I regret them so that I feel
00:04:35.900 some kind of trouble so that I want to resolve those kind of troubles by
00:04:42.910 breaking compatibility so the you know
00:04:48.169 in a sauce design of software or it designed the languages so the designers
00:04:53.800 sometimes want to change the language or
00:04:59.510 software in better way by breaking a compatibility for example we had some
00:05:06.260 kind of huge breakage in between the will be 1/8 and will be 1/9 it was more
00:05:14.030 than 10 years ago but it is a good thing
00:05:19.340 so we replaced up we replaced a virtual machine that makes really a few times
00:05:25.790 faster and then we introduced some kinda are the multi language things so that we
00:05:33.800 can safely use the so many encoding without strings encodings like a unique
00:05:40.820 code 50s in Japan or maybe and a big five in Taiwan or some some other
00:05:46.340 encodings so that current Ruby 1:9 and Ruby 2 supposed to more
00:05:52.280 than 80 encodings all over the world so that kind of change was needed but at
00:05:59.060 the same time the breakage we brought
00:06:04.450 stopped evolution got so many people stay using the old one eight for a long
00:06:12.140 long time so we need we needed more than
00:06:18.860 five years to as a community to migrate what one nine after we release the one
00:06:26.090 nine so the goals five years the commute done at least half of the community was
00:06:34.840 slows down in the improvement from the improvement of the language
00:06:41.360 and the implementation implementation of the runtime so that God five-year is
00:06:47.930 kind of waste of time for us the Python was even worse they took more than ten
00:06:57.620 years or PHP they even canceled piece
00:07:05.210 pieces so the people who is working on the PHP so created the new whole new
00:07:13.189 language without compatibility name the piece b6 but it was the gap was so huge
00:07:21.349 and then knowing the community virtually nowhere in the community shows the piece
00:07:26.810 b6 so they just gave up the similar things happened in atmospheric fall so
00:07:34.430 they gave up atmospheric fall so it's it's called second system syndrome so
00:07:41.319 when we have trouble with the current system we just get mad and yet throw
00:07:49.370 away the first version then we recreate the second version which is whole new and far better and no one use them so
00:08:00.770 that we have learned we have to move on step by step gradual change is the way
00:08:09.919 to go so that we have to buy a compass
00:08:16.129 to accomplish the goals we student threw
00:08:22.430 away our current system current software then we have to gradually improve our
00:08:30.289 systems and then we have to set up the simple goals and then we accomplish them
00:08:37.370 one by one okay let me show you a case study of accomplishing a simple goal for Ruby
00:08:47.740 lastly two years ago actually two almost three years ago so I
00:08:54.310 give give up this kind of slogan model or keyphrase to name the ruby 3x3 that
00:09:03.100 means that how we want to make Ruby three three times faster no you know
00:09:11.680 that made so many people inside of outside of the Kaduri community complain
00:09:18.550 about the slow slowness of the Ruby
00:09:23.559 language look in most of the case so ruby is fast enough the reason you use
00:09:31.569 Ruby right but you know the comparing Ruby to say C++ or maybe Java or I don't
00:09:41.050 knows so and under the very simple micro
00:09:46.839 benchmarks Ruby slow yeah the grouping million times the empty will million
00:09:56.410 times in P loops you know few hundred times lower than C++ of course but in
00:10:04.600 real world application which is not that slow but you know at the same time no
00:10:12.910 one complains about the faster Ruby you
00:10:18.100 know if you we got past so everyone's going to be happy except for exit path
00:10:27.270 so the faster will be the make will be passive that is the simple goal
00:10:34.350 it seems straight forth and pretty simple okay making movie fast but
00:10:43.350 technically it is difficult and all the we have been we have been working on
00:10:50.100 Ruby virtual machine for us to more than twenty years so that we all will have
00:10:56.220 already picked the low-hanging fruit so we have to do something very drastic to
00:11:03.720 make it make really fast fast for three
00:11:09.660 times so actually for more difficult and limiting because we have some kind of a
00:11:18.420 human rules or maybe regulations the hard part is of course about the
00:11:26.550 compatibility we have to keep compatibility even though the released after the second one is the memory usage
00:11:35.510 in general the software performance is that it's kind of that time space
00:11:41.610 trailer so you usually when you make
00:11:48.720 your software faster your software will consume the more memory for example
00:11:56.660 there would be sense to the JVM there will be is faster than purity in most of
00:12:03.149 the cases acceptable startup times and that's just great great things vector
00:12:08.279 JVM but at the same time JRuby concerns
00:12:14.399 more memory in micro benchmarks it
00:12:20.329 consumes a hundred hundred times more memory
00:12:26.320 or it it consumes the same thing more time more memory on the articles
00:12:33.170 benchmark which is relatively big benchmark and somewhat realistic
00:12:38.990 benchmark we will talk about obstacles later so the better the Ruby language may run
00:12:46.790 on memory tight involvement like a karateka smallest Dino I happen to work
00:12:53.780 for a broker so that the it is very important for me to ensure the Ruby
00:13:02.150 would work work we will run safely on
00:13:07.580 the smallest I know without 520 Meg or memory or a decent TC has only to have
00:13:17.870 the two gigabyte memory ok your developers your kisi may have a 16 gig
00:13:24.440 or maybe 20 24 gigs of memory oh but the for the more mere PC uses the
00:13:35.360 decent TT only has a 2 gig gig of memory for a few years back the 2 gig is big
00:13:43.010 memory or even on an embedded system some people try to run really software
00:13:50.210 on top of the smaller computers like a Raspberry Pi or maybe does Lego
00:13:56.839 Mindstorm or maybe the big teeny embedded a building bold like out with a warm egg
00:14:04.160 or memory so at least it should be configurable to use less memory that's
00:14:10.760 the first rule also I'm just I'm the second group memory uses so that we want
00:14:17.480 to make we faster but at least the the faster Ruby can be configured the
00:14:26.769 to use less memory like us the current will be implementation the third one
00:14:33.879 third kidding rules is dependency so really is long live project it's it's 24
00:14:41.110 years of old so I started the the proofing Rudy on February 24 1993 so
00:14:53.290 that in on next February will be will turn to 25 whoa
00:15:00.029 so that depends for Ruby depending on
00:15:05.139 the outside project is dangerous the for
00:15:10.929 example so to make really faster so we can't rely on the DS project like LLVM
00:15:18.329 lifted new lightning better we don't
00:15:23.559 have control over those software so that these are the third-party software and
00:15:29.439 then it's you know we can we cannot control them unless you an apple if you
00:15:38.529 are poor you can buy them the software so that those of you may have bugs so
00:15:46.689 that they may not you know it's on priority the product may be abundant so
00:15:53.490 so that we may need to focus or we have
00:16:00.160 to maintain those kinds of huge turtle software by ourselves which is nearly
00:16:05.470 impossible so that is kind of silly things but there's very few projects of
00:16:12.669 web between more than twenty years ago so that if we want we rely on the third
00:16:20.079 party a huge project we have to take care we might have to take care of them
00:16:27.189 in the future so the programming language live far longer than other
00:16:33.459 software like a you know the Fortran was born in 54
00:16:40.130 1954 the the list was born in 58 so but
00:16:46.920 those languages still survived the Ruby is 24 years old 24 year old and then but
00:16:55.620 I assume Ruby we will survive for coming
00:17:01.070 20 years next 20 years or maybe next 50 years so so we just don't want to rely on the
00:17:12.000 third party project which live you know
00:17:17.570 along far shorter than the verb itself the also we need to have the
00:17:26.070 maintainability so overall meant ability matters so because our main table code stops the
00:17:35.760 pollution so the F we start liberal evolution so
00:17:41.610 that we as a community the grocery type
00:17:49.200 so we have to keep on moving so that the maintainability not us so these are our
00:17:57.230 no restrictions regulations and hidden rules and we map I must add some kind of
00:18:04.350 the easy part to make our goals easy which is one of them is a baseline so
00:18:12.000 the our baseline of three times faster is compared to Rudy 2.0 which is AA
00:18:21.170 which was reducing our 2013 which is
00:18:27.060 four years ago not that 2/4 which really is in last year so we have done a lot of
00:18:34.350 improvement during the are since the will be too old so we implemented the
00:18:39.930 generational garbage collectors we added in we have added incremental garbage collectors and then last year we have
00:18:47.820 added the open address hash table which is which runs faster for the hash table
00:18:53.490 and the metal cup and a lot of other improvements and we have the last last
00:19:02.040 four years we have five to ten percent improvement in performance and memory
00:19:08.550 usage each year we have done a good job for us last few years so they're really
00:19:15.420 two for is faster than really too old then good b-24 consumes less memory
00:19:23.210 slightly less memory than would be too old so we want to include these
00:19:28.440 improvements in the you know the three by three measurement so this is this is
00:19:36.540 one hidden regulation which makes algal
00:19:41.700 little bit easier okay second rule a second regulation is no micro benchmarks
00:19:49.590 micro benchmarks is pretty interesting like we have the Sun going to shoot out games the comparing compare the the
00:19:57.210 performance of the languages but the only games you know the measuring the
00:20:05.820 teeny loops or you know the finding suppose the searching through the binary
00:20:12.750 tree is quite interesting games but you know that not usually reflect the real
00:20:20.610 world behavior so real world application behave differently from micro benchmarks
00:20:26.840 so the in the measurement of Ruby 3x3 so
00:20:32.880 we have to build some kind of standard benchmarks so the standard benchmark
00:20:39.110 need to be very real wall with that we
00:20:44.730 fetch real world it they are out show but they have to affect real world
00:20:50.850 behavior so that we are introduced a to kind of new benchmarks one is the web
00:20:58.200 application benchmark which on top of rails because most people use Ruby
00:21:03.210 through on top of Rails unfortunately yeah rails programmers
00:21:15.050 raise your hand okay that's the reason so that this kind of
00:21:23.630 benchmark is based with this cause and then you can find your benchmark here github.com Noah gives whales with Ruby
00:21:33.020 bends so we are having we had we under the process of improving this funding
00:21:39.560 the benchmark that could be it that can be installed very easily and you can
00:21:46.580 measure the performance very easily so this kind of benchmark is done by no
00:21:52.250 gift which is hired by dog appFolio company which hires him as a working for
00:22:01.790 the improving Ruby four times the
00:22:06.920 another another benchmark is the optic care of our benchmark opt carrots stand
00:22:13.430 stands for the carrot for optimization I
00:22:19.090 don't know about the other culture but it's at least in Japan carrot stand for
00:22:25.000 you know tempting bite for horses you
00:22:30.410 know you put the carrot on on in front of the holes the hook like I like this
00:22:37.640 that host runs the chasing carrot so
00:22:42.740 that can the host can run their very past so that optic care of try to be a
00:22:50.090 carrot for Ruby 3x3 so it's like we
00:22:57.550 pursue to improve the performance of the optic care of benchmark so the Ruby we
00:23:04.010 are going to be faster the other carrot is the nanometers Nintendo internet
00:23:12.080 system emulator so you can play say Mario using the other carrot they try to
00:23:20.440 implement a a compressor six frames per second by you know the dynamic
00:23:28.269 interpreted conversion machine so you can find out the carrot here github.com
00:23:35.289 mummy at the carrot the topic a lot is
00:23:41.149 written by the this guy you scandal which is insanely genius guy so the we
00:23:50.960 have the his immigration we have the baseline of the Ruby tool and we don't
00:23:56.419 use the micro benchmarks to measure will be three by three okay that there are
00:24:02.899 all the regressions memory usage dependency the maintainability the
00:24:08.179 baseline the no micro benchmarks so the Ruby 3x3 under these regulations how
00:24:18.080 hard they are I consider Ruby 3x3 is nearly impossible
00:24:31.629 yeah we need some kinda fresh technology
00:24:37.059 named it here we have the tons of other
00:24:42.100 optimization to the virtual machine but
00:24:47.139 the I'm expecting dead can be a very very useful in improving the performance
00:24:58.210 the gist stands for the just-in-time compilation so the some language used
00:25:04.039 LLVM to implement it like a ruby Gnaeus crystal julia these languages LLVM to to
00:25:12.860 make this language faster so it is portable so it runs on any OS and see
00:25:20.269 many ways and many CPUs and as the LLVM is highly optimized the code generated
00:25:27.169 by LLVM is quite quality in a highly optimized and but uh the dip
00:25:36.780 API sometimes changes so we have to follow these change and then the LLVM is
00:25:45.540 a huge hate party software so we had a problem for anxiety of dependency we
00:25:54.540 have other jet libraries like a Lib that lived it or the new lightning so that
00:26:02.630 these libraries are less widely used and it comes with the lesser GPL which is
00:26:12.320 now fully compatible with the owl our license which is BSD and we have we also
00:26:21.990 have that anxiety of dependency so we have been are considering adding G to
00:26:31.320 the language for a long long time and then the only option we could think of
00:26:38.760 without these kind of our problems is the writing our own jet which is very
00:26:46.700 very difficult so that we were having
00:26:53.550 trouble for a long long time but uh early this year
00:26:59.250 the other option came in and it emptied
00:27:04.530 stands for emoji keyboard you can find the blonde with emptied here github VN
00:27:13.380 mock love will be 3 LP LMZ branch it's done by dove vladimir and Makarov
00:27:22.110 delight pronounced like who's working for Red Hat and then the rod email is
00:27:29.910 also the opera just hash table we have introduced last year so the engine is a
00:27:38.700 little bit different approach MJ is a
00:27:44.610 LTL and just uses the does straightforward DCC fourth clan and then
00:27:52.080 just our M line uses messages let me explain a little bit more about that so
00:27:58.049 LTL stands for the register transfer language so that it is kind of the byte
00:28:09.269 code or the abstract instructions for abstract machine and it's based on the
00:28:16.620 registers in the in the world of the virtual machine in our implementation so
00:28:23.429 there are long history of arguments between the stock-based internal
00:28:32.419 representation and the register based internet position so the stock-based
00:28:38.130 aisle means the distancing so that get local up the get local variable which is
00:28:47.429 the part of the young instructions so that you can take the look value of the
00:28:57.240 local valuable of be index into the stack then the another local variable
00:29:06.860 into the stack then at the plus operation consuming to stock entries
00:29:15.200 then push the result in the in on top of
00:29:23.429 the stack then you put the value the stack top value to the local variable in
00:29:31.740 a index that kind of thing like it's kind of like a fault you know stock based language in a
00:29:39.480 register this IR which is the okay the value of a youth class volley way and
00:29:46.769 valuable P into the value of C so much simpler but imprinted implementation
00:29:54.149 wise so that the risk of SiO is much much more are complicated so that you know
00:30:01.710 both sides of the pros and cons so there's no clear winner in this argument
00:30:09.410 and y'all's the current VM years done folder yet another Ruby VM the real
00:30:18.030 stands would love uses stack beta are like JDM you stack this i/o okay for
00:30:28.920 your information the M Ruby the alternative implementation will be also use the register by all anyway the stack
00:30:37.440 based AI R is simpler and stock based IRS shoulder-in in term of the the size
00:30:43.950 of the the compiled by code the the
00:30:49.320 register based il creates less instructions okay the size of the code is smaller in stock
00:30:57.540 based the number of the instructions of the smaller in stock register based i/o
00:31:05.550 and in addition the register based io creates less memory traffic so you can
00:31:11.850 access less memory and register desire of claim to run faster so that enough
00:31:22.500 this as I said before that there's no clear winner in the stock based il and
00:31:29.640 the resistor base I all but at least for this purpose so that the register this
00:31:36.360 il is easier to implement it on top it and that which is the best IO is less a
00:31:43.710 little bit easier to implement the the optimization so he chose the new the
00:31:52.740 virtual machine instructions on which is register based so the the vladimir
00:32:00.890 replace the job by his LTL voter machine which is not perfect yet but it's
00:32:08.850 working and it as fast under the current
00:32:14.960 implementation so his LTL virtual machine is run as fast as two fold
00:32:20.890 it's not slow and it consumes almost
00:32:27.050 same memory amount as the recommended virtual machine so that you know the
00:32:35.600 step of the Ruby makes three times faster so that you know the same
00:32:44.480 performance is not satisfied so you might feel unsatisfied by the same
00:32:52.460 performance same memo footprint but the important things is that you know you
00:32:58.880 don't have the performance decoration and then you them come concerns the
00:33:05.210 baseline of the memory footprint so the we have the new virtual machine with
00:33:12.500 register based then he implemented on top of the RPL the the activities
00:33:22.340 like this the figure is really small but
00:33:28.300 fundamentally the empted images here
00:33:35.470 generate cheat code into files then
00:33:41.440 compile C code by GCC or climb as a
00:33:47.860 normal a compilation step then generate
00:33:53.090 the dot as the dot a so file shared object file then load dynamically those
00:34:00.080 iso files into Ruby to implement this
00:34:05.230 which is which is nice idea it is not
00:34:13.520 straightforward you jury did creates the the interruption in memory then called
00:34:20.930 the function we generate in the memory but a he cush
00:34:26.330 he used the Biosystems and that the user compiles to compile jet files so that we
00:34:35.990 in under the current implementation we generated the Java code which is in
00:34:41.900 memory then we execute that those in memory your code write those we eat
00:34:48.920 compiled will be cold into the yard cold gang excuse ah you are called by the virtual reality
00:34:55.820 machine so by MGM jet the baseline is
00:35:05.030 you can read the Ruby code then compile will be called into the LTL which is the
00:35:10.700 register based virtual machine code then execute the the LTL by the Aldea virtual
00:35:17.600 machine which is threefold and then quotes a similar to yours but
00:35:24.410 once you turn off the jet option so MZ
00:35:30.490 creates the LTL then general C code into
00:35:36.650 file from LPL then compiled all seek ship code by GCC then load compile iso
00:35:47.690 file then execute the function so benefit so we have no tricky
00:35:58.370 dependencies so this ec is independent of course GCC is other third-party
00:36:05.030 software but which is live far longer than Ruby the first version of Ruby in
00:36:12.130 93 or compiled by this machine so DCC is all enough
00:36:18.020 besides that so that you know the compilation step is well-defined so it
00:36:24.170 is it's so stable so it hasn't changed for us I don't know 30 40 years so we
00:36:33.200 can rely on them to the next 20 years and then those compiled is a very stable
00:36:39.530 and a GCC's ubiquitous you can you can have the DCT on Linux Mac Windows or
00:36:47.349 maybe in the owner and abetted devices so at least you can have a complete
00:36:54.980 compiler on so many systems the by the
00:37:01.520 reason so that ends it is pretty much portable and highly optimized but we
00:37:10.849 also have tricks so the point is it is
00:37:23.839 so many unnecessary steps compared to the attitude so that you have to
00:37:33.349 minimize headers so in the build process we create the minimized header
00:37:41.170 he claims that we can cut the 90% of the Ruby headers then Oh and that he used
00:37:54.109 the worker threads to create the the jet code so the good compilation process is
00:38:01.880 the is done by the separate thread from the P the main line friends so that you
00:38:10.609 can use the the multi-core to to get compiled so as a result default l GL is
00:38:20.630 of such as Ruby and a default of the L constant up less memory as we Alex the
00:38:26.060 current implementation and and it runs far faster than yours and it concerns more memory than job of
00:38:33.410 course and then you can do that ahead of time compile a hydrant on completion so
00:38:41.059 you can compile all the review files into the machine code you can roll them
00:38:47.780 into the virtual machine to run you will will be called in see it's not comparable to plan C
00:38:55.880 code written by a human but it's faster
00:39:01.400 than the group does the plain Ruby and then we can have the future of such
00:39:07.970 drastic inlining which makes the compiled code even faster or maybe the
00:39:15.530 weird planning about the speculative jet which in assuming the okay this argument must
00:39:24.140 be integers so you can compile these numbers as integers without any the
00:39:31.450 converting back and forth with the Ruby world and C world so by using these
00:39:37.130 kinds that technique and ideas range it can be even faster of course and it has
00:39:44.000 drawbacks which is the higher compiler
00:39:50.390 cost you know the process is a generation she called excusing C
00:39:55.640 compiler the passing C code the cogeneration code generate from generate
00:40:00.680 code from C code than the dynamic loading dot ISO file which is all of
00:40:06.049 them unnecessary for the usual tips like a live using lidget or other jet
00:40:13.460 technologies so these kind of things the
00:40:18.559 you know the burden to the performance but we they attract a he is trying to
00:40:26.720 the minimal is kind of a burden so although result mgs1 far faster than
00:40:34.520 y'alls and it consumed more memory than job as i told you okay and that runs
00:40:41.150 faster than JRuby and indeed consume far less memory than geography okay under the micro
00:40:48.720 benchmarks which are a lot of the words kmidgette runs six times faster than we
00:40:55.800 do all in average then just consume four times more memory as a reference JRuby
00:41:02.280 12.5 faster than will be too old and the dairy comes with 200 times more memory
00:41:07.400 in micro benchmarks in optical out
00:41:12.570 benchmark and it runs 2.8 times faster and then consumed 1.16 16 times more
00:41:21.180 memory as a reference generally runs 2.4 times faster than will be too old and
00:41:27.570 there it comes 18 times memory ok another the real world example the difference is not that
00:41:35.820 big you know that's not sixth time not 200 times so the evolution is an empty
00:41:44.670 is very promising but as it still have some issues we cannot replace the M jet
00:41:52.220 our virtual machine by NZ yet but it's
00:41:57.300 promising we need more so we don't make
00:42:02.339 any promise we don't make any promise that we might not have the Ruby MJ as a
00:42:10.130 jet engine for will be three but at least we already have the implemented
00:42:18.750 technology to make Ruby three times faster and then the engine achieves the
00:42:26.339 highest in out criteria okay we are trying to make the other with rheumatics
00:42:31.890 it's like a multi-core concurrency or type inferences okay I'm not going to
00:42:37.380 talk about them today but as those simple goals have hidden rules and
00:42:45.290 regulations and limitations and they are so difficult internet so I can now I
00:42:53.460 only say that today but we have tons of work to do that to make
00:42:59.070 Ruby better conclusion a completion simple goal can be extremely difficult a
00:43:06.560 lot of hidden trade-offs and migrations but it's all a way of creation we are
00:43:14.940 created right so we are trying to create something we haven't seen just so it's
00:43:22.860 kind of magic - subdiver first source of development is the process of making
00:43:28.820 impossible possible so at the first grant-making Ruby 310 past is impossible
00:43:38.670 but somehow we can do not nasty things
00:43:48.740 but you can technologies ideas with help form genius and community so that the
00:43:57.210 difficulty and pain a cause of the creation we know is how every single
00:44:03.770 simple goal is hard but we have to keep
00:44:08.790 trying we have to keep moving forward and in do until we can accomplish we
00:44:18.510 will help you the Ruby is the way that I
00:44:23.570 try to help you guys to implement great software so we can help each other so I
00:44:31.290 help you you help me we ask so together we can make it and in
00:44:41.240 this talk is special appreciation to brother Mycroft happy hacking and make
00:44:49.410 impossible possible thank you
00:44:59.120 so you mentioned that mg might be slower in some cases I wondering if you're
00:45:04.500 planning to give some API to disable it explicitly if I know that my program may
00:45:10.410 not benefit from it that it might be slower with mg done than without it yeah you have to turn on ng by explicitly so
00:45:17.760 by default ah da you can run Dirk by default it will be off and I need to
00:45:23.850 turn it on explicitly or by D chosen to do an on explicitly okay okay for it
00:45:29.040 it's the performance is to say the same okay Callie thank you hi
00:45:38.250 so I'm pardon my ignorance but so the point of JIT is that you instead of
00:45:45.450 interpreting the program when you run it you compile it into C into like a shared
00:45:52.230 object and then you kind of execute that object on the target platform great okay
00:45:57.690 and interpret so the way it is done now works how so how do you how do you
00:46:03.930 interrupt how do you run them I mean I'm sorry to ask that but how do you actually run Ruby at the moment like how
00:46:09.090 does the interpreted way work yeah yeah there you compile the you're really cold
00:46:15.270 in in see if I are converting out LTL to
00:46:22.830 the C code okay corresponding C code then compile them by the C compiler then
00:46:29.180 called the load and dynamically then link into that you know it plays up the
00:46:36.530 implementation with the Sheep ring ah that will be implemented the root method by the dog guides below that C function
00:46:44.000 so that that must just run the method implemented in c so but that's the
00:46:52.380 that's the JIT right data yet okay and how does it work like at the moment we don't have get right at the moment we
00:46:58.770 have interpreted the interpret I never understood how the actual interpretation
00:47:04.700 process works like so there's Ruby code and then we have the Ruby VM
00:47:11.470 and you basically compiled the Ruby code into instructions for the Ruby VM yes
00:47:17.380 and then the VM The Onion's doesn't fit the one instruction book okay okay okay
00:47:23.230 and that's obviously slower because you have to interpret the move okay okay well no if I finally understand
00:47:29.079 what JIT is thank you you're welcome
00:47:40.030 in education okay it's fundamentally
00:47:58.940 saying so that under the virtual machine you have to convert back and forth in
00:48:04.160 the C structured and the Ruby data types and in the converted C code you have to
00:48:11.120 do the same so that the cost you can remove from the virtual machine is the
00:48:17.170 doctoring the cold and the the conditioning or something like that so
00:48:22.820 that make the control faster not the top the data process itself so you have to
00:48:29.780 send a method in in a dynamic way so you have to teach them the value in dynamic
00:48:35.690 way or something like that that won't change so that that is the reason so the
00:48:42.710 engine runs three times faster not a hundred times faster
00:49:03.530 what time okay thank you
Yukihiro "Matz" Matsumoto
@matz
Explore all talks recorded at Red Dot Ruby Conference 2017
+12