That seems really bizarre! A puzzle that small should have no issues, and that hardware sounds relatively good. I’m going to assume you don’t have other things running (if you did, possibly worth verifying that none of those are causing issues). Beyond ye olde “turn it off and back on again and see if it helps”, the main thing that comes to mind is ensuring hardware acceleration is enabled in your browser - if not, this means that rendering is happening on your CPU instead of your GPU, which could bog things down (though I’d be surprised to see it be this bad).
Verifying this will depend on your browser - on Chrome you can go to
chrome://gpu and see what’s listed next to “WebGL” and “WebGL2” under " Graphics Feature Status" (both should say “Hardware accelerated”), and in Firefox you can go to
about:support and look at the “Compositing” field under “Graphics” (I think it should just say “WebRender”, though I’m not 100% sure if this is the same on different systems).
As far as answering your later questions directly: There’s no preferred browser, other than it should be relatively recent/up to date (no IE support ). It will likely only take advantage of a single core (due to a combination of how browsers work, how the code is architected, and just the type of operations we have to perform). As mentioned before, it will also take advantage of your GPU.
Running a small, basic puzzle in Chrome, the entire browser uses a couple hundred MBs of RAM (most of which is just Chrome’s baseline) and <10% CPU (I have an i7-8750H). This of course changes significantly with the size of the puzzle - recent labs with a couple thousand bases are much more resource intensive - though we’ve recently done a fair bit of work to improve performance (it’s waaaay better than it was before this summer). If it’s of any interest, to give a bit more context, there’s two main areas that impact performance:
- Rendering, that is, displaying the graphics on the screen. Issues here would be noticed when just letting the puzzle idle, zooming, dragging, changing from target to natural mode, etc. There’s two parts to this.
The first one is figuring out what goes on the screen where - most notably, this happens whenever the structure changes (eg, changing between target and natural mode, or if you change a base that alters the natural structure while in natural mode), the positions of all the bases have to be recomputed (and, when using our new annotations feature, the locations of annotations also need to be updated). This is what we have the most control over, and where we’ve had the most issues in the past.
The other aspect to this is actually drawing the objects on the screen - this is mostly handled by the library we use (PixiJS), which wraps an underlying technology called WebGL, which is what takes the images of the bases, instructions for drawing basic shapes like the base rings, etc. and actually turns that into the final image - this is the bit where the GPU is important.
- Folding, that is, taking your sequence and predicting the natural mode structure. Issues here would be noticed particularly whenever you mutate a base. We rely on software written by other research groups to do this part.
Here we’re very much limited by the efficiency of the algorithms - conventional packages like Vienna, NUPACK, and Contrafold/Eternafold use algorithms that are exponentially slower the longer your RNA is - this is due to the nature of the problem (it essentially has to try every combination of bases!). LinearFold is special in this regard - it doesn’t slow down as quickly (specifically, in linear time rather than exponential) as the length of the RNA grows. It does this by basically making some decent guesses that allow it to throw out/not check most of the options.
These algorithms also can’t (or at least, can’t easily) be made parallel, so even if we could take advantage of multiple cores, or a GPU, or a ton of servers in the cloud, it currently can’t be made to run much faster just by throwing more resources at it - it’s mostly limited to the speed of your CPU.
I’ve thrown a bunch of technical jabber in there largely for fun, but do let me know if you have any other questions or if I can clarify further.