Slow GUI (at least on WIndows)
System dynamics program with additional features for economics
Brought to you by:
hpcoder,
profstevekeen
I'm just wondering what it is that makes Minsky so slow to run a simulation when there are many screen objects to update? It's also incredibly laggy when trying to pan with the mouse or zoom, etc, when a larger model is used. Whilst this is more of a problem with larger models, the size of the model is still very small compared to the size of the canvas. To make it run smoothly does it just require a faster CPU or GPU or is it
I've tried on a couple of different laptops with onboard GPU. Currently on an i5-7300U dual-core @2.60GHZ, 8MB RAM running Windows 10.
Does it run any better on linux? I've spent several hours installing a linux dual-boot and trying to install minsky with no success. I tried following the instructions in the discussion forum but there's always errors. Just a reminder to myself of why I stick to windows I guess, but that's all an aside.
On Thu, Jun 28, 2018 at 01:42:26PM -0000, Nick Jackson wrote:
8MB sounds a little tight, I'm guessing you mean 8GB.
I doubt a GPU will help at all with Minsky. The rendering is done
using the Cairo library, which does exploit SSE etc instructions, but
not the GPU IFAIK.
I'm not whether it runs better on Linux. On my setup, Linux is native,
and I have Windows 10 installed on a virtual machine. You'd expect in
such a setup that Windows 10 version would run slower, as there's an
extra layer of indirection, converting the VGA graphics calls into
Xlib calls, which are then rendered via X-window server on Linux. But
in practice, I haven't noticed Windows as being markedly slower, but
then I haven't really gone looking either.
Where there is a big difference is in file I/O. Windows has a
notoriously slow file system - a factor of two at best, sometimes an
order of magnitude slower, depending on what you do - as compared with
Linux. But that shouldn't affect Minsky, which is not doing much in
the way of I/O.
What is slow is MacOSX. Macs might be friendly to users, but it's the
most goddamn awful pig of a system to try and program. It's hard
enough to just get stuff to work, let alone figure out ways of making
it run faster.
There are some things you can do to ameliorate the situation.
When running a simulation, you can increase the number of time steps
per iteration, which dials down the rate at which the display is
updated. Unfortunately, the plots end up being more discretised, which
I need to fix.
In version 2.7, I dialed down the amount of rendering done with the
panopticon, which helps panning and zooming in big models. I have also
added turning off the panopticon in the preferences panel, but this
hasn't been released yet. You'd have to build for source code to get
that feature :).
Effectively using grouping. Items contained within a group are only
rendered at high zoom levels
More plans are:
Not draw items off the screen. Making the window smaller should
improve the panning/zooming performance. The code is there, but
looking at it, I don't think it is working correctly. This wasn't an
issue with Minsky 1.x, as that optimisation was already provided by
the Tk Canvas object used in that version.
Have an option to turn off animation of variables and operators
whilst running simulations, leaving just the plots updated every
iteration.
Modern linux distros are remarkably easy to install and set up. Easier
than installing Windows (which is not too bad), and way, way easier
than MacOSX, which is incredibly difficult once you've wandered off
the path of buying shiny new hardware from Apple.
I'm usually on OpenSUSE Tumbleweed, but have had good experiences with
Fedora and Ubuntu in terms of installation experience (though I
personally find using them a bit confusing, as all the usual Linux
stuff is hidden, a bit like Windows :).
If you want to go down that path, I suggest you download a Virtual
Machine system, and install your Linux distros into that. I can
recommend VirtualBox. The advantage is that VM provide very standard
hardware that all OSes know how to support, so everything works out of
the box. Eg I've had very few problems with Windows 10 in a Virtual
Machine, far less than what my friends complain about when running
Windows 10 on actual hardware.
Cheers
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
It sounds like it would be quicker.
It wasn't installing linux that was the problem it was installing Minsky and not having the dependencies and then when trying to follow the steps in the other forum post some of the dependencies there are no longer found by apt, etc, etc. Maybe I'll try again another day. It would be nice just for Minsky to take care of all that in the install but I guess most linux users are experienced with all this and it's not a problem.
I didn't want to use a virtual machine as I thought that the problem with Minsky was screen updating and that it might be worse through a virtual machine.
On Sat, Jun 30, 2018 at 02:23:03PM -0000, Nick Jackson wrote:
I hope you were trying to use my packages at OBS home:hpcoder1. The
package managers will find all the dependencies if you follow the
instructions on the OBS website for your particular release of your
distro.
That said, it is not actually tested that the installs will work! For
instance, around a month ago I removed the tktable project, since it
is no longer needed as of Minsky 2.1. I removed the reference to the
dependency from the spec file (which builds RPMs), and also from
minsky.dsc and debian.control. The trouble was, I missed a 3rd
reference to the dependency in the debian.control file. Honestly, the
Debian package specification files were designed by a committee.
That is probably the error you ran into, which has now been fixed.
But this raises a bigger question of whether it is possible to set up
a Continuous Integration system for testing OBS output. I'm starting to
explore docker as a way of solving some other problems with TravisCI
(Ubuntu 14.04 is really showing its age) - maybe I can set things up
to test distro installation and a runtime smoketest using Travis and Docker...
In the meantime if anyone else is reading - if you notice a problem
with Linux installation of Minksy - please let me know, and I can
investigate. I won't know otherwise that there's a problem.
I know - it is a way of trying out new Linux distros without getting
tangled up with hardware support issues - but it seems you were well
beyond that point anyway.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
Well I was trying to manually install it initially. Indeed, now using the debian package I get the error for the reference to tktable. So presumably I should wait for version 2.8 in which that error will be fixed and I'll be able to install the linux version that way?
never mind. I managed to extract the package, edit the control file, make the package again and install it.
It's not really any faster than on windows. Zoom and bookmark buttons still make all the objects disappear and panopticon still not working. At least it was worth a try.
On Tue, Jul 03, 2018 at 09:22:49AM -0000, Nick Jackson wrote:
There are some improvements coming in 2.8, including the "zoom to fit"
feature you suggested.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
On Tue, Jul 03, 2018 at 09:02:35AM -0000, Nick Jackson wrote:
I fixed that 5 days ago. Still version 2.7, but there should be a bump
in a minor package version number by OBS. Were you trying to use a previously
downloaded version? Try using apt get to get the latest
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
I don't have Linux, I have two computers with windows - one is 8 years old and other is 3 years old- and noticed that models runs faster on better computer. I mean, it takes shorter time to reach, in example, t= 10, 50 or 100 years. I supposed graphics is slowering software - too many charts and running numbers, especialy if you have onboard GPU. But I have downloaded some older heavy model and scrolling is difficult even without button "run" pressed. So maybe it is not because of graphics. Maybe the problem is that model is entered in older version 1.X and damaged when converted to 2.X? Or maybe the problem is scrolling function itself.
I wouldn't like this software to look like rough statistical software without graphic interface. If it would be the case, in my opinion, it would be better to do that, with future development, on third, fourth or fifth tab with an option to freeze these graphic tab.
We could download here some larger model and measure how much time it takes for it to go to the, in example, t = 10, 50 or 100 years on different computers and systems.
Last edit: Kresimir 2018-06-28
As an adendum to my last post, I installed Minsky on a VM copy of Ubuntu 17.10, as well as one installed on Windows 10. Both at Minsky 2.7. I then loaded Pedro Patas's benchmark model (to date, probably the biggest, most complex Minsky model). Then I panned it away from the starting point, then timed how long it took for Minsky to rerender the model after pressing the "Reset Zoom" button, by counting "dead dogs" (ie roughly in seconds). The Ubuntu version took just under 3 dead dogs, whereas the Windows version was about 7. The only other difference in hardware was that the Windows VM had 2 virtual cores and 4GB of RAM, whereas the Ubuntu one had 1 core and 1 GB RAM. I don't think that difference is significant, however, as Minsky doesn't really exploit parallel processing.
So the initial conclusion is that the Linux build of Minsky is perhaps twice as fast as the Windows one. However, it is possible that Virtual Box has "pass through" optimisation of the XLib calls in the Ubuntu case that it can't do with the Windows one. The only way to really tell is to repeat the experiment hosting the VMs on Windows. Sadly, I don't have a native Windows box I can do this on, and you can't run a virtual machine on top of a virtual machine (I tried - the software just doesn't let you).
Last edit: High Performance Coder 2018-06-29
PS the virtual machines above were hosted on my Broadwell-based NUC, with 16GB physical memory, i7-5557U dual core CPU @ 3.1GHz.
PPS - when trying the same experiment natively on the host machine, running OpenSUSE Tumbleweed, the performance was indistinguishable from the Ubuntu VM - ie just under 3 dead dogs.
I downloaded log simulation 5 file from this page. https://github.com/highperformancecoder/minsky-models/tree/master/PedroPratasThesis
I could not even run it and have problems with uploading icons and scrolling before run button pressed. I believe that file has some problem within itself. Some paramaters are not properly wired which can be seen on movie. Or maybe in version 1.x some operator had one inputs and in version 2.x has two inputs causing problems. Graphic card is integrated Intel HD Graphics 4400, Windows 7 Professional 64 bit, Intel Core (TM) i3-4130 CPU 3,40 GHz, RAM 4 GB.
That file cannot be graphicaly more demanding than some movie or computer game. And problems occured before run button pressed.
Admittedly a bit laggy when panning, but appears to run OK on my
computer... With Minsky 2.7/OpenSUSE Tumbleweed/i7-5557U/Intel HD
Graphics (6000?) ...
I increased the max step size to 0.03 so as to see something
interesting happening...
I do believe there is some low hanging fruit in terms of rendering
performance, but its always about priorities, and up until now, people
haven't been doing anything complex enough :)
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
.
For recording I use Icecream Screen Recorder which is without adds and free up to 5 minutes of video.
Also when that file opened, it takes much time for icons to appear on screen. Maybe one or two minutes.
But I managed to run this file succescully few times on same computer and it runs very slow.
Last edit: Kresimir 2018-06-29
On Fri, Jun 29, 2018 at 06:30:38AM -0000, Kresimir wrote:
About 10 seconds for me for the NUC...
On my laptop - a 2010 netbook with 1.6GHz Atom processor, just a
fraction over 1 minute to load and render. This is a slow machine,
already more than 8 years old, and considered barely able to run
windows at the time, but has happily run OpenSUSE its entire
life. Your machine ought to do much better - maybe not as well as the
NUC - but much better than my laptop.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
I also downloaded Benchmark model and waited more time afer icons appeared on screen. Software was doing something. I could see that mouse pointer turned to circle about every ten second. After I waited more time that model runs but slowly.
.
I didn't notice "time unit" in Runge Kutta before. What for is that?
Benchmark model step size 0.01. He setted step size to 0.003 which is very small. I waited more time to upload icons but also had some problems when I was trying to move something or scroll.
After about one minute of uploading mouse pointer turning to circle every eight seconds. What software is doing at that time?
Getting back on topic then. Is it Cairo that is the underlying issue? I feel like ultimately to move into a serious use-case scenario Minsky must be able to deal with larger models. Would moving to a more GPU-based solution help? I imagine that would involve serious re-coding? As the model I'm currently working on has grown I've slowly become accustomed to clicking once and waiting for the reaction but if I were to just send it to somebody to have a look at they may become frustrated and just give up which would be a shame.
On Tue, Jul 03, 2018 at 11:40:58AM -0000, Nick Jackson wrote:
As I mentioned, there is some low hanging fruit in getting the canvas
to render faster - in particular to avoid rendering items offscreen by
caching their sizes. I don't suspect cairo itself of being slow - it
is SSE acelerated, and forms the basis of the Gecko rendering that
Mozilla/Firefox uses IIUC.
Absolutely we need to handle larger models, so keep 'em coming. Also
important is the use of grouping to manage larger more complex models,
which until now nobody has really used much.
Cheers
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au