WEBVTT 00:00.000 --> 00:14.280 Hello everyone, my name is Masashi Yuximura from NTT in Japan and today I will present 00:14.280 --> 00:22.440 a high-speed Linux application execution in the browser with binary translation. 00:22.440 --> 00:33.720 So today the browser has become a computing platform, games, rendering video processing 00:33.720 --> 00:37.320 and even LMS can run in the browser. 00:37.320 --> 00:42.000 So can any program run in the browser? 00:42.000 --> 00:46.320 Yes, so the answer is no, and it is very difficult. 00:46.320 --> 00:57.920 This will be because the browser MS is security and portability and access to OS features 00:57.920 --> 01:03.920 and the device is dimmed. 01:03.920 --> 01:08.920 So what if we could run any native application in the browser? 01:08.920 --> 01:18.360 Yes, so today there are many efforts to put powerful software to WebAssembly, such 01:18.360 --> 01:24.200 as post-to-deskware, FPV, and live-office. 01:24.200 --> 01:34.400 So native browser converges and combines native level of performance with WebRAM, portability 01:34.400 --> 01:36.400 and security. 01:36.400 --> 01:44.920 So, however, as mentioned earlier, it is very difficult to run any native application 01:44.920 --> 01:46.920 in the browser. 01:46.920 --> 01:55.240 So, to address this program, there are projects such as BV-86 and Konata Wazun that 01:55.240 --> 02:00.120 both CPU and Mertas to WebAssembly. 02:00.120 --> 02:11.720 This approach works functionally about CPU, migration, code this CPU, performance, degradation. 02:11.720 --> 02:17.280 In some cases, applications have become at tens of times slower. 02:17.280 --> 02:27.840 So, this performance limitation is a key problem, really, others. 02:27.840 --> 02:35.480 So, concerning that, we propose a RFCOM on LT-Binary Transurator, a from the next applications 02:35.480 --> 02:37.680 to WebAssembly. 02:37.680 --> 02:47.240 Instead of emulating the CPU at runtime, RFCOM translates native binaries ahead of time. 02:47.240 --> 02:56.320 Because of this, RFCOM can achieve a much better power mass than CPU emulating base approaches. 02:56.320 --> 03:05.160 Currently, RFCOM supports the AX application, it is converting. 03:05.160 --> 03:12.320 So, next, I will show a demo, and in this demo, we are going to bash BV-box on the 03:12.400 --> 03:14.560 device in the browser. 03:14.560 --> 03:38.680 So, this, for BV-box applications, convert it to Wazun with RFCOM, so we can see that, thank you. 03:38.920 --> 03:48.400 This is a demo page on the WebAssembly, so you can try the demo on your own now. 03:48.400 --> 04:01.360 So, first, you can see that BV-box is executed on the browser, so this is a Google 04:01.360 --> 04:10.160 Bash on the browser, yes, of Ant, we can run some commands, for example, you name, 04:10.160 --> 04:23.800 so there is a PSA-UX, yes, and with PSA, we can see that, to processes running in the browser, 04:23.800 --> 04:35.760 but this commands come from BV-box, okay, so next, we run Python, we start the Python 04:35.760 --> 04:49.380 report, yeah, okay, so, okay, so, you can see that the binary information is a head 04:49.460 --> 04:58.020 trash, a main column, commit number, yes, so this shows that the sheet Python source code 04:58.020 --> 05:08.380 is not modified, and build sheet Python as re-acceptifications and component it into Wazun, yes, 05:08.380 --> 05:18.300 so if I modify the sheet Python source code, this message will be a head-shrush, main dirty 05:18.380 --> 05:33.300 column, commit number, yes, so, yeah, sheet Python runs in the browser without code changes, 05:33.300 --> 06:00.940 yes, so, I try to execute Python, for example, link, see W, and PID, yeah, okay, that 06:00.940 --> 06:20.940 is correct, yeah, so, and quit, okay, okay, so, and we can make a fire with BV-accomand, yeah, so, for 06:20.940 --> 06:40.980 example, print, okay, and save the fire, yeah, so, and the content is, print how they 06:40.980 --> 06:50.980 compile some, yes, so, if I try to execute this Python, yeah, they're out for this correct, 06:50.980 --> 07:08.180 okay, so, thank you, thank you, okay, so, I think this is the end of the demo, so, let's go back 07:08.180 --> 07:19.340 to the slide, okay, okay, so, and next, let me show the benchmark results, we compare three 07:19.340 --> 07:28.700 approaches, and the first is a source library generated by M script N, and the second is the 07:28.860 --> 07:38.340 applications running on the own content wasn't with QMU, and the source is the applications 07:38.340 --> 07:48.860 translated using LFCOMP, okay, so, we tested three benchmark programs, the first is prime 07:48.860 --> 07:56.900 number, calculation, and the second is a neural network that trains on the M list data set, 07:56.900 --> 08:04.460 and the third is, in fact, a floating point benchmark test, so, and this graph shows the 08:04.460 --> 08:13.400 power months ratio, and the first approach is set to 100%. Yeah, so, as you can see, the 08:13.400 --> 08:23.660 content wasn't as much lower power months, but FCOMP achieves about 60 to 90% over the source 08:23.660 --> 08:36.300 of the approach, this means FCOMP has smaller power months loss, okay, so, two supports, 08:36.300 --> 08:45.100 real reaction applications, LFCOMP must emulate the X system course in the browser, so, this 08:45.100 --> 08:55.420 is the most challenging parts of LFCOMP, yes, and many system course are sufficient to 08:55.420 --> 09:01.820 call the library, library function of M script N, for example, open, read, write, link 09:01.820 --> 09:09.820 out, try and get it, and so on, so, however, some system course implementation is not 09:09.820 --> 09:19.600 convenient, yes, so in particular process management, such as forcons, execvoy is essential, 09:19.600 --> 09:28.320 okay, so, and now, and of course support forcons execvoy, but I do the time constraints, 09:28.320 --> 09:36.880 And I will skip the implementation details here. 09:36.880 --> 09:45.200 Yes, so like this, a four-keys executed, the executable is executed. 09:45.200 --> 09:57.240 And also, that idea is that each Linux process is represented 09:57.240 --> 10:04.320 as a web worker managed by JavaScript, JavaScript, based on it. 10:04.320 --> 10:07.400 Yeah, that is like a main key. 10:07.400 --> 10:11.720 OK, so this is a feature work for us. 10:11.720 --> 10:19.320 We plan to improve the overall function hierarchy. 10:19.320 --> 10:29.680 Yes, so we still need to add more system core implementation. 10:29.680 --> 10:38.440 At the moment, we support only statically linked applications. 10:38.440 --> 10:45.600 And we would like to support the comparisons of Linux shared objects, 10:45.600 --> 10:51.520 as well as in addition, and the implementation of machine core. 10:51.520 --> 10:56.840 Translation is still in progress and support for X8664, 10:56.840 --> 10:59.320 is not concrete yet. 10:59.320 --> 11:02.960 That is a very hard work. 11:02.960 --> 11:10.200 Yeah, so on seconds, we plan to put the board restors. 11:10.200 --> 11:21.120 Yes, so we are considering improving the Python environment and putting a C or B. 11:21.120 --> 11:27.120 Yes, so if we have any good ideas, let me know. 11:27.120 --> 11:33.480 Yes, so we also welcome any issues or a full request for AirCom. 11:33.480 --> 11:44.040 So please check the repository. 11:44.040 --> 11:45.040 That is all. 11:45.040 --> 11:47.040 Thank you.