SpikeFun 0.68 - WebM Video Capture, Support for >64 CPUs...

With SpikeFun 0.68 comes WebM video capture support - until v0.68, cortical simulation could be captured in a series of large JPEG files. If you wanted to make the video out of them, you would need to post-process those images and encode them separately into the format of your choice. SpikeFun 0.68 adds more flexibility here - from now on, it is possible to directly capture the video in Google WebM video format.

Why WebM? Well, although WebM is not as effective as, say, H.264/AVC (and, therefore, needs more bytes for the comparable quality) and its reference encoder implementation is not exactly the fastest in the world, it does come with one advantage: it is free. So, using WebM is compatible with distribution of the free application, such as SpikeFun. SpikeFun allows tweaking of WebM encoding parameters (target bitrate, bit allocation mode - CBR, VBR and CQ, min/max quantizer, frame rate...) so you can find the combination optimal for your viewing pleasure... Try it! Command line switch to enable WebM capture is... -webm

If you are still not happy and would like to use different video codec, SpikeFun still supports capturing into JPEG sequence with minimal compression - in fact, it is still the default video capturing mode

Processor Group Support

Another new feature in SpikeFun 0.68 is support for processor groups. Why is this a big deal? Processor groups are introduced with Windows Server 2008 R2 and Windows 7 (NT kernel version 6.1). With previous versions of Windows, all user-mode (Win32) APIs dealing with processor affinities for threads/processes were using 32-bit DWORD (for 32-bit Windows) or 64-bit DWORD_PTR parameter. As every logical processor was represented with one bit in the 32-bit / 64-bit bit-field, this effectively limited the number of processors to be manipulated to 32 or 64.

As number of processors in modern hardware continued to increase, this limitation became a bottleneck even before Windows 7 / Server 2008 R2 were released. With architectures such as Intel's Beckton Xeon CPU it was possible to have more than 64 logical CPUs on a x86 system. For example, with 8-way Intel Beckton it was possible to have the system with 128 logical processors (8 processors with 8 cores, where each core can execute 2 threads). With more recent platforms, such as Intel's Boxboro EX the number of logical processors can grow up to 160.

So, legacy Windows API was not able to deal with more than 64 processors meaning that any logical CPU above 63rd will sit idle. Windows Server 2008 R2 changed all that introducing support for processor groups. Processor group is a new entity which encapsulates up to 64 logical processors. This is very handy, as one processor group could act as a "legacy" system for applications that are not CPU-group aware.

This is how processor group looks like:

Each processor group can hold up to 64 logical processors. Windows NT 6.1 kernel allows up to 4 processor groups, bringing to total number of logical processors that could be supported to 256. With SMT (hyperthreading) processors this effectively means that the number of physical cores is now expandable to 128. There is nothing stopping Microsoft from supporting more than 4 processor groups in Windows kernel: new Win32 APIs are using 16-bit WORD value for identifying processor group (GROUP_AFFINITY structure) meaning that, in theory, number of processor groups can grow up to 65536.

As each processor groups looks exactly like the legacy complete system (up to 64 logical processors), it makes support for legacy applications easy. Old applications unaware of the processor groups will act as nothing is different, as Windows scheduler will keep their threads inside one processor group. Any operation affecting thread affinities will be served on the application's own group - so backwards compatibility is 100%.

This is exactly how SpikeFun operated, prior to 0.68, which limited the number of CPUs that SpikeFun could effectively use. With 0.68, SpikeFun work manager is fully utilizing the new Win32 APIs that are group-aware, so it will be using as many processors as there are (NOTE: SpikeFun currently does not support CPU hot-plugging, although Win32 API does support this - this might be added in the future). Still, the standard unit of operation in SpikeFun is NUMA node (all decisions are based with regard to the NUMA node) - the only difference is that 0.68 is able to "see" all processor groups on the system and properly allocate work threads on every processor found on the system.

SpikeFun 0.68 also brings additional performance improvements for large NUMA systems - spike delivery has been optimized so it requires less worker threads (number is decreased by N, where N is the number of logical processors installed on the system) and the latency for job completion has been reduced.