Write fixed-width fields to stream in Julia? - io

In C++ you can do something like:
std::cout << setw(10) << left << x << setw(15) << left << t << std::endl;
to write two variables, x and t, to a stream, with a fixed column width.
How can I do this in Julia?

#printf gives you one way to do this:
#printf "%-10d %-15d\n" x t
There is a quick reference to GCC's version of this syntax. Julia may not support all of it, though.

You could also use my ScottPJones/StringUtils.jl package.
(it's not registered, so you'd need to clone it).
using StringUtils
println(u"\%-10d(x) \%-15d(t)")
You might like some of the additional features it has compared to using the #printf macros.

Related

Does AtomicU64 always undergo operations as big endian in rust?

So I am doing some experiments involving wait-free or lock-free reference counting, and I was trying to combine the storage of a small bit flag set and an atomic counter. I have come up with the following code:
use std::sync::atomic::{AtomicU64, Ordering};
fn main() {
let num = AtomicU64::new((3 as u64) << 62);
println!("{:#b}", num.load(Ordering::SeqCst));
num.fetch_add(1, Ordering::SeqCst);
println!("{:#b}", num.load(Ordering::SeqCst));
assert_eq!((num.load(Ordering::SeqCst) & !((3 as u64) << 62)), 1 as u64);
}
Which prints
0b1100000000000000000000000000000000000000000000000000000000000000
0b1100000000000000000000000000000000000000000000000000000000000001
and does not fail the assert_eq. However, I am wondering if this code will work cross platform? Does AtomicU64 always undergo operations as big endian ? Or does it sometime under go operations as little endian ? If so, how should I change my code to work on any platform that AtomicU64 works on ?
For reference, this result is obtained from the rust playground.
Does AtomicU64 always undergo operations as big endian in rust?
Depends on the platform.
I am wondering if this code will work cross platform?
Yes.
Does AtomicU64 always undergo operations as big endian ?
No.
Or does it sometime under go operations as little endian ?
Yes. Well, "sometime" - endianess is fixed to a platform.
how should I change my code to work on any platform that AtomicU64 works on ?
No changes need to be done.
Operators << & ! represent mathematical operations, independent of how are they implemented or stored, the result is mathematically the same everywhere. 3 << 62 is equal to 3 * 2**64 = 13835058055282163712 everywhere, no matter how the number is represented.

ibgtop function glibtop_get_cpu() information breaks down if a processor is disabled

