Developer time is the most valuable resource. Writing in Python may cause slower code, but it is in reality much more efficient because you will get an exponential amount of more work done!
Name:
Anonymous2012-11-29 0:21
In c, suppose:
foo = false;
Should I write:
foo = bar;
Or:
if (bar) foo = true;
Will the first statement always execute faster, or does it depend on whether bar is true or false?
>>31
Intel made processors that melted people's balls and backed off from those blistering (HEH) speeds. Computers are no longer commodity devices if they're hotter than the sun and require heavy equipment to cool.
Since you brought it up: The effective processing speed did not hit a wall. Intel's >3GHz offerings from around 2004 used a lot of stupid tricks to make it seem like they were faster than they actually were, because as long as they could get away with a higher MHz label, they could sell newer processors. The per-instruction latency in the PIV and friends was actually harmful to overall performance compared to, say, a PIII-based design with the same clock speed.
If they'd done it "the right way" the whole time (ie. relying only on smaller processes for faster speeds instead of doing parlor tricks with the instruction pipeline) you'd see a much gentler slowdown over time.
Name:
Anonymous2012-12-01 15:05
>>4
It does, but it's a library feature (include stdbool.h), not a language feature like it is in C++ and other languages.
Name:
Anonymous2012-12-01 15:15
>>32
If they'd done it the right way the whole time they'd develop SPARC or Setun derivative.
Name:
Anonymous2012-12-01 16:41
>LE LELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>LE MEME FACE WHEN
>LE MEME FACE WHEN
>LEEEEEEEEEEEEEEEEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>EGIN!
>EGINGIN!!!!
>EGINGINGWIM!!!!!!!!!!!!!!!!!!!!!!!!
>MY LEL FACE WHEN LE /G/RO IS FUQIN EGIN
>>34
Hence the "scare" "quotes." Doing it that way was not actually very damaging in the short term, and even though they "wasted" a lot of money and engineering talent on making their CPUs look faster, they gobbled up a lot of market share in the process. It was the right move for Intel in terms of corporate self-interest.
Name:
Anonymous2012-12-01 19:48
>>31,32
Intel jumped onto the RISC bandwagon and became obsessed with pushing their CPUs as fast as they could, even if it meant using such a deep pipeline that anything but pure sequential code got hit with a huge latency penalty.
Name:
Anonymous2012-12-02 0:46
So basically a market full of retards made pony trick profitable which is why we had P4.
>>32
Fun facts: P4 processors did not have a barrel shifter so their shifts and rotates were slow, and even the ALU was pipelined so that operations <= 16 bits of data were around twice as fast as those needing 32 bits. The ALU ran at double the clock of the rest of the logic, and could beat Core/Core2 in straight-line execution in very very specific pieces of code(basically integer adds only). Very sensitive to instruction and data alignment, not unlike most RISCs.
Name:
Anonymous2012-12-02 6:40
>>39
Remember when you ran away and I got on my knees and begged you not to go because I'd go berserk?
Well, You left me anyhow and then the days got worse and worse and now you see I've gone completely OUT OF MY MIND!
>>33 stdbool is pointless bullshit created to appease C++ programmers. It just adds some extra typedefs for ``comfort'', the actual semantics of true and false values are the same regardless of whether stdbool is used or not. Case in point:
#include <stdbool.h>
...
bool x = 2; /* valid C code */
if (x) {
/* test succeeds */
}
if (x == true) {
/* test fails */
}
If you aren't working on a mixed codebase there is less than zero reason to use stdbool.
>>34
Yeah, because big endianness and ternary are such great ideas. IHNBT
>>39 P4 processors did not have a barrel shifter
Really? They couldn't spare the transistors for that of all things? Terrible!
the ALU was pipelined so that operations <= 16 bits of data were around twice as fast as those needing 32 bits.
Wow. Did the designers really think people would actively take advantage of this?
Very sensitive to instruction and data alignment, not unlike most RISCs.
Except that on RISC, one generally assumes that operations using the machine's native word size will be fast.
Systems using broken a broken stdbool like the above are still common, and will cause code like >>44 to break.
Name:
Anonymous2012-12-02 22:28
>>44
But booleans and integers still have very distinct meanings. That's why I use bool; it aids in clarification. We're not in the 1970s anymore, you know.
Name:
Anonymous2012-12-02 23:37
>>47
Even in the 70's languages had separate booleans because you can pack several in one byte.
Name:
Anonymous2012-12-02 23:41
>>44 Yeah, because big endianness and ternary are such great ideas.
At least someone gets it!
Name:
Anonymous2012-12-02 23:42
>>48
Sounds like an idiotic waste of time packing and unpacking that shit for a 70's computer.
Name:
Anonymous2012-12-02 23:59
>>50
70's computer hardware was not as strong as they were today. Little techniques like that help increase the use of the machine's capabilities.
>>48
You can still use single bit flags in C. The OpenGL API uses them extensively, for instance.
>>50,51
There's still a code size and execution time cost to testing single bits instead of whole bytes (on a byte oriented machine, anyway). People might have done it more often in the 1970s because memory was much more expensive, but it would still be considered an optimization rather than the norm.
>>44
It wasn't about transistor count but keeping the delay between each pipeline stage as short as possible. It's the same with the odd add behaviour --- they probably figured propagating a carry through all 32 bits could be too slow for 1 cycle, so cut it up into 2 pieces with early-out.
AMD's "faildozer" was along the same lines too... but they came a few years later so the process advantage helped, although it still wasn't enough.
in c99 you don't need include anything for having _Bool, iirc stdbool.h just defines _Bool as bool
anyway it works weird
Name:
Anonymous2012-12-04 4:30
>>53
Yeah, missed explicitly stating that more transistors = more delay.
I'd like to see their analysis for a 1 cycle vs. a 2 cycle design. Without seeing any numbers, I'd tend to think that people would do many more 32 bit ops, so better to just keep the ALU to a very tight, single cycle. Of course, that wouldn't work on the P4 anyway because the pipeline was so fucking deep... does Core still do it this way?
>>53
Yes, looking at this a little more I believe _Bool is the actual C99 type that the compiler needs to understand as only ever holding a value of 0 or 1. The compiler must know this because using a plain integer type would lead to conversion problems like >>44.
Name:
Anonymous2012-12-04 5:14
>>55
Just for laughs you can go back and look at code written for the original 68000, which had a 16-bit ALU. Since 32-bit operations took twice as long, most code used 16-bit words whenever possible.
>>55
I think you're confusing the bitness of the instruction with that of the operands. I was referring to add instructions that are 32-bit, but which do not carry between bit 15 and 16, e.g.
add eax, 1 with eax=00000000 completes in 1 cycle
add eax, 1 with eax=0000FFFF takes 2 cycles
add eax, 65535 with eax=00000001 also takes 2 cycles
They probably thought "why wait for an add that's done already", and it would make sense for things like loop counters, but then again the single-byte inc r/dec r on the P4 seems to always act as if the carry was needed. Compared to the ones before and after, the P4 microarchitecture was just weird.
...and AMD remains roughly 3 years behind in terms of IPC. http://media.bestofmicro.com/I/O/298752/original/overall.png
(Would've liked to see some of AMD's CPUs from 2005 there. The P4 really sucks in that comparison but everything else was at least 2 years newer.)
>thinking execution speed is deprecated
Shoulda had a V8!
Name:
Anonymous2012-12-04 12:00
>>1
Until the loss of revenue from high execution time surpasses the cost of programmer time.
Name:
Anonymous2012-12-04 15:09
>>63
I don't always install le Gentoo but when I do I take an arrow to the knee.
Name:
Anonymous2012-12-04 17:11
>>63
There aren't many applications worldwide where that scenario is true. Even when it is true, chances are, it's already a solved problem that is solved using a language such as C with Python bindings to make use of that code.
>>63
That would be called opportunity cost, and what you said is self evident.
These labor hours cost more than the cost of the speed of the program.
Well, the claim entails that one is more expensive than the other (and if it wasn't, then the opposite would be true: that the cost of high execution time surpasses the cost of the programmers' time).
Basic logic, bro.