search for: ncoding

This is part of my program. I am getting an error, that I cannot figure out, any help would very much appreciated, thanks. # subset variables arc <- arc[,c("SNAP", "code", "ncode", "var", "n_total")] Error in `[.data.frame`(arc, , c("SNAP", "code", "ncode", : undefined columns selected arc$N_eff <-

hi all, i have problems running this code (taken from: http://blogs.msdn.com/michkap/archive/2006/12/20/1332470.aspx) in wine (1.1.26). the GetKeyState trick is not working, so GetKeyboardState never fills in any information in windowless apps. > /* > * If this thread needs a key state event, give one to it. There are > * cases where

A major problem with the queue spinlock patch is its performance at low contention level (2-4 contending tasks) where it is slower than the corresponding ticket spinlock code. The following table shows the execution time (in ms) of a micro-benchmark where 5M iterations of the lock/unlock cycles were run on a 10-core Westere-EX x86-64 CPU with 2 different types loads - standalone (lock and

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

Peter, I was trying to implement the generic queue code exchange code using cmpxchg as suggested by you. However, when I gathered the performance data, the code performed worse than I expected at a higher contention level. Below were the execution time of the benchmark tool that I sent you: [xchg] [cmpxchg] # of tasks Ticket lock Queue lock Queue Lock

...f per-cpu queue nodes and used them to form a waiting queue, we can encode the queue node address into a much smaller 16-bit size. Together with the 1-byte lock bit, this queue spinlock implementation will only need 4 bytes to hold all the information that it needs. The current queue node address encoding of the 4-byte word is as follows: Bits 0-7 : the locked byte Bits 8-9 : queue node index in the per-cpu array (4 entries) Bits 10-31: cpu number + 1 (max cpus = 4M -1) For single-thread performance (no contention), a 256K lock/unlock loop was run on a 2.4Ghz Westmere x86-64 CPU. The following t...

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

Hi, Here are some numbers for my version -- also attached is the test code. I found that booting big machines is tediously slow so I lifted the whole lot to userspace. I measure the cycles spend in arch_spin_lock() + arch_spin_unlock(). The machines used are a 4 node (2 socket) AMD Interlagos, and a 2 node (2 socket) Intel Westmere-EP. AMD (ticket) AMD (qspinlock + pending + opt) Local:

Hi, Here are some numbers for my version -- also attached is the test code. I found that booting big machines is tediously slow so I lifted the whole lot to userspace. I measure the cycles spend in arch_spin_lock() + arch_spin_unlock(). The machines used are a 4 node (2 socket) AMD Interlagos, and a 2 node (2 socket) Intel Westmere-EP. AMD (ticket) AMD (qspinlock + pending + opt) Local:

All, When attempting to pxeboot the latest Xen3.0 hypervisor/kernel it was failing with the following error: ------ \ \/ /___ _ __ |___ / / _ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ |_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |____(_)___/ \__,_|_|

...pass in is a "state" of a stream - either the beginning, middle, or end so I can handle these cases differently (for example, at the start of the stream I set all necessary headers). The generated file, however, does not seem to be valid and does not play. Could somebody verify that my encoding logic is sound? Here is the C source on GitHub (based on libvorbis encoder_example.c) : https://github.com/mateusz-/vorbisenc.js/blob/master/encoder_example.c And, if it helps, here is the corrupted/invalid Ogg file : https://raw.github.com/mateusz-/vorbisenc.js/master/audio.ogg Thank you, Mateusz...

Many warnings are encountered with GCC 10. Fix them. Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu> --- usr/dash/eval.c | 2 +- usr/klibc/zlib/infback.c | 2 +- usr/klibc/zlib/inflate.c | 20 ++++++++++++++++++++ 3 files changed, 22 insertions(+), 2 deletions(-) diff --git a/usr/dash/eval.c b/usr/dash/eval.c index dd144948a9fa..6b2b01e19a47 100644 ---

From: Matt Fleming <matt.fleming at linux.intel.com> These patches are based on the elflink branch. This set of patches is my attempt at moving the command-line interface functionality out of the core and into an ELF module to reduce the size of the core. The most interesting patch is [PATCH 4/4] which moves the cli code out of core/elflink and into com32/elflink/modules. [PATCH 4/4] is

From: Matt Fleming <matt.fleming at linux.intel.com> This is a series of patches that, * shrink the core by moving things into an ldlinux ELF module * begin wiring up some of the C versions of various functions The core now only contains essential code and loads the ldlinux module to do everything else, like providing a command line interface and loading kernels. The config file parsing