Windows 10: Microsoft Edge Chakra documentation is joining MDN web docs

Brink · Jun 26, 2018

Last fall, along with other browser vendors and web platform stakeholders, the Edge platform (EdgeHTML) team adopted MDN web docs as our official web API reference library. In the process, we redirected over 7700 MSDN pages for HTML, CSS, SVG and DOM APIs to corresponding reference content on MDN and joined the community in helping maintain it, including making over 5000 edits to the browser compatibility tables to reflect the latest Edge API surface.

Today the Microsoft Edge JavaScript engine, Chakra, joins the community-wide effort to make MDN web docs the web’s one-stop, premiere development reference, starting by redirecting all 500+ pages of Microsoft’s JavaScript API reference from docs.microsoft.com to their MDN counterparts and porting our legacy JS extensions reference for historical and servicing purposes.

We want to thank our community for enthusiastically embracing MDN web docs, and special kudos to everyone who helps to improve the docs, edit by edit. In the previous year alone, you helped the MDN web docs community grow monthly users by over 50%! Let’s keep documenting the web forward together.

– Erika Doyle Navara, MDN Product Advisory Board representative for Microsoft Edge
Click to expand...

Source: Chakra documentation is joining MDN web docs - Microsoft Edge Dev Blog

:)

Brink · Jun 26, 2018

Documenting the Web together with MDN Web Docs

Today, we’re excited to share some big news for developers around the world wide web: We’re committing our resources towards making MDN Web Docs the best place to go for web API reference. To kick things off, today we started redirecting over 7,700 MSDN pages to corresponding topics in the MDN web docs library powered by Mozilla.

In conjunction with similar commitments from Mozilla, Google, the W3C, and Samsung, we’re teaming up to make MDN Web Docs the best place for web developers to learn and share information about building for the open web.

MDN is a core part of Mozilla’s overarching mission: to ensure the Internet is a global public resource, open and accessible to all. We believe providing web developers the best possible information will enable them to deliver great web experiences that adhere to established standards and work across platforms and devices. We are excited to have Microsoft, Google, The W3C, and Samsung on board as we continue on our journey to make MDN the premiere resource for developers.

— Ali Spivak, Head of Developer Ecosystem at Mozilla
Representatives from each of these organizations will also be serving on the MDN Product Advisory Board, a committee dedicated to making MDN your definitive place for useful, unbiased, browser-agnostic documentation for current and emerging standards-based web technologies. The MDN Product Advisory Board is also looking for active individuals from the web community to serve on the board. If you’re interested, find more details on MDN web docs.

Web docs should just work for everyone

Redirecting our API reference library to MDN is the next step towards consolidating our compatibility info in the same place you probably already frequent for general web documentation. Earlier this year, we began the effort to backfill the MDN browser Compatibility tables with a column representing the Microsoft Edge browser.

Over 5000 MDN edits later, the entire web API surface of Microsoft Edge (as of the 10/2017 Windows 10 Fall Creators Update, Build 16299) is now documented on MDN, and will continue to be kept up-to-date with each new release of Windows and our EdgeHTML browser engine.

Example of a Browser compatibility table on MDN Web Docs

One of our guiding principles in developing Microsoft Edge is that end users should never have to worry about which sites work in which browsers. This philosophy—”the Web should just work for everyone“—led to our choice to target the “interoperable intersection” of web APIs in our browser engineering.

Just like with end users, we think it’s well overdue for developers to have a simpler view of web standards documentation. Developers shouldn’t have to chase down API documentation across standards bodies, browser vendors, and third parties—there should be a single, canonical source which is community-maintained and supported by all major vendors.

For these reasons we’re all-in on making MDN the home of web standards documentation. Not only is MDN a veritable encyclopedia and thriving community of all things web development, it’s also an institution in itself–a living monument to our collective history—as web developers and enthusiasts, web standards advocates, and browser engineers–of developing the web forward.

Documenting the web forward

MDN was founded over 10 years ago in 2005 as the Mozilla Developer Center and later become known as the Mozilla Developer Network. Just as the Mozilla Organization was founded out of Netscape, the Mozilla Developer Center grew from the original Netscape Navigator browser docs.

Similarly, the Internet Explorer Developer Center was first published online from the Microsoft Developer Network (MSDN) several years before that in the late 90s to help introduce and showcase Dynamic HTML (“DHTML”), Microsoft’s precursor to the modern DOM and CSS object model.

