Unimportant

I'm assuming you have your 5000 matrices in a contiguous memory block, like a array or a std::vector, all next to each other?
If so, it is possible the performance discrepancy you're seeing from those 2 cores is due to false sharing at the "edges", where 2 blocks of 625 matrices meet. (Assuming there isn't something else in your code causing this. No races anywhere ? For sure?).
 
Cache lines on modern systems tend to be 64 bytes wide. Cache lines are the smallest unit the cache controller can work with. That means even when you change only a single byte, a whole 64 byte cache line has to be brought in, modified, and written back. Everywhere a block of 625 matrices ends and the next one begins there will be a cache line that contains a bit of the end of the first block and a bit of the beginning of the next block. Each of the 2 cores working on those 2 blocks has it's own copy of that cache line in it's L1/L2 cache. Whenever 1 core makes a change to it's bit of the cache line it invalidates the entire cache line for the other core causing a reload from higher up memory. Thus, both cores will ping-pong back and forth clobbering each other's cache line.
 
You might think: "But it only happens on a tiny section near the edges of 2 blocks". Yes, but cache misses really are *that* expensive that it could cause such slowdowns.
"Why only on 2 cores?" It depends on the size of your matrix elements and the alignment of how everything ends up in memory. Some blocks might only share a few bytes in a cache line while other blocks might share a cache line 50/50.
 
To test I'd create 8 separate std::vectors of say 650 matrices in stead of 625 and leave the last 25 unused but act as padding and retest.
 
Also look out for possibilities of false sharing in the rest of your code. Try to move as much per thread state as possible to the stack of the actual thread as each thread will have it's own separate stack space, typically far enough away from the others.
 
 
 

No, it works just the same and will always print "True". Nonzero values evaluate as true, zero as false.
 
Why would it be bad form? It's used all over the place by C and C++ programmers, what is unclear about it ?
It is allowed since C99.
Could you give an example of such a int -> boolean -> int because this sounds like gibberish to me and would require some pretty poor code to even invoke.
 
We tend to prefer C++ in environments where reliability is king due to the very powerful static tools it has, such as templates and constexpr.
When properly used these can provide a safety layer at compile time! What is more reliable then your faulty code failing to compile ? For example:
const auto speedOne = GetSpeedSensorOne(); //European made sensor returns a Speed<Speed::Unit::kmh> const auto speedTwo = GetSpeedSensorTwo(); //American made sensor returns a Speed<Speed::Unit::mph> const auto totalSpeed = speedOne + speedTwo; //Speed<Speed::Unit::kmh> and Speed<Speed::Unit::mph> are... //...diffirent types , compile error ! When uncaught, mistakes like this make Mars climate orbiters crash! //...or, a craftier implementation would convert between the two units automatically.  

But there is a large cost to it, both for the student who graduates with a mortgage but no house and to society, who will eventually be on the hook for the bailouts when a large portion of those loans eventually default. Not to mention the inflated army of bureaucrats running the whole show that could've been doing something productive instead. That's a hefty price to pay for a journey to useless credentials.
 
When you want something more then average in life, one should attempt to take the road least traveled. Back in the day, when only the best got to go to college, and only a percentage of them actually graduated, going to college was that road. You where something special if you made it. Today almost everyone goes to college, which is a huge waste because not everyone is college material - the opposite in fact - and it devalues the degree because the bar has been lowered to give these ppl who should not be in college in the first place a better chance of graduating. There's simply too many of them, this equality thing has been taken too far.
 
One should make his own decisions of course, all I'm saying is you should consider the cost (of all natures, time is also a cost) / benefit of everything you do.
 
As for certifications. If you can get them at little cost and it's a rare certification that'll actually help you going places, go for it.
But if it's a costly endeavor, for a certification seemingly everyone has, take the other road.

But there is a large cost to it, both for the student who graduates with a mortgage but no house and to society, who will eventually be on the hook for the bailouts when a large portion of those loans eventually default. Not to mention the inflated army of bureaucrats running the whole show that could've been doing something productive instead. That's a hefty price to pay for a journey to useless credentials.
 
When you want something more then average in life, one should attempt to take the road least traveled. Back in the day, when only the best got to go to college, and only a percentage of them actually graduated, going to college was that road. You where something special if you made it. Today almost everyone goes to college, which is a huge waste because not everyone is college material - the opposite in fact - and it devalues the degree because the bar has been lowered to give these ppl who should not be in college in the first place a better chance of graduating. There's simply too many of them, this equality thing has been taken too far.
 
One should make his own decisions of course, all I'm saying is you should consider the cost (of all natures, time is also a cost) / benefit of everything you do.
 
