Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I understand modern browsers' JS engnines (like V8, Spidermonkey, Chakra, etc.) use thread pools internally, even though only a single thread (running the event loop) is exposed to a JS programmer.
Obviously, the (rarely used) Web Workers require multiple threads (or multiple processes) - otherwise they couldn't utilize multiple CPU cores. My question is, apart from Web Workers, what is the benefit of implementing JS engine with multiple threads?
Why couldn't JS engine remain always single-threaded by internally relying on the same event-loop that the JS programmers use, using non-blocking OS calls whenever it needs to do any IO?
To clarify: JS engine uses a thread pool even if the user opened just one window with just one tab.
Edit: this is answered here
There are many parts of a script engine that benefit from parallelisation, as they can run concurrently for different parts of the script or in relation to each other:
parsing
compilation
JIT, optimisation
debugging/logging/profiling
garbage collection
graphics
And that doesn't even involve sharing between multiple instances of the engine for different usage environments (worker scripts, browsing contexts).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
This is a question of interest, There are a number of interpreted languages that can be used to create an OS, Can one create an Operating system using PHP or JS.
It does not have to be a fully-fledged OS, at least the one that prints Hello World.
Regards
All three of those languages are Turing-complete, so they can simulate any other Turing-complete language. An operating system written in one (or a few) Turing-complete language can also be written in another, assuming that sufficient access to the underlying hardware is provided.
Whether such a thing could be made to be run any any reasonable speed is another matter entirely.
The number of things you can do in programming is virtually limitless, but many of those things require a lot of effort.
The main purpose of an operating system is to provide an interface between application programs and the computer hardware, often abstracting away details. In order to do this, the OS code must be able to access the hardware directly (or almost directly, e.g. by calling BIOS functions).
High-level languages like PHP and JavaScript don't have any mechanisms to do this. They depend on an operating system to provide access to hardware at a high level: files, network sockets, etc.
These languages do allow you to link in extension libraries, which give them extra capabilities. But then you're not actually writing the OS in these languages, you're writing it in the language that the extension is written in.
I don't think even C can be used to write an OS if you just stick to the portable features of the language. Operating systems written in C depend on implementation-dependent features such as casting integers to pointers, they use extensions like asm(), or they occasionally link with subroutines written in assembly, on order to get direct control of the hardware.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Given that V8 execution of ES6 code is slower on some operations, compared to ES5.
According to this: http://incaseofstairs.com/six-speed/
Can anyone point to an article/paper/post where tests were performed in order to find out if such performance difference will impact in the normal operation of an API developed with node.js?
Should I use ES6 or greater to build a node.js API, considering it is slower to ES5?
That's a false premise right off the bat, as demonstrated by the chart you linked to.
No, this is not "premature optimization"
Yes, it is. Choice of language dialect is much more about ease of development, compatibility with libraries, and reliability. There is nothing in common implementations of ES6 that are "slower" across the board. You haven't even built your application yet, and you're worried about something that is unlikely to make a significant impact at all.
If you find that there some particular code that could be optimized, Node.js allows you to implement native binaries where you can optimize all you want.
I know some may wonder, if the API is going to get millions of hits, but again, I'm more interested in the correct pattern to use.
Use ES6.
In the back-end, we're talking about hundreds or thousands of clients, and that performance hit will be compounded.
And yet, you don't even know what the pain points are in your application because you haven't built it yet. For most applications, it's going to come down to I/O.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In relation to this stack overflow question, I'm wondering what the typical use-cases are for compile-to-JavaScript tools. I've done some research and I've found a list of programming languages that compile to JavaScript, many of which are strongly-typed.
Emscripted and ASM.JS are typically used for for processor intensive tasks. Is this the primary use case of such tools, or is this dependent on the tool?
For the most part it is dependent on the tool. Libraries such as asm.js offer low-level complex functionality and enhancements that most people would not be able to implement themselves. This is the basis for most libraries, it brings the saying "Standing on the shoulders of giants" to mind.
CoffeeScript and TypeScript are dialects of JavaScript that offer people the option of writing in a language that has features they are accustomed to in other languages (like static typing). They can then compile their CoffeeScript code to JavaScript for use in a web browser.
I hope this gave some insight into your question.
Can compile-to-JavaScript tools be used for “regular” client-side development?
Coffeescript / TypeScript -> Yes. In fact that is on of their main
target audience.
Asm.js -> Depends on how you define regular. If creating a quake clone in the browser is regular for you then yes. If creating a standard SPA (angular/react/ember etc) is regular then no, asm.js is not targetted at you
I think most or all of those "languages that compile to JS" don't have anything to do with ASM.JS. ASM.JS is a very limited subset of JS that only runs assembly-style commands on a block of memory.
The main reason for doing so is performance, yes, since you can't directly access DOM and other handy browser objects directly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There is no universal bytecode for JavaScript, but most JavaScript engines have their own bytecode. Since JavaScript files travel as source code string, they have to parse/compile source code string into bytecode at before execution.
However, as we can specify a user agent type (e.g. browser type and version) in HTTP request, can't we make the server keep bytecode for each browser and respond accordingly to save some time at client?
What's preventing us from taking this approach? I don't think browsers will have no problem even if some JavaScript files are given in bytecode and others in source string. Similarly, we have .pyc files in Python, and it runs well with .py files.
[Update]
Potential benefits I can think of are below.
You could save parsing time at client. Parsing is fast, but it may be worth to do it for low-end devices.
You could put some hints in bytecode. For example, JavaScriptCore (WebKit's JavaScript engine, JSC for short) patches bytecode with information gathered during runtime, such as types. JSC's bytecode is designed in a way that it has slots for such information.
In terms of maintainability, the server can always send the original source code string if the client's browser is unsupported, and there are not so many different JavaScript engines. Supporting four most popular browsers (Chrome, Firefox, IE and Safari) seems feasible to me. In addition, I don't see bytecode instruction set changing frequently.
All engines would need to make their byte code format public
The server would need to hold very many different byte code files, or even compile them on the fly
Browser detection is fraught with peril (user agents lie, proxies cache)
Bytecode rules might change between minor versions of a browser
The performance gains probably wouldn't be all that significant (especially when compared to network transfer times)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
According to this discussion, the iphone agreement says that it doesn't allow "loading of plugins or running interpreted code that has been downloaded".
Technically, I would like to download scripts from our server (embedded in a proprietary protocol).
Does this mean I wouldn't be allowed to run a runtime like v8 in an iphone app?
This is probably more of a legal question.
I think your interpretation is correct - You would not be allowed to download and execute JavaScript code in v8.
If there were some way to run the code in an interpreter already on the iPhone (i.e. the javascript engine in MobileSafari) then that would be permitted I think.
This is partially a technical question too. V8 as currently implemented won't run on the iPhone. No JIT-based VM will.
Well I embedded Lua into my application already and am programming most of the login in Lua and then downloading it to my iPhone for fast iteration, but this is only intended during development. Once I ship the scripts will be placed in the source and compiled into byte-code shipped along with the app just like any other resource.
I'd say this applies to V8 aswell.
I concur. My reading is also that DOWNLOADED scripts are not allowed. Pre-installed and user-written scripts are fine. But it is a fine distinction and IANAL etc etc.