Microsoft Internet Explorer Developer Center on MSDN Online, circa 2000. Courtesy of the Internet Archive Wayback Machine

Fast forward to the modern web platform of today. The competing Netscape and Internet Explorer browsers from the bygone era of the early web are now subjects of tech archaeology, not site compatibility testing. From the final releases of IE culminating with the birth of Microsoft Edge, we replaced earlier Microsoft technologies with emerging industry standards–the modern DOM and ECMAScript standards for DHTML and VBScript, HTML5 for ActiveX, a common browser extension model for Browser Helper Objects (“BHOs”).

Through all this change, MDN has grown up alongside the web, and today has over 34,500 documents, 6 million monthly users and 20,500 contributors. From its initial Netscape product docs, the breadth and depth of MDN’s content has radically expanded to encompass the state of the art of modern web development—so much so that recently the site was restructured and rebranded to reflect MDN’s commitment to being a browser-neutral community resource. We are excited to join Mozilla, Google, The W3C, and Samsung in making MDN our home for web standards documentation and dedicated to helping it grow even further to meet your needs.

We will continue to maintain Microsoft- and Windows-focused documentation on Microsoft Docs (docs.microsoft.com/microsoft-edge), including Windows-specific test guidance, information on the Edge DevTools, and upcoming details about Progressive Web Apps in the Windows Store. And you’ll still find the latest Microsoft Edge status, changelogs, and news at our Microsoft Edge Developer site (dev.microsoftedge.com).

Please join us in supporting and contributing to MDN web docs! We’re all building this Web together; let’s document our hard work!

— Erika Doyle Navara, Senior Dev Writer
Click to expand...

Source: Documenting the Web together - Microsoft Edge Dev Blog

Brink · Jun 26, 2018

Bringing Asm.js to Chakra and Microsoft Edge

A couple of months back, we announced that we had started development on Asm.js. Support for Asm.js has been one of the top 10 most-requested items at the Microsoft Edge Developer Suggestion Box on UserVoice since we launched it in December 2014. Since that time, we’ve made good progress, and in Windows 10 Insider Preview builds starting with 10074, we are now previewing the early work that we’ve been doing to enable Asm.js support in Chakra and Microsoft Edge.

What is Asm.js?

Asm.js is a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. As a sublanguage, asm.js effectively describes a sandboxed virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ techniques like type specialized compilation without bailouts and ahead-of-time (AOT) compilation for valid asm.js code. Such compilation techniques help JavaScript execute at “predictable” and “near-native” performance, both of which are non-trivial in the world of compiler optimizations for dynamic languages like JavaScript.

Given the complexity of writing asm.js code by hand, asm.js is currently produced principally by transpiling C/C++ code using toolchains like Emscripten to run on the Web platform, utilizing technologies such as WebGL and Web Audio. Game engines like those from Unity and Unreal are starting to land early/experimental support of plug-in free games on the web using a combination of asm.js and other related technologies.

How do I experiment with Asm.js in Microsoft Edge?

To enable and experiment with the current Asm.js support in Microsoft Edge, navigate to about:flags in Microsoft Edge and select the “Enable asm.js” flag as below:

Engineering Asm.js into Chakra’s Execution Pipeline

To enable Asm.js in Chakra, the components marked in green below have been added or modified vis- -vis the typical code flow though Chakra’s pipeline outlined and explained in this blog.

Key changes include:

Addition of an asm.js validator, which helps Chakra identify and validate that the asm.js code adheres to the asm.js specification.

Generation of optimized Type Specialized bytecode. Given that asm.js supports only native types (int, double, float or SIMD values), Chakra takes advantage of the type information to generate optimized Type Specialized bytecode for asm.js code.

Faster execution of Type Specialized bytecode by Chakra’s interpreter by utilizing the type information to avoid boxing and unboxing of numeric values, and removing the overhead of generating profile data while interpreting. For non-asm.js JavaScript code, Chakra’s interpreter generates and feeds profile data to the JIT compiler to enable generating highly optimized JIT code. The type specialized bytecode generated for valid asm.js code already has all the data needed by Chakra’s JIT compiler to produce highly optimized machine code. The type specialized interpreter is 4x-5x magnitude faster than the profiling interpreter.

