Sergey Vojtovich s...@mariadb.org writes:
+#ifdef __cplusplus
+template typename T, int S class Atomic_type_triat;
+
+
+template typename T class Atomic_type_triatT, 4
+template typename T class Atomic_type_triatT, 8
+template typename T, typename S= Atomic_type_triatT, sizeof(T) class
Hi, Kristian!
On Jan 24, Kristian Nielsen wrote:
Sergey Vojtovich s...@mariadb.org writes:
+template typename T, typename S= Atomic_type_triatT, sizeof(T) class
Atomic
+ T operator++() { return add(1) + 1; }
[lots and lots of more template code snipped]
I am vetoing this.
I really do not like hiding the type. If you did not think carefully about the
type of the underlying variable, you _really_ should not be using something as
complex and subtle as an atomic operation.
And I _really_ do not like that we would now have two _different_ ways to do
atomic operations,
Kristian,
On Fri, Jan 24, 2014 at 10:49:26AM +0100, Kristian Nielsen wrote:
I really do not like hiding the type. If you did not think carefully about the
type of the underlying variable, you _really_ should not be using something as
complex and subtle as an atomic operation.
Sorry, still
Kristian,
sorry forgot to answer your last question.
On Fri, Jan 24, 2014 at 10:49:26AM +0100, Kristian Nielsen wrote:
...
So, if people really want to spend time on improving my_atomic.h - why on
earth would they waste their effort on something of as little importance as on
whether code says
I have been analysing CPU bottlenecks in single-threaded sysbench read-only
load. I found that icache misses is the main bottleneck, and that
profile-guided compiler optimisation (PGO) with GCC gives a large speedup, 25%
or more.
(More details in my blog posts:
Hi, Serg, all.
I'm not sure how about fixing this one:
https://mariadb.atlassian.net/browse/MDEV-5273
So would like your opinion.
The thing is that the SHOW commands with old-fasioned implementations
(those that aren't mapped to the SELECT FROM information_schema.something)
return
7 matches
Mail list logo
