[Nottingham] Linux VM performance

Wed May 18 10:57:52 UTC 2016

Ah, that explains why VirtualBox is needed then. Do they still do a free 
version of VMware? Not that I expect there's much difference in performance 
between the two. 
I'm not sure what the quickest performing distro is, actually. As far as 
desktop environments go, Ubuntu Unity is noted as being quite bloaty. You 
could try lxde (lubuntu), maybe? 
Neal. 

--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

18. May 2016 11:44 by nottingham at mailman.lug.org.uk:

> Hi Neal,
> Unfortunately I'm torn somewhat. I end up having to work on a Windows 
> machine a lot of the time (blame work), who are very strict about me not 
> installing a 'native' Linux installation.
> On the other hand, I have a rather nice MacBook at home which doubles as my 
> home server. I've tried Linux on it before but it performs poorly in 
> comparison to Mac OS as regards battery life and user experience - things 
> like hardware not being supported and the trackpad working in a weird way.
> As a result I make almost exclusive use of VMs for my Linux stuff.
> Daryl.
> On Wed, May 18, 2016 at 11:38 AM, Neal Ponton via Nottingham <> 
> nottingham at mailman.lug.org.uk> > wrote:
>
>>           >> Daryl, 
>> A lot of that went over my head, but have you tried using kvm instead of 
>> VirtualBox? I'm assuming you're using Linux as a host system, here. I've 
>> recently started messing about with kvm and it's renowned to have better 
>> performance, since the VM plugs into a kvm stub in the host kernel, which 
>> apparently reduces the amount of abstraction needed and runs close to 
>> 'bare metal' speeds. 
>> I also learned that you can bring up a terminal in the client machine by 
>> simply using 'virsh console....'. This was after messing about needlessly 
>> setting up ssh server! :-) 
>> Neal. 
>>
>> --
>> Securely sent with Tutanota. Claim your encrypted mailbox today!
>> https://tutanota.com
>>
>> 18. May 2016 11:30 by >> nottingham at mailman.lug.org.uk>> :
>>
>>
>>> WARNING: Random meandering follows...
>>> I have a talk tomorrow evening. I have absolutely nothing to show yet.
>>> However, I have been having AWESOME (I spend too much time around an 
>>> American) fun tidying up and rejigging my performance analysis. I did a 
>>> talk on this last year.
>>> It's a simple scheduling algorithm so all tight loops and floating point 
>>> maths. It SHOULD suit JITs very well. The code size is small enough that 
>>> it will fit into CPU caches.
>>> The code is as identical as possible across languages. I'm generally 
>>> avoiding code that is too idiomatic; however, I'm using immutable 
>>> structures where possible and recursive techniques in those languages 
>>> that support it. I'm writing everything out to the terminal to stop those 
>>> clever lazy languages avoiding calculating anything (I'm looking at you 
>>> Haskell!)
>>> Results below:
>>> Blitzmax: 0:24.87 real  23.99 user  0.24 sys
>>> Monkey-X: 0:15.84 real  15.17 user  0.24 sys
>>>  C# Mono: 1:01.38 real  58.84 user  0.83 sys
>>>      C++: 0:12.73 real  12.05 user  0.21 sys
>>>  Clojure: 1:01.01 real  62.52 user  1.01 sys
>>>        D: 0:32.22 real  31.98 user  0.15 sys
>>>  F# Mono: 0:58.05 real  57.32 user  0.52 sys
>>>       Go: 0:23.41 real  23.19 user  0.17 sys
>>>  Haskell: 0:38.96 real  38.27 user  0.50 sys
>>>     Java: 0:30.41 real  30.43 user  0.25 sys
>>>    OCaml: 0:43.50 real  43.19 user  0.20 sys
>>>  Python2: 4:46.03 real  282.67 user  1.43 sys
>>>  Python3: 4:26.41 real  264.80 user  0.72 sys
>>>    PyPy2: 0:16.76 real  16.11 user  0.20 sys
>>>    PyPy3: 0:32.44 real  31.34 user  0.34 sys
>>>     Ruby: 2:31.46 real  149.54 user  0.54 sys
>>>     Rust: 0:12.47 real  11.94 user  0.14 sys
>>>    Scala: 0:31.63 real  31.25 user  0.66 sys
>>> Ignoring the first two rows (which are proprietary game BASICs, but great 
>>> fun for chucking together graphical demos), then the most interesting 
>>> results are that Rust is quicker than Boost C++ and that PyPy is very 
>>> nearly as quick as both.
>>> I'm not comparing against .NET C# and F#. I would expect those to perform 
>>> much quicker, but of course they don't run on Mac OS/Unix/Linux! I would 
>>> imagine C# would be in the 20-25 second range.
>>> Anyway. that wasn't the point of my email. I was setting up a VirtualBox 
>>> VM to package all this up and so installed the latest Ubuntu (as I like 
>>> to try new shiny stuff). Performance was really poor. Ubuntu has always 
>>> been a bit graphics heavy and the acceleration isn't so good in 
>>> VirtualBox it seems.
>>> So I'm going to do what I've done many times before and install a 
>>> non-graphical Debian. I can run Emacs through there for code editing and 
>>> Synaptic for package management. I can flick between virtual terminals 
>>> with Ctrl-Alt-Fn (IIRC) and configure it to run a decently high 
>>> resolution using GRUB.
>>> It sounds like an interesting experiment. How productive is it possible 
>>> to be using the terminal? In the modern world of HTML emails and 
>>> web-everything, it seems impossible to be productive (I'm not talking 
>>> sysadmin activity here). Email? Word processing using Latex? Spreadsheets 
>>> are fundamentally text based anyway so should be okay. Presentations 
>>> would be an obvious no-go I expect. What compromises need to be allowed? 
>>> Full screen image/PDF viewing perhaps.
>>> It might be an interesting experiment to undertake. Especially for 
>>> someone who can code up missing pieces as needed. Especially for an 
>>> old-school guy who considered the first GUIs to be a nice fad.
>>> "Someone" should take this on as an experiment and do a talk on it. I'm 
>>> thinking a three month experiment.
>>> Daryl.
>>
>> _______________________________________________
>> Nottingham mailing list
>> Nottingham at mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/nottingham
>>
>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/nottingham/attachments/20160518/1d0fe49b/attachment-0001.html>