Faster code compilation by Chakra’s JIT compiler. Asm.js code is typically generated by using the LLVM compiler and Emscripten toolchain. Chakra’s JIT compiler takes advantage of some of the optimizations that are already available in the asm.js source code generated by the LLVM compiler. For example, Chakra’s JIT compiler avoids doing an inlining pass and takes advantage of code inlining that has been performed on the asm.js code produced by the LLVM compiler. Avoiding analysis for such JIT optimizations not only helps save CPU cycles and battery usage to generate highly optimized code, but also improves the throughput of Chakra’s JIT compiler tremendously.

Predictable performance by removal of bailouts from compiled asm.js code. Given the dynamic nature of JavaScript, all modern JavaScript engines support some form of migration to non-optimized code execution, called bailouts, when they determine that the assumptions made by the JIT compilers are no longer valid for the compiled code. Bailouts not only impact performance but also make it unpredictable. Taking advantage of type-safety restrictions posed on valid asm.js code, the code generated by Chakra’s JIT compiler for valid asm.js code is guaranteed to not require bailouts.

JIT Compiler Optimizations for Asm.js
Apart from changes to Chakra’s execution pipeline described above, Chakra’s JIT compiler has also been enhanced to take advantages of the constraints laid out by the asm.js specification. These enhancements help Chakra’s JIT compiler to generate code that could execute at near native code performance – the golden target for all dynamic language JIT compilers. Let’s drill into two such optimization techniques.

Helper and bailout call elimination
Helper or bailout code acts like a power backup for compiled code in dynamic languages. If any of the assumptions that the JIT compiler makes while compiling the code is invalidated, there needs to be fail safe mechanism to continue execution with correctness. Helpers can be used to handle un-anticipated situations for an operation, and control can then return to the JIT’d code. Bailouts handle situations where the JIT’d code cannot recover from the un-anticipated conditions and control needs to be transferred back to the interpreter to execute the remainder of the current function. For example, if a variable is seen as integer and the compiled code is generated with that assumption, the occurrence of a double should not impact correctness. In such cases, helper or bailout code is used to continue execution, albeit with slower performance. For asm.js code, Chakra does not generate any helper or bailout code.

To understand why, let’s take an example of a function square in an asm.js module, which has been over simplified to help explain the concept.

function PhysicsEngine(global, foreign, heap) {
"use asm";
…
// Function Declaration
function square(x) {
x = +x;
return +(x*x);
}
…
}

This function square in the code sample above translates to two x64 machine instructions in asm.js code, excluding the prolog and the epilog that is generated for that function.

xmm1 = MOVAPS xmm0 //Move native double value to a temporary register
xmm0 = MULSD xmm0, xmm1 //Multiplication

In contrast, the compiled code generated for the square function when asm.js is not enabled generates over 10 machine instructions. This includes:

Checking if the parameter is a tagged double, if not jump to a helper which handles conversions from any type to double

Extracting the double value from tagged double

Multiplying the value

Converting the result back to tagged double

Chakra’s JIT compiler is able to generate efficient code for asm.js by taking advantage of the type information of the variable, which cannot change through the lifetime of the program. The Asm.js validator & linker ensure the same. Given that all internal variables in asm.js are native types (int, double, float or SIMD values), internal functions freely pass native types without boxing them to JavaScript variables between function boundaries. In compiler terminology these are often called direct calls and avoid boxing or conversions when operating on data in asm.js code. Likewise for external calls into or from JavaScript, all the incoming variables are converted to native types and boxed while all the outgoing native types are converted to variables.

Bounds check elimination for typed array accesses
In a previous blog, we explained how Chakra’s JIT compiler supports auto-typed array optimizations, as well as hoisting of bounds check outside of loops thus improving the performance on array operations inside loops by up to 40%. With asm.js type constraints, Chakra’s JIT compiler completely eliminates bounds checking for typed array accesses for all of asm.js compiled code, regardless of the location (inside or outside loops or functions) or the type of the typed array. It also eliminates bounds checks for constant and non-constant index accesses for typed arrays. Together, these optimizations help bring near native performance when operating on typed arrays in asm.js code.

Following is a simplified example of typed array store at a constant offset and the single x64 machine instruction generated by the Chakra’s compiler for that code in asm.js.

int8ArrayView[4] = 25; //JavaScript code
[Address] = MOV 25 //Single machine instruction to store value

When compiling asm.js code, Chakra’s JIT compiler is able to pre compute the final address corresponding to int8ArrayView[4] during link time of asm.js code (first instantiation of the asm.js module) and hence can generate a single instruction corresponding the typed array store. In contrast, the compiled code generated for the same operation in non-asm.js JavaScript code results in around 10-15 machine instructions with path length being considerable. The steps include:

