I ported LaTeX to Javascript • Hacker News Board

Re: I ported LaTeX to Javascript

#71

Post by simonster » Mon, Jan 21, 2013, 12:54 AM UTC

bzbarsky wrote: post #64

simonster wrote: post #33

Earlier quoted context omitted.

I've seen emscripten-generated JS crash Safari before. It's not a performance issue; jsc is plenty fast and beats SpiderMonkey in most benchmarks. However, emscripten seems to exercise certain corners of JS that pose stability problems for jsc.

Which benchmarks are you looking at? And are they actually JSC vs SpiderMonkey or JSC+WebKit vs SpiderMonkey+Gecko? I.e. are they JS benchmarks or DOM benchmarks?

"Beats" might be too strong a word :). I guess the picture from AWFY 64-bit is that both have strengths and weaknesses but overall they're comparable.

Re: I ported LaTeX to Javascript

#72

Post by rb12345 » Mon, Jan 21, 2013, 1:12 PM UTC

gmac wrote: post #69

Sephr wrote: post #62

Earlier quoted context omitted.

data: URIs are deprecated for generating content. Use object URLs and Blobs ( https://developer.mozilla.org/en-US/docs/DOM/Blob ). If you want to force saving the file to a disk use

Although, annoyingly, data: URIs are your only option in Safari (including the latest version), and they also happen to crash the PDF viewer. Safari does have createObjectURL, but then doesn't understand the URL it creates! Just as annoyingly, IE10 has createObjectURL too, but only allows the created URLs to be used for , and . To save a blob, you have to use something ms-prefixed instead, and this doesn't allow inli…

I suppose that pdf.js could be used for inline PDF viewing, but at the moment the Firefox 18.0 version idles at ~20% CPU.

Re: I ported LaTeX to Javascript

#73

Post by bzbarsky » Tue, Jan 22, 2013, 2:19 AM UTC

simonster wrote: post #71

bzbarsky wrote: post #64

Earlier quoted context omitted.

Which benchmarks are you looking at? And are they actually JSC vs SpiderMonkey or JSC+WebKit vs SpiderMonkey+Gecko? I.e. are they JS benchmarks or DOM benchmarks?

"Beats" might be too strong a word :). I guess the picture from AWFY 64-bit is that both have strengths and weaknesses but overall they're comparable.

Yeah, on that set of benchmarks (the one that everyone is targeting hence not doing anything obviously stupid on), they are.

The problem is that all of the JS engines involved have various failure modes in which they end up way slower than the others, though... We're talking 10x-1000x slower. And the problem with performance is it only takes your script hitting one serious performance bottleneck to make the speed of the rest of it not really matter. :(

Hence my interest in testcases that point out such performance cliffs, so they can be removed.