Computing desk
< February 21	<< Jan \| February \| Mar >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 22[edit]

Intel TSX Vs TSX-NI[edit]

According to Intel:

The Intel Xeon Gold 6234 Processor has TSX-NI.[1]
The Intel Xeon Gold 6244 Processor has TSX.[2]

Clicking on the little question marks on the Intel website displays:

Intel Transactional Synchronization Extensions (Intel TSX) are a set of instructions that add hardware transactional memory support to improve performance of multi-threaded software.

Intel Transactional Synchronization Extensions New Instructions (Intel TSX-NI) are a set of instructions focused on multi-threaded performance scaling. This technology helps make parallel operations more efficient via improved control of locks in software.

Unlike pretty much every other feature, where the Bronze and Silver processors lack the feature while the Gold and Platinum processors have it, whether a processor is listed as having TSX or TSX-NI seems random.

Could it be that these are the exact same thing but two people at Intel added two slightly different names and descriptions? If not, what is the difference? Either way, the Wikipedia page at Transactional Synchronization Extensions should document it the difference or lack thereof. --Guy Macon (talk) 03:26, 22 February 2020 (UTC)[reply]

See here for example. I think the original version of TSX (in Haswell) was buggy and maybe misdesigned. They disabled it, re-enabled it and found more problems, etc. TSX-NI might be a redesign. I've never used it but if you want to understand what it is for, look at pages about software transactional memory (STM) (our article and web searches). I remember a good article about the STM implementation in GHC (Glasgow Haskell Compiler) here. STM is a very convenient way to avoid the standard lock hazards in multi-threaded programming, but its standard implementation technique requires several locked instructions, so it can be slow. TSX is a special hardware feature to speed it up. 2601:648:8202:96B0:C8B1:B369:A439:9657 (talk) 05:23, 22 February 2020 (UTC)[reply]

I believe that I have an answer, and unless anyone objects I will update the page.

My citation is Intel Transactional Synchronization Extensions (Intel TSX) Overview

I believe that the lead of the Transactional Synchronization Extensions page should be changed to:

Transactional Synchronization Extensions (TSX), also called Transactional Synchronization Extensions New Instructions (TSX-NI), is an...

and

...According to different benchmarks, TSX/TSX-NI can provide...

Here is what the citation says about it:

Intel TSX provide two software interfaces to specify regions of code for transactional execution.

Hardware Lock Elision (HLE) is a legacy-compatible instruction set extension (comprising the XACQUIRE and XRELEASE prefixes) to specify transactional regions. HLE is for programmers who prefer the backward compatibility of the conventional mutual-exclusion programming model and would like to run HLE-enabled software on legacy hardware, but would like to take advantage of new lock elision capabilities on hardware with HLE support.

Restricted Transactional Memory (RTM) is a new instruction set interface (comprising the XBEGIN, XEND, and XABORT instructions) for programmers to define transactional regions in a more flexible manner than that possible with HLE.

RTM is for programmers who prefer a flexible interface to the transactional execution hardware.

This and similar pages saying the same thing are the only references that talk about new instructions. There appears to be no such thing as "TSX" outside of "TSX-NI" --Guy Macon (talk) 09:44, 22 February 2020 (UTC)[reply]

Yes please do update the page. But, I think it was originally just called TSX and it didn't work and they had to revamp it. So I figured TSX-NI was the revamp. -NI is a standard Intel acronym for New Instructions. 2601:648:8202:96B0:C8B1:B369:A439:9657 (talk) 20:13, 22 February 2020 (UTC)[reply]

Done. --Guy Macon (talk) 18:00, 23 February 2020 (UTC)[reply]

Variable in c++ program passed by value to procedures changes its value[edit]

I'm debugging a program, and because I'm new to C++ I've difficulties finding the problem. So far I've diagnosed the fundamental issue to be caused by the value of a variable that is read from a file that should stay constant, to change during the evaluation of the problem. Nowhere in the program is that variable assigned a new value. But the variable is passed to procedures and functions. It's never changed, and I made sure it's passed by value, not by reference to make sure it shouldn't change even if I made an error somewhere inside the procedures.

So, what can cause the value of a variable in a c++ program to change its value if no new assignment to that variable is made? Count Iblis (talk) 17:20, 22 February 2020 (UTC)[reply]