Loading the typed array from closure variable (typed array is closure captured in asm.js)

Checking if the closure loaded variable is indeed a typed array, and if not, bailout

Checking the index is within the length of the typed array; if any of the conditions fail, jumping to helper or bailout

Storing the value in the array buffer

The above checks are removed from asm.js code due to the strict constrains on what can be changed inside an asm.js module. For example, a variable pointing to typed array in an asm.js module is immutable and cannot change. If it does, it’s not a valid asm.js code and the asm.js validator fails to validate it as asm.js code. In such cases the code is treated like any other JavaScript function.

Scenario light-ups and performance wins from Asm.js

From the early work that shipped in the latest Windows 10 preview, we have started to see some great scenarios light-up apart from the performance wins by bringing asm.js to Chakra and Microsoft Edge. If you want to take it for a spin, try out games like Angry Bots, Survival Shooter, Tappy Chicken, or try out some fun asm.js demos listed here.

Ge6NZT9mbA8
Unity WebGL Player | Prime World Defenders

In terms of performance wins, there are a crop of asm.js benchmarks that are emerging. With the preliminary asm.js support, Chakra and Microsoft Edge now perform more than 300% faster on Unity Benchmark and around 200% faster on individual tests like zlib, which features in Google’s Octane and Apple’s Jet Stream benchmarking suites.

Unity Benchmark scores for 64-bit browsers (Click to enlarge)
(System info: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (4 cores), 12GB RAM running 64 bit Windows 10 Preview)
(Scores have been scaled so that IE11 = 1.0, to fit onto a single chart)

So, what’s next?

This is an exciting step towards bringing asm.js to the web platform underneath Microsoft Edge. However we are not fully done yet. We are working on fine tuning Chakra’s pipeline for ASM.js support – gathering data to validate if the current design approach performs well for real world asm.js payloads, understanding and addressing outstanding performance, functionality and tooling issues etc. before enabling this feature by default. Once enabled, asm.js would not only be available in Microsoft Edge, but would also be available in Windows store apps written using HTML/CSS/JS as well as Web Views that target the new EdgeHTML rendering engine that is shipping with Microsoft Edge in Windows 10.

We’d also like to thank Mozilla, with whom we’ve been working closely since we started developing asm.js, and Unity for their support and partnership in helping bring asm.js to Chakra and Microsoft Edge. And a big thanks to all the developers and users of Windows 10 and Microsoft Edge, who have been providing us with valuable feedback in this journey. Keep it coming! You could reach us and let us know your feedback on Twitter at @MSEdgeDev or on Connect.

– Abhijith Chatra, Senior Software Engineering Manager, Chakra
– Gaurav Seth, Principal PM Manager, Chakra
Click to expand...

Source: http://blogs.windows.com/msedgedev/2...microsoft-edge

Brink · Jun 26, 2018

Microsoft Edge Web Summit May 5th and 6th, 2015 - Watch Live Here

Join the team behind Microsoft Edge as we present the latest updates to our roadmap, the EdgeHTML rendering engine, and the Chakra JavaScript engine. Then enjoy our fantastic lineup of guest speakers as they share their expertise on modern web technologies like ES6, SVG, WebGL and WebAudio.

Starts at 10 AM PDT.
Click to expand...

Watch live: Microsoft Edge Web Summit 2015 | Channel 9

Information:

http://devchannel.modern.ie/websummit2015

Announcing the 2015 Project Spartan Web Summit, May 5th and 6th in Mountain View, CA

Sessions: Microsoft Edge Web Summit | May 5th and 6th, 2015

[edge][/edge]

Windows 10: Microsoft Edge Chakra documentation is joining MDN web docs

Microsoft Edge Chakra documentation is joining MDN web docs

Microsoft Edge Chakra documentation is joining MDN web docs

Microsoft Edge Chakra documentation is joining MDN web docs

Microsoft Edge Chakra documentation is joining MDN web docs - Similar Threads - Microsoft Edge Chakra

Microsoft Edge supporting Open Web Docs to deliver web developer docs

Microsoft Edge – will not connect to the web

Web Notifications in Microsoft Edge

ES2016 Async Function support in Chakra and Microsoft Edge

Documenting the Web together with MDN Web Docs

JavaScript performance updates in Microsoft Edge and Chakra

Microsoft Edge and Web Components

Share Web Pages in Microsoft Edge

Bringing Asm.js to Chakra and Microsoft Edge