It's not part of the website. It's an unlinked html page that is reachable thanks to google. I'm wondering, for how long Mark is going to benefit that page to keep saying "cracked" JXcore again?
is there any link from any of the jxcore pages to that year old page ? It even says that download Beta 2... What beta 2 is that?
https://github.com/jxcore/jxcore is the place (as you and he already knows) we publicly give out the source codes. Even a new graduate can see what's been going on. Hey.. it's visible there is nothing to crack.
This is so dumb cheap Mark! This is an open source project and everything is open in the wild while we stated several times there is no source code protection on our Github page.
Second time you are doing this the same cheap way. Congrats!
Yet this is just a declaration for now, we do not have any intention to keep it closed source. There is no need to trade stability with speed since most of the 'current' performance difference with JXcore comes from less amount of JS <-> native switches and better memory management. Very soon we will be open sourcing it! Thanks
Wondering something a little bit close to strong AI and how it could be .. "The robots already have some autonomy and can make decisions about taking steps and moving their joints, McKenna said. However, a human will still supervisor the robot and will control the machine from a safe distance and make decisions about whether the robot is ready to take on its next task."..
At what part I said that Its all done over a weekend?
from the post "..Last weekend I could finish the prototype and measure the initial performance of the solution.."
If you still understand that it's all finished over a weekend. No way.. I don't think it is easy to develop a LLVM frontend with those features over a weekend.
If you could have some details on LLVM, you wouldn't accuse me on something you miss read.
Because;
There is no such an LLVM JS engine. LLVM has its own IR and that prototype turns the JS codes into a wrapped LLVM IR.. As a result the final code functions at native level, so it is already fast.
For this reason, 20% or more performance difference because of LLVM actually shows how V8 is fast! It doesn't show the prototype is over a weekend or anything else..
> Maybe you don't have a case but there are many scenarios can benefit from multithreading including web hosting.
> The goal is to have a zero compatibility issue and we are almost there with the next beta.
> I believe that the node developers would enjoy benefiting from load aware instance monitored processes instead a trivial multi processing. BTW, still you can combine multithreading with multiple processes in case you want to keep process is active during v8 is GC'ing on one of the threads.
It doesn't change anything for javascript modules. On the other hand, we already embedded most popular c,c++ modules internally (with multithreading in mind) (coming with next beta)
Besides, making a native c,c++ module multithread compatible will be mostly changing couple of lines of code. We were working on a wrapper and it will be part of beta 2 also.
Thanks for the comments.
>JXCore allows you to run x number of tasks in parallel where x is the number of CPUs?
You may have a 8 cores but configure JXcore to use 64 threads.
> The problem is solved by running multiple node processes, which is standard deployment for node
You can still run multiple node process but 2 threads per each. This will improve the responsiveness of each process by balancing the load exactly on the native side. That means, if anything happens on one of the V8 threads (GC etc). the other one will be handling the load.
> That said, how well is each thread isolated from everything else.
Totally isolated. We already started to update native c,c++ modules for isolated multithreading.
>Does an uncaught exception kill just the thread and its state, or does it kill the process?
On this very beta release, it throws into main thread (when it's uncaught by thread) but coming beta (internal monitoring is implemented) will be optionally resetting the sub thread itself.
You may simply consider each thread as a separate node.js host.
Considering the fact that nothing yet optimized on the prototype side, it's fair to have a such benchmark since the test cases are complicated enough for a prototype. Indeed V8 performs quite well. The project is under development and only time will show whether they are exaggerated or not.
I'm aware of that patent long before and not following the same structure. Besides, it also targets other languages by saying 'Javascript or similar'. No worries here. Thanks for reminding.
I didn't mention clearly since it wasn't a big part of the picture. Dynamic Type part was a bigger problem! Right now I prefer a separate thread for GC but I have also couple of bad cases for this kind of garbage collection. I don't think there is a 'one perfect GC for every kind of usage'. But my focus is performance consistency. Sorry for passing it on my post. I added a side note saying (GC thread).