I am pretty much a first timer at this so please feel free to tell where I have not followed correct procedure. I will do better next time..
My claim: libgtop function glibtop_get_cpu() information breaks down if a processor is disabled.
My environment: I have disabled processor #1 (0,1,2,3) for a hardware issue I have with a motherboard. Since that time, and presumably as a result, gnome-system-monitor now reports the machine as having 3 cpus (which is correct) and calls them CPU1, CPU2 and CPU3 (not wild about the labels used here but we can discuss that another time). The more important problem is that the CPU values for CPU2 and CPU3 are always zero. When I compare the CPU of gnome-system-monitor to ‘top’ (using the ‘1’ key to get individual processors), they don’t match. When I say don’t match, ‘top’ values are non-zero, while gnome-system-monitor values are zero.
‘top’ reports %Cpu0, 2 and 3. No sign of CPU 1. More important, the numeric values for these labels are non-zero. When I use the ‘stress’ command, the values move around as expected. ‘top’ indicates the individual processors are at 100% while gnome-system-monitor says 0.
Summary so far: ‘top’ gives plausible figures for CPU while gnome-system-monitor does not. On my system, I have disabled CPU 1 (0 index) and see that CPU2 (1 index) and CPU3 (1 index) have zero CPU.
I have been reading and modifying the code in gnome-system-monitor to explore where these values are coming from and I have determined that there is nothing ‘wrong’ with gnome-system-monitor program per se; at least as far as the numeric values for CPU are concerned. This is because the data gnome-system-monitor uses is coming from libgtop library and specifically the glibtop_get_cpu() function. The resulting data returned by glibtop_get_cpu() is zero for all indexes of 1 (0 index – this is in the C++ code) or greater.
It seems to me, I need to see how glibtop_get_cpu() works, but I have had no luck finding the source to glibtop_get_cpu(). What should I do next? The library I am using is 2.38.0-2ubuntu0.18.04.1 … on Ubuntu 18.04.1. Happy to try any suggestions. I probably won’t know how to do what you suggest, but I can learn.
Should I raise a bug? I would like to go deeper than this on the first pass if possible. I was hoping to look at the problem and propose a fix but at the moment, I am stuck.
Edit! (improvements suggested to the original question)
Incorrect output:
# echo 1 > /sys/devices/system/cpu/cpu1/online // bring all cpu online for the base case
$ ./test_get_cpu
glibtop_sysinfo()->ncpu is 4
xcpu_total[0] is 485898
xcpu_total[1] is 1532
xcpu_total[2] is 484263
xcpu_total[3] is 487052
$
# echo 0 > /sys/devices/system/cpu/cpu1/online // take cpu1 offline again
$ ./test_get_cpu
glibtop_sysinfo()->ncpu is 3 // ncpu is correct
xcpu_total[0] is 501416
$
# echo 1 > /sys/devices/system/cpu/cpu1/online // bring cpu1 online
# echo 0 > /sys/devices/system/cpu/cpu2/online // … and take cpu2 offline
$ ./test_get_cpu
glibtop_sysinfo()->ncpu is 3
xcpu_total[0] is 508264
xcpu_total[1] is 5416
$
Interpretation: As anticipated, taking 'cpu2' offline means we can't see 'cpu3' in the glibtop_get_cpu() result. By induction, (risky) I think that it we take 'cpu' offline, we will not get any statistics for all 'cpu' and higher.
That is my evidence for something wrong with glibtop_get_cpu().
My Code:
#include <iostream>
using namespace std;
#include <glibtop/cpu.h>
#include <glibtop/sysinfo.h>
main() {
const glibtop_sysinfo * sysinfo = glibtop_get_sysinfo();
glibtop_cpu cpu;
glibtop_get_cpu(&cpu);
cout << "glibtop_sysinfo()->ncpu is " << sysinfo->ncpu << endl;
//for (int i=0;i<sysinfo->ncpu;++i) { // e.g. ncpu might be 3 if one processor disabled on a quad core
for (int i=0;i<GLIBTOP_NCPU;++i) { // Alternatively, look through 1024 slots
if (cpu.xcpu_total[i] != 0) {
cout << "xcpu_total[" << i << "] is " << cpu.xcpu_total[i] << endl;
}
}
}
I have found the code I was looking for # https://github.com/GNOME/libgtop
Sorry to have wasted anyone's time. I don't know precisely how the above code works. For example I don't know how/if/where glibtop_get_cpu_l() is defined but I can see enough in the code to realize that as the code stands it looks at /proc/stat and if a specific "cpu" isn't found then that is a 'warning' and is logged somewhere (don't now where) and the rest of the cpu's are skipped. I will do more work on this in my own time.

what is the best way to test the performance of a program in linux

Suppose I write a program, then I make some "optimization" for the code.
In my case I want to test how much the new feature std::move in C++11 can improve the performance of a program.
I would like to check whether the "optimization" do make sense.
Currently I test it by the following steps:
write a program(without std::move) , compile ,get binary file m1
optimize it(using std::move), compile, get binary file m2
use command "time" to compare the time consuming:
time ./m1 ; time ./m2
EDITED:
In order to get the statistical result, it was needed to run the test thousands of times.
Is there any better ways to do that or is there some tools can help on it ?
In general measuring performance using a simple time comparison, e.g. endTime-beginTime is always a good start, for a rough estimation.
Later on you can use a profiler, like Valgrind to get measures of how different parts of your program is performing.
With profiling you can measure space (memory) or time complexity of a program, usage of particular instructions or frequency/duration of function calls.
There's also AMD CodeAnalyst if you want more advanced profiling functionality using a GUI. It's free/open source.
There are several tools (among others) that can do profiling for you:
GNU gprof
google gperftools
intel VTune amplifier (part of the intel XE compiler package)
kernel perf
AMD CodeXL (successor of AMD CodeAnalyst)-
Valgrind
Some of them require a specific way of compilation or a specific compiler. Some of them are specifically good at profiling for a given processor-architecture (AMD/Intel...).
Since you seem to have access to C++11 and if you just want to measure some timings you can use std::chrono.
#include <chrono>
#include <iostream>
class high_resolution_timer
{
private:
typedef std::chrono::high_resolution_clock clock;
clock::time_point m_time_point;
public:
high_resolution_timer (void)
: m_time_point(clock::now()) { }
void restart (void)
{
m_time_point = clock::now();
}
template<class Duration>
Duration stopover (void)
{
return std::chrono::duration_cast<Duration>
(clock::now()-m_time_point);
}
};
int main (void)
{
using std::chrono::microseconds;
high_resolution_timer timer;
// do stuff here
microseconds first_result = timer.stopover<microseconds>();
timer.restart();
// do other stuff here
microseconds second_result = timer.stopover<microseconds>();
std::cout << "First took " << first_result.count() << " x 10^-6;";
std::cout << " second took " << second_result.count() << " x 10^-6.";
std::cout << std::endl;
}
But you should be aware that there's almost no sense in optimizing several milliseconds of overall runtime (if your program runtime will be >= 1s). You should instead time highly repetitive events in your code (if there are any, or at least those which are the bottlenecks). If those improve significantly (and this can be in terms of milli or microseconds) your overall performance will likely increase, too.

How to do so in Linux, so that when reading from a file, the current application receives data from another application?

Let's say I have a file "hello.txt" containing the text "Hello, world!"
I have application "textreader", that reads the file hello.txt and puts it in stdout.
Next, i have encrypted the file "hello.txt". Can decrypt it a special library that can read the file byte by byte.
Ho do i can use application "textreader" to read from encrypted file as a normal file, using my library (or my application)? I can't write some temporary files under the terms of the problem.
It is possible to use named pipes (mkfifo), but prerequisite is the support seeking. File must be read randomly.
Does anyone have any ideas how i can to do it, if i haven't source code of "textreader"?
Write a shared library that replaces the standard Linux I/O routines, and load it with LD_PRELOAD.
This will work provided the application is dynamically linked to the C library - if "textreader" makes system calls directly, then interception won't work.
See also:
http://www.linuxjournal.com/article/7795
http://lca2009.linux.org.au/slides/172.pdf
Normally this is done using filesystem filter driver which will perform decryption on-the-fly. In order to support random seek you would have to encrypt data in independent blocks (64-256Kb large) and cache those blocks in memory in decrypted form. Not a trivial task but can be accomplished. I am not aware of how to implement a filter driver on Linux (we offer a similar product for Windows).
How about simply using stdin?
If the textreader application converts hello.txt to stdout, simply pipe the output of textreader to your own application/script. For example:
$ ./textreader | ./myapp
Depending on what language you'll decide to use in your application, you can handle stdin the same way you'd handle most streams.
The following SO answers should give you more information as to how to read from stdin in different languages:
Python: How do you read from stdin in python
C++: How to read until EOF from cin in C++
PHP: working with the php://stdin I/O streams
Wikipedia also provides some helpful information regarding stdin.
Edit: Most streams are seekable, as you initially asked. I wrote a small example in C++ that shows how you can seek stdin.
#include <iostream>
int main(void) {
int i = 0;
std::string buffer;
while (not std::cin.eof()) {
std::getline(std::cin, buffer);
if (buffer.find("while") != std::string::npos)
if (i < 10)
std::cin.seekg(0, std::ios::beg);
else
std::cin.seekg(0, std::ios::end);
std::cout << "Line " << i++ << ": " << buffer << std::endl;
}
return 0;
}
You can compile the code by using g++ test.cpp -o test and then run it with ./test < test.cpp. The code will output the beginning of the file twice, up to the beginning of the while loop. No buffering is done other than reading a single line from stdin at a time.
how about load the encrypted file in memory and decrypt from the memory buffer?
some script language such as perl, python, etc can read the whole file and assign it to a variable

When 2 int's are stored in Visual Studio, the difference between their locations comes out to be 12 bytes. Is there a reason for this?

When I run the following program in VC++ 2008 Express, I get the difference in location between two consecutively stored integers as '12' instead of expected '4'. On any other compilers, the answer comes out to be '4'. Is there a particular reason for why '12'?
#include <iostream>
using namespace std;
int main()
{
int num1, num2;
cin >> num1 >> num2;
cout << &num1 << endl << &num2 << endl;
cout << int(&num1) - int(&num2)<<endl; //Here it shows difference as 12.
cout << sizeof(num1); //Here it shows the size as 4.
return 0;
}
I'm going to make a wild guess and say that you built it in debug mode. Try building it in release mode and see what you get. I know the C++ run-time will place memory guards around allocated memory in debug mode to catch buffer overflows. I don't know if it does something similar with variables on the stack.
You could be developing code for a computer in China or it may be that there is a small and rare deficiency in the specific hardware you are using. One old model has difficulty with large numbers where the top bits become set and if the variables are in contiguous memory locations it was found that a buildup of charge in the core memory could have a crosseffect on adjacent memory locations and alter the contents. Other possibilities are spare memory locations for detecting overflows and underflows and it could be that you are running 32bit software mapped onto a 48bit hardware architecture brought forward to exist as a new model with the spare bits and bytes remaining unused.

Resources