As for certifications. If you can get them at little cost and it's a rare certification that'll actually help you going places, go for it.
But if it's a costly endeavor, for a certification seemingly everyone has, take the other road.

It might be interesting to note that on modern machines, which rely heavily on caches, a linked list is far inferior to a plain dynamic array in all possible ways. It simply does not pay to bother with a linked list, even for inserting/removing elements somewhere in the middle of the list.
Moving the elements of a dynamic array, even millions of them, when inserting/removing in the middle - which is a cache friendly, linear, predictable operation - is orders of magnitude faster on modern machines then traversing a linked list which has it's nodes spread out trough memory - which is a very cache unfriendly, random operation.
 
Straight from the horse's mouth:
https://www.youtube.com/watch?v=YQs6IC-vgmo
 

The counter can only divide the base clock by a integer. So you cannot get those random values from a 100kHz base clock. You could get 50kHz, or 25kHz, etc...

just be SUPER careful with this. If you expose the raw pointer from your smart pointer, it CAN get deleted and then you can get undefined behavior. For example, even if nothing else is needed from your pointer after that point, you would still get double deletion and undefined behavior when the unique_ptr goes out of scope.

There's another gotcha that you overlooked. What happens when the user enters multiple characters as an answer to a question? (try it).
You need to clear the input stream after each input operation to flush any additional nonsense the user may have typed.
 
Also note that `system("pause")` is not portable.
 
Modified example:
#include <iostream> #include <stdlib.h> #include <limits> #include <cctype> using namespace std; void CheckAnswer(char correctAnswer) { while (1) //endless loop. { char answer; std::cin >> answer; /* Clear the cin input stream! */ cin.ignore(numeric_limits<streamsize>::max(), '\n'); answer = toupper(answer); if (answer == correctAnswer) { std::cout << "Correct!\n"; break; //break from endless loop. } else { std::cout << "Wrong!\n"; } } } main() { /* place the introduction in a scope of it's own, this limits the scope of std::string name so it does not pollute the entire main function. */ { //INTRODUCTION cout<<"Enter player name: "; string name; cin>>name; cout<<"WELCOME " <<name<< " TO WHO WANTS TO BE A MILLIONARE"<<endl; cout<<"INTRODCING YOU'RE HOST C++"<<endl<<endl; system("pause"); cout<<"RULES"<<endl; cout<<"1.ANSWER IN ALL CAPS"<<endl; cout<<"2.YOU HAVE 3 LIFELINES CALL A FRIEND,50-50 and skip question"<<endl; cout<<"3.NO CHEATING"<<endl <<endl <<endl; cout<<"WITHOUT FURTHER A DO WHO WANT TO BE A MILLIONARE?"<<endl; system("pause"); } //QUESION //question 1 cout<<"Who is the Current Chancellor of Germany"<<endl; cout<<"A-Wilhem II"<<endl; cout<<"B-Angela Merkel"<<endl; cout<<"C-Franz Hamburg"<<endl; cout<<"D-Hanz Zimmerman"<<endl; CheckAnswer('B'); //QUESTION 2 cout<<"Who is the competitor Wolfgang Amadeus Mozart?"<<endl; cout<<"A-Antonio Sallieri"<<endl; cout<<"B-Ludwig Beethoven"<<endl; cout<<"C-Johann Pachelbel"<<endl; cout<<"D-Johann Sallieri"<<endl; CheckAnswer('A'); /*...etc...*/ system("pause"); }  

Assembly *does* have concepts for functions and loops. Most architectures have a call instruction and x86 has a loop instruction. 
 
We can't all avoid assembly. Someone has to build the compilers and tools you work with.

The second one imho. Valid C code is not necessarily valid C++. Implicit void pointer conversion has already been mentioned as an example.
Both C and C++ are based on the "you don't pay for what you don't use" principle. If you don't use any "fancy" language features then your C++ executable should be just as small and fast as the C executable. If you do use extra language features then it's probably because you need them and you should make a fair comparison with a C program that somehow implements the same functionality.
First of all. Since C++11/14 it's std::unique_ptr and std::make_unique. Don't use auto_ptr. It's a kludge from before move semantics existed that'll get you into trouble.
 
Pre C++11 I don't see how C++ encourages dynamic constructs more then any other language at the time, any concrete examples?
Post C++11, with move semantics, you can pretty much do anything statically. (remember we have std::vector for dynamic arrays).
 
Proper RAII techniques make memory management nearly automatic and elegant, once you get used to proper RAII paradigms you don't even want a garbage collector anymore. On top of that RAII allows for cleanup of *all* resources, not just memory.
True, but that's a lot of manual work (for someone who just claimed manually cleaning up his memory is a hassle), and as such very error prone.
 