@Count Iblis: Try using a debugger, it should be able to set a breakpoint for modification of the variable. When you catch it, you'll see what instruction modifies the variable. --CiaPan (talk) 18:27, 22 February 2020 (UTC)[reply]

As an alternative, you can copy the variable into some safe place (that is, another static variable) and insert some tests around different parts of code to verify whether the variable is still equal to its copy. This way you can iteratively narrow down the area of possible error (but that may be misleading, as there may be different circumstances triggering the erratic behavior). --CiaPan (talk) 18:38, 22 February 2020 (UTC)[reply]

The variable could be getting clobbered through a pointer error of some sort. Try declaring it const and seeing if you get any compile-time errors. If you have to debug it dynamically and your debugger supports watchpoints (they trigger when the contents of a memory location changes, using hardware assistance on some processors), that can be more convenient than using a normal breakpoint. See here for more info about watchpoints as the Wikipedia link doesn't explain them much. 2601:648:8202:96B0:C8B1:B369:A439:9657 (talk) 20:17, 22 February 2020 (UTC)[reply]

Added: note that you can't assign to a const symbol at all: you can only initialize it where it is declared. So if you want to read it from a file, you have to say something like

const int myvar(read_value_from_file());

Fwiw it is considered good style these days to use const and immutable values in preference to mutable variables whenever you can, a la functional programming. So it's a useful change to make either way. 2601:648:8202:96B0:C8B1:B369:A439:9657 (talk) 20:27, 22 February 2020 (UTC)[reply]

Just a "duh" check for a quite common mistake (I have done this myself): double-check to make sure the program doesn't use "=" when it should be "==", like in a loop condition. Complimentary regex for checking: myvar[ ]*=[^=]. To be extra-thorough you can check for other whitespace characters as well but the syntax varies: \s for Perl/Perl-like, [:space:] for POSIX. --47.146.63.87 (talk) 23:35, 22 February 2020 (UTC)[reply]

As the OP said, the variable should have always been passed by value. If it indeed were passed by value, then even assigning a new value to it would not affect the calling function. So not only is it an accidental assignment of some kind, but an accidental pass-by-reference on top of it. I don't know enough about C++ to know if such situations would be automatically generated despite the wishes of the programmer. Elizium23 (talk) 06:31, 23 February 2020 (UTC)[reply]

I've now found that the problem was caused by the fact that in C++ arrays are always passed by reference (my variable read from a file is an array). I then don't understand why in some C++ tutorials they make all that fuss about how to pass an array by reference so as to avoid the contents of the array being duplicated. So, this is then the fuss about the expression int & Ar[20] not allowed as this is going to be interpreted as an array of pointers and therefore having to write int (& Ar)[20], what is the point about all that id arrays are always passed by reference anyway???? Count Iblis (talk) 16:46, 23 February 2020 (UTC)[reply]

Count Iblis, unfortunately, that is legacy baggage from C. Any C programmer would intuitively understand that arrays are passed by reference (pointer) due to function calling conventions. But should it be expected of a C++ programmer to know C first? Elizium23 (talk) 16:54, 23 February 2020 (UTC)[reply]

If you mean a C-style array, declared like "int x[23];", then yes it is always passed by reference. Generally in modern C++, you should treat that type of array as a legacy feature and avoid using it if you can. Instead use std::array or std::vector which you do have to explicitly pass by reference to avoid copying. Also, use x.at(i) for std::arrays and vectors, instead of x[i]. .at() does a range check on the subscript which catches a lot of errors. In my measurements I've found has almost overall performance cost. The book "Effective Modern C++" by Scott Myers, about stuff like this, is very good. 2602:24A:DE47:B270:A096:24F4:F986:C62A (talk) 17:54, 23 February 2020 (UTC)[reply]

Yep, common pitfall for people new to C. (C++ just copies all this from C.) C arrays are just pointers in disguise. Now, I echo the above reply: modern, idiomatic C++ basically avoids all the "legacy" C stuff unless it's absolutely necessary. It sounds like you're self-teaching and going off online tutorials of dubious quality: I then don't understand why in some C++ tutorials they make all that fuss about how to pass an array by reference so as to avoid the contents of the array being duplicated. Are you sure they're talking about C arrays and not C++'s std::array? As I said, C arrays are just pointers; passing a C array by reference merely avoids copying the pointer. Anyway, if you want good resources for learning C++, go here. --47.146.63.87 (talk) 00:08, 24 February 2020 (UTC)[reply]