Nov 172018
 

At the end of the first day of the 2018 Vikings Weekender, GM Anton Smirnov and IM Junta Ikeda share the lead with 3.5/4. They met in the 4th round, with the game finishing in a quick draw by repetition. On 3 points are FM Brandon Clarke, and Bahman Kargosha. Clarke lost his round 3 game against Smirnov (see below), while Kargosha has had 2 wins and 2 draws.
The 26 players Open event has probably the strongest field in the tournaments history, with the top half of the field rated above 2000. A combination of strong visiting players, and young local talent has created an event where every round is challenging for those taking part.
In the 24 player Minor (Under 1600), Bazli Karattiyatil leads with 4/4. He looked to be in a little trouble in his round 4 game against Yifu Wu, but a clever in between move was enough to halt Wu’s attack and leave Karattiyatil with a winning position.
Full results and a link to the live coverage can be found at http://tournaments.streetchess.net/vikings2018/ The fifth round for both tournaments starts at 10:30am tomorrow (Canberra time).

One of the more interesting games from the tournament was the round 3 clash between Smirnov and Clarke. Clarke found an interesting (and correct) piece sacrifice, even allowing Smirnov to promote his e pawn. But just at the crucial moment, Clarke got carried away by visions of checkmate, and played into a losing line. If he had simply captured the new queen (21. … Rxc8) then Smirnov had nothing better than 22.Bd2 Rb1+! 23.Kxb1 Rb8+ 24.Kc1 Bb2+ with a perpetual.

Smirnov,Anton – Clarke,Brandon [B90]
Vikings Weekender, 17.11.2018 new PgnViewer( { boardName: “game910”, movesFormat: “default”, pgnString:’1.e4 c5 2.Nf3 d6 3.d4 Nf6 4.Nc3 cxd4 5.Nxd4 a6 6.Bd3 g6 7.f3 Bg7 8.Be3 Nc6 9.Qd2 O-O 10.O-O-O d5 11.Nxc6 bxc6 12.e5 Nd7 13.f4 Qa5 14.Kb1 Rb8 15.Ne2 Qa3 16.Qc3 Qxc3 17.Nxc3 f6 18.e6 f5 19.exd7 Bxc3 20.dxc8Q Rxb2+ 21.Kc1 Rxa2 22.Qe6+ Rf7 23.Qc8+ Rf8 24.Qb7 Ra1+ 25.Qb1 Rxb1+ 26.Kxb1 Rb8+ 27.Ka2 1-0′, pauseBetweenMoves: 500, pieceSize: 29 } );

2018 Vikings Weekender – Day 1
Source: Chessexpress

Nov 162018
 

When you create a new variable (in C, C++ and other languages) or allocate a block of memory the value is undefined. That is, whatever bit pattern happened to be in the raw memory location at the time. This is faster than initialising all memory (which languages such as Java do) but it is also unsafe and can lead to bugs, such as use-after-free issues.

There have been several attempts to change this behaviour and require that compilers would initialize all memory to a known value, usually zero. This is always rejected with a statement like “that would cause a performance degradation fo unknown size” and the issue is dropped. This is not very scientific so let’s see if we could get at least some sort of a measurement for this.

The method

The overhead for uninitialized variables is actually fairly difficult to measure. Compilers don’t provide a flag to initialize all variables to zero. Thus measuring this would require compiler hacking, which is a ton of work. An alternative would be to write a clang-tidy plugin and add a default initialization to zero for all variables that don’t have a initialization clause already. This is also fairly involved, so let’s not do this.
The impact of dynamic memory turns out to be fairly straightforward to measure. All we need to do is to build a shared library with custom overrides for malloc, free and memalign, and LD_PRELOAD it to any process we want to measure. The sample code can be found in this Github repo.

Measurements

We did two measurements. The first one was running Python’s pystone benchmark. There was no noticeable difference between zero initialization and no initialization.
The second measurement consisted of compiling a simple C++ iostream helloworld application with optimizations enabled. The results for this experiment were a lot more interesting. Zeroing all memory on malloc made the program 2% slower. Zeroing the memory on both allocation and free (to catch use-after-free bugs) made the program 3.6% slower.
A memory zeroing implementation inside malloc would probably have a smaller overhead, because there are cases where you don’t need to explicitly overwrite the memory, for example when the allocation is done behind the scenes via mmap/munmap.

Jussi Pakkanen: The performance impact of zeroing raw memory
Source: Planet Gnome