From: John Stone (
Date: Sat Dec 07 2019 - 19:20:24 CST


On Sat, Dec 07, 2019 at 06:28:12PM +0100, FX wrote:
> > You'll find that a few plugins won't work correctly due to changes
> > in Tk 8.6, but we're working on updating those that are affected.
> Great! I really know nothing about Tk.

No worries, we're working on these issues here...

> Related to Tcl/Tk: one thing that has bugged me for years about VMD. Is there a way to make the console understand simple readline keymaps? (arrows, ctrl+arrows, etc)

On Linux Axel Kohlmeyer provided a nice modification to the VMD startup
script that runs VMD behind 'rlwrap', which achieves exactly what
you're after:

You could easily modify the VMD launch script to make
it use rlwrap if you install it on your machine. Give that a try and
look at the VMD unix/linux startup scripts for comparison.

> > The issues with use of the retina displays hinge upon the support in the
> > latest FLTK and Tk implementations.
> I think I have good news on that, see my other email.

Yeah. It is particularly encouraging that you were reporting that Tk
seemed to do the right thing with just modification of the Info.plist
file in the app bundle. The FLTK calls will have to be worked out in
a bit more detail since they are (according to the docs at least)
totally MacOS X-specific, and we might need to be able to
suppress the use of retina mode for debugging any problems that might arise.

> On an unrelated note, while I was looking at the Apple-specific code in the VMD codebase, a few remarks/questions:
> - In WKFThreads.C, the __APPLE__ specific code is unnecessary. macOS supports sysconf(_SC_NPROCESSORS_ONLN) and can use the same code as __linux

Only on the most recent revs. If you go back a few revs it was still broken.
That said, I'm generally quite happy to get rid of all of the old
NSxxxx() API calls going forward as long as sysconf() is _actually_
trustworthy now... ;-)

> - How important is the wkf_cpu_capability_flags() code? I see that it???s not enabled except on Linux, but it would be easy to make a GCC and clang version with __builtin_cpu_supports(). I could look into it if it is interesting, but I don???t see where it???s actually used, except for displaying information at launch.

So, this is tricky.
At present, when we compile using Intel C++, a bunch of macros are defined
that allow VMD to enable use of the hand-vectorized assembly code for
various things by default. At present, this determination is
compile-time-defined, largely because we didn't have a comparable code
path for GCC or Clang. I looked at writing a decoder for the x86 CPUID
instructions, but it's quite hideous since Intel and AMD have
incompatibilities in many places. To that end, in the short term I've
kept things compile-time-defined and this has been "okay" up to now,
but going forward, particularly with new Intel Ice Lake, or AMD Epyc
hardware, this is leaving some performance on the table, and it
would be preferable to make the determination completely at runtime.
Right now, the AVX2 and AVX-512 code isn't enabled by default
in the standard binaries because we don't have a portable runtime
CPU instruction set query mechanism.

Look around at the hand-vectorized code in VMD -- just grep
for "__AVX2__" or "__AVX512" and you'll see that there are various
places where we could get some speed from a fully dynamic runtime
launch scheme, but we'd need it to work with all of the GCC/Clang
variants and not just with Intel's compilers. See util_simd.C for example.

We also need similar mechanisms for PPC64, and ARM64, but those targets
are much less diverse than the x86 family is, so we can get away
with compile-time determination on those systems for some
time yet if necessary.


> Cheers,
> FX

NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801           Phone: 217-244-3349