Finished settling in, more or less, and now about to actually do some real actual genuine honest-to-God coding again at last.
Next release will be 7.1.0, will be identical to 7.0.0, except it will contain the benchmark programme.
I’ve just found out - I was Googling to see where he’d gone; he’d not posted anything for about six months.
He died on the 29th December, 2015, his birthday.
Every hand-over-eyes-I-see-no-problem politican in Europe will breathe an involuntary sigh of relief.
I decided on the source code layout, which is a huge issue in this programme - what’s being done (benchmarking many variations) lends itself to a highly factorized layout, but it ends up being unmaintainable, and also suffers of course inherently from inflexibility; when you come up with another test type which doesn’t fit in the factorization you have, your code is problematic.
I spent yesterday and now today so far getting the topology code back on its feet, which seems to have worked, first pass (by first pass I mean hours of compiling and fixing up the code for 7.0.0 - but first pass as it, it wasn’t broken once this was done!)
Sample output from my Core i5 on Linux;
Key === M = Memory N = NUMA node S = Socket (physical package) Ln = Level n cache D = Data cache I = Instruction cache U = Unified cache P = Physical core L = Logical core Topology ======== M N S L3U L2U L2U L1D L1D L1I L1I P P L L L L
I’m now going to see if I can get release 6 (six, not 6.0.0, etc) compiling reilability and consistently on Raspberry Pi - it seems to compile with some versions of GCC but not others, and the problem is the in-line assembly for DWCAS. There’s a better way to do this, which is to cast to an int long long unsigned and use the GCC instrinsic, which I hope will side-step the problem.
I want to write about my recent travel experiences with airport security.
I flew from Newark, New Jersey (EWR) to Schipol, Amsterdam (AMS) and then a second flight, a few days later, from AMS onwards.
In EWR, I as I always do declined the body scanner and asked for a pat-down.
One of the operators tried to persuade me the scanner was safe by saying it was “like an ultrasound”, which is a shocking claim - utterly untrue. An ultrasound is like sonar. It uses sound waves which pass physically into the body and bounce around. A body scanner is like an x-ray machine. It uses ionizing radiation, which rams into the body and damages cells and contributes (in what is hopefully a tiny fashion, but the research is not clear) to the risk of cancer.
No one working with these machines should EVER say that. It was disgraceful.
So then I was “patted-down”.
Except it wasn’t a pat-down. That phrase is for when you stand up and someone pats you. I was “patted down” with such physical force I was actually staggering backwards and forwards - I was unable to maintain my balance standing. This went on for about five minutes.
So that was EWR.
Then in AMS, when I departed, again, I declined the scanner and was patted-down - actually patted-down; but this time, I was also taken into a privacy booth, and asked to unbutton and lower my jeans, which I did, he visually checked the buldge in my underwear and that was it.
That hasn’t happened before. I’m wondering if there is a connection between these two (EWR and AMS) events. Has there been globally a directive to make non-scanner checks more… more, what? more effective? presumably effective? while at the same time of course making them more intrusive, more intimate, more and more unpleasent - and remember here, there’s no evidence I am hostile; these are just routine, generalized checks.
The TSA recently stated passsengers no longer have the right to decline the body scanner - they can, at the TSA’s discretion, be required to go through, or, of course, be refused their flight (and what else? then coming to the attention of the FBI? who have the power to make a warrentless entry in all kinds of situations - including, shockingly, living within one hundred miles of the US border, which includes of course all of say NYC, which is where I used to live. Congress and the Senate are useless - these kinds of powers should not exist, but they do).
So, what do I come away from this with?
If EWR pat-downs are like that normally, I am not longer going to fly through EWR. I’d have to go through EWR again to find out if it is so, and the experience was unpleasent enough I have no wish to experiment to find out - so that kind looks like EWR is now on my no-fly list.
I already no longer fly through Gatwick, not for that reason, but because of the awful, awful experience of the cameras as you queue for immigration.
If US airpot pat-downs are like this in general, then - believe it or not - I’m no longer flying to the US. I’ll see if I can get in by ship in a more peaceful manner.
What of Schipol? I don’t know what to make of that. The TSA (the American airport security organisation) being abusive I know about. They are culturally like that and it’s not being fixed - indeed, I’d say it’s getting worse. (They’re also expensive - eight billion a year - and no good; the detection rate for explosives and guns is about 8%) - but Schipol? I thought the Dutch would be better. I will give them a second chance, and see what happens.
On what is I think now the fifth attempt (over the course of about two years) I finally have the design of the benchmark programme correct.
It’s a complex beasty - you have the data structures, the benchmarks, the many different types of locks (and the lock-free as well of course), where the locks vary by platform, CAS and DWCAS backoffs need to vary, where each benchmark runs over a range of logical processor sets (e.g. say on every logical core, then on one logical core per NUMA node, etc, etc - the full meainngful set of sets), and where you want to be able to produce arbitrary gnuplots afterwards.
It used to be more complex - there were NUMA and non-NUMA variants to consider, and also before the SMR variants of data structures became a separate data structure, you also had to consider the SMR and non-SMR variants.
I remember spending two weeks in particular Tunis working on this - it’s a deadly trap. The problem is you can just about fully optimize the code layout; abstract the lock types, loop over the benchmarks, loop over the data structures, etc, etc, etc - you end up with a perfect factorization. The problem is, it’s at the limit of what you can manage… so when you come back to it, you can’t remember how it works, and, more painfully, if ANY new requirement comes along, it can’t fit - but you’re already at your limit even when you were fresh to the code and had it all in your mind.
A simpler approach was needed.
What I’ve done is basically two things - first, I’ve removed the per-lock abstraction. Each data structure now has an implementation for each lock. This was actually needed because having one template data structure which used function pointers for locks added the overhead to the locking benchmark runs of following that function pointer. Probably the cost is very small - even negligible - but it’s unwise to assume, so it would have to be investigated to be sure, and of course adding overhead to the locking benchmarks favoured liblfds. Second, I’ve used an abstraction layer, as with liblfds; the abstraction layer implements the locks - all of themm, for all platforms, dummying them up if they’re not actually available - and all the code above that is always fully compiled on all platforms.
I’m still thinking about what to do with the output though, since there can be many thousands of output records, and I want to access them arbitrarily to make gnuplots - I could run into a performance problem!
Anyways, I’ve just made the full basic structure of the benchmark programme compile. There’s a lot of code thrown in there from the previous attempts - it all needs a lot of work on quality - but it compiles and the fundamental design is correct, so we’re on the right track.
Hopefully will tomorrow have some gnuplots for freelist.
Home Blog Forum Mailing Lists Documentation GitHub Contactadmin at liblfds dot org