Note that I'm not arguing against C, C is not obsolete. However one should pick the right language for the task at hand. The canonical example is having to write a drawing application that can draw different shapes. The advantage of polymorphism should be clear in this case. You define a "shape" interface for the main drawing code to use and then implement all the shapes you need, even add shapes later, without the drawing code ever needing to change (not even requiring recompilation!) or know about any of this.

No, the main problem is that a liquid spilled on a circuit board that has a voltage applied to it immediately causes an electrolysis effect that causes near instant corrosion, we're literally talking seconds here to do irreversible damage. If a board that's completely powered down were to get wet and dried quickly there'd be no problem, but in the age of laptops with built-in non-removable batteries boards always have voltages present.
 
A small enough spill on a non-critical location is probably recoverable but then again such a spill would not cause the device to (completely) fail in the first place.
 

No, the main problem is that a liquid spilled on a circuit board that has a voltage applied to it immediately causes an electrolysis effect that causes near instant corrosion, we're literally talking seconds here to do irreversible damage. If a board that's completely powered down were to get wet and dried quickly there'd be no problem, but in the age of laptops with built-in non-removable batteries boards always have voltages present.
 
A small enough spill on a non-critical location is probably recoverable but then again such a spill would not cause the device to (completely) fail in the first place.
 

@VexKrad
 
You define 'o' as a single character variable. How are you planning on storing multiple characters in that single space? And even if you were to only read in a single character it would still cause undefined behavior because you ask for a string (%s) and strings are 0-terminated. You need a single character worth of space for storing that terminating zero alone so you overrun your "buffer".
 
Note that scanf is nasty for even allowing this, which is why you should not be using it. I'd also make it a habit to check the result of operations. Every call to scanf can fail. (for example, because you enter text when it expects a number). After such a failed call the data that stay stuck in the input buffer causes your program to "act weird" on subsequent calls to scanf. Says a lot about modern schooling that they still teach it this poorly.

Use threads to divvy up the workload and compose the data that should be sent to OpenGL but only have a single thread (the one that opened the OpenGL context) handle the calls to OpenGL. Also consider that the error might be in your code, not necessarily anything to do with OpenGL, are you sure you don't have any data races? atomicity issues ? OOE problems that break naive mutex attempts?, etc...

@fpo
You're overusing references and using them in ways that are frowned upon. The most prominent use of references is to pass a expensive-to-copy object as read only. For example:
//PlayAudioSample signature... void PlayAudioSample(const AudioSample& Sample); AudioSample TestSample("test.wav"); PlayAudioSample(TestSample); Here, AudioSample is a class that reads a wave file from disk and holds all the relevant data. The function PlayAudioSample plays back such samples. We don't want to needlessly copy a potentially expensive object just to play it back, so we pass by reference. PlayAudioSample also does not need to be able to modify the AudioSample (in fact, we want to protect ourselves from accidentally modifying it) so we pass as const reference.
 
The second use of references should be if we want to modify the parameters that are passed, but only in intuitive ways.
The standard library has a great example that goes something like this:
void swap(T& a, T& b); That swaps the contents of a and b, that's pretty clear and concise and off course requires non-const references.
 
However, in your code:
tileData[tileDataIndex] = Interpret(ch, tileDataIndex, vectorIndex); I totally don't expect the Interpret function to go and start messing with tileDataIndex and vectorIndex, that's just a huge code smell. More particularly you should not be micromanaging a function's local variables in a subfunction.
It's a huge indication of poor program structure and it's the primary reason you're getting into trouble here. I'm having a hard time following your code and I've been doing this for decades.
 
What is it you're trying to do *exactly* and perhaps we could show you a proper example to pick apart.
 
On a sidenote: Read up about "const correctness" and start applying it rigorously, it'll come back to bite you in the ass if you don't. Trust me, retrofitting existing code for const correctness is a nightmare, and your code won't play well with someone else's code that has const correctness otherwise.

C++ supports references, which allow passing objects by reference without pointer syntax:
void Foo(int& i) { i = 1337; } //... int a = 101; Foo(a); //a now equals 1337  

200v DC is kind of a strange number... could you elaborate on why you would need such a high DC voltage?
 
It may make more sense for safety and other reasons (faster charging, thermals)  to build 24v (~6 in series) or 48v (~12 x 3.7v..4.2v in series) battery packs and use a dc-dc converter to boost to 200v or whatever voltage you'll need (there's ready made inverters and converters used for solar power industry, which can take 24-48v and convert it to higher AC or DC voltage.
 

@lewdicrous
This is the spectrum of the little noise clip you uploaded, after normalizing:

We see the biggest peak at 100 hz, that's almost certainly the bridge-rectified mains (living in a 50hz mains area?).
The second peak next to that is @ almost exactly 350 Hz. All the other peaks after that are on multiples of 350 Hz, so it looks like 350 Hz is the fundamental and the others are it's harmonics. Listening to a 350 Hz test-tone on youtube seems to agree with this, the tones match.
 
That probably explains the involvement of the subwoofer. Such low tones are produced by the woofer, so if you turn it off it's only natural the noise is mostly gone. It's probably still there but without the woofer you can't hear it, it's beyond the range of the tweeters.
So you're looking for something that's generating 350 Hz noise, can't readily think of something. It's certainly not digital noise or switch mode power supply stuff, the frequency is too low for that.
 
Have you tried disconnecting everything from the speaker set and only attach a battery powered audio source like your phone. That should help determining if the noise is coming from the speaker set or some weird mains loop.
 
EDIT: Don't happen to have any LED dimmers/controllers hanging around? Seems a lot of those things do their PWM @ 350 Hz
Example:
http://www.tridonic.cn/cn/download/data_sheets/DS_TALEXX_C001_en.pdf
 
 

Use threads to divvy up the workload and compose the data that should be sent to OpenGL but only have a single thread (the one that opened the OpenGL context) handle the calls to OpenGL. Also consider that the error might be in your code, not necessarily anything to do with OpenGL, are you sure you don't have any data races? atomicity issues ? OOE problems that break naive mutex attempts?, etc...

It's kind of normal.
The measurements aren't done at the same time, one software may take a "snapshot" in the first 100 milliseconds of every second, the other software may take a "snapshot" 500 ms later.
Also, processors these days dynamically adjust their frequencies depending on load and how much load the other cores have. So one software could take measurement when the core is running at  1800 Mhz and half a second later the core could have a tiny bit more work and boost itself at 3 Ghz  - the percentages are most likely calculated based on the frequency at the moment of measurement.
Also, the cpu doesn't really tell you how busy each core is, that's calculated over periods of times... one software could compute the load and tell you the average over the previous 2 seconds, another software could average just the last second or half a second.
 

@Master Disaster @it_dont_work @Unimportant @Hackentosher @JRzoid
 
It works! Looks pretty good, I think. 
 

First of all, it won't compile, the call to the 'f' function is wrong. You need to pass the address of the array but you try to take the address of the type.
int main() { const int n = 5; SomeStruct *theArray = NULL; f(&theArray, n); //Pass the address of theArray instance, not the type SomeStruct. }  
(re)alloc takes the amount of memory to allocate in bytes. Your struct probably consists of more then a single byte, so you need to allocate n times the size of the struct bytes:
*dynArray = (SomeStruct *)realloc(*dynArray, sizeof(SomeStruct) * n); Additionally, you should test if the memory allocation actually succeeded before attempting to use the memory. (re)alloc returns a NULL pointer on failure.
 
As for how to access the struct member, there's no really clean way. The canonical way would be:
(*dynArray)[n - 1].someMember //(*dynArray) dereferences the pointer to access the underlying array pointer //[n - 1] accesses the last element //For scanf you need to take the address of the member so it becomes: &((*dynArray)[n - 1].someMember) If you need to access a lot of members this way it becomes ugly. One could create a intermediate pointer to the array element to access as a proxy to make things cleaner:
SomeStruct *proxy = &((*dynArray)[n-1]); //proxy now points to array member n - 1. scanf("%d", &proxy->someMember); printf("%d", proxy->someMember); //Cleaner and more readable for multiple accesses.  

It tends to be based on a sliding potentiometer but there has to be some electronics in there too to power the actual load. Simply putting the potentiometer in series with a serious load is impossible. For example, at half speed the potentiometer would roughly dissipate the same power as the load, for a typical cordless drill that would be tens of watts.
 
For mains AC powered drills there should be a triac and the potentiometer would control the phase angle. For DC cordless drills there should be a MOSFET and the potentiometer controls PWM duty cycle. So simply trying to measure resistances won't work. (Or it could simply be the potentiometer and the electronics where external)

The safe (for your PCB), poor man's way of replacing a SO device with only a plain soldering iron is to sacrifice the old chip. Use small snips (or a xacto knife) to carefully cut the chip's pins at the point where they enter the chip's body. Then the chip will fall straight off (If it does not, the body is glued the PCB, in that case try heating the chip's body with your soldering iron and use a little force) and then you can desolder the pins one by one.
 
Putting on the new device is simple after that.

A ultra cheap way we've utilized before and works well is to buy the cheapest POS 3$ USB keyboard you can find and rip it apart to take the controller board out. Then find a couple - nonblocking - inputs on the multiplex to attach your buttons to.