Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Execution Speed is Deprecated, Use Python!

Name: Anonymous 2012-11-29 0:16

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: Anonymous 2012-12-02 11:31

Why do they call it Python?

BECAUSE IT CRAWLS

Name: Anonymous 2012-12-02 13:45

>>41
Why do they call it Lisp?
Because it's a many-eyed alien monster

Name: Anonymous 2012-12-02 15:45

>>42
(NOT EVEN FUNNY!)> ᕦ(ò_óˇ)ᕤ

Name: Anonymous 2012-12-02 18:11

>>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.

Name: Anonymous 2012-12-02 19:35

>>44
~ $ cat 44.c
#include <stdbool.h>
#include <stdio.h>

int main() {
  bool x = 2; /* valid C code */
  if (x) {
    puts("test succeeds");
  }

  if (x == true) {
    puts("test fails");
  }
}
~ $ gcc 44.c -o 44 -std=c99 -Wall -Wextra -pedantic
~ $ ./44
test succeeds
test fails

Name: Anonymous 2012-12-02 20:27

>>45
There are a proliferation of stdbool implementations for C89/C90 compilers that don't use a native _Bool internally, e.g.

http://www.opensource.apple.com/source/cvs/cvs-39/cvs/lib/stdbool_.h

Systems using broken a broken stdbool like the above are still common, and will cause code like >>44 to break.

Name: Anonymous 2012-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: Anonymous 2012-12-02 23:37

>>47
Even in the 70's languages had separate booleans because you can pack several in one byte.

Name: Anonymous 2012-12-02 23:41

>>44
Yeah, because big endianness and ternary are such great ideas.
At least someone gets it!

Name: Anonymous 2012-12-02 23:42

>>48
Sounds like an idiotic waste of time packing and unpacking that shit for a 70's computer.

Name: Anonymous 2012-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.

Name: Anonymous 2012-12-03 0:20

>>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.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-12-03 1:32

>>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.

Name: Anonymous 2012-12-03 2:53

>>33

in c99 you don't need include anything for having _Bool, iirc stdbool.h just defines _Bool as bool
anyway it works weird

Name: Anonymous 2012-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: Anonymous 2012-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.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-12-04 6:23

>>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.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-12-04 6:40

...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.)

Name: Anonymous 2012-12-04 10:34

>>57-58
Marry me!

Name: Anonymous 2012-12-04 11:05

>>59
faaaaag

Name: Anonymous 2012-12-04 11:12

>>60
Muck off, ``maggot''.

Name: Anonymous 2012-12-04 11:23

>thinking execution speed is deprecated
Shoulda had a V8!

Name: Anonymous 2012-12-04 12:00

>>1
Until the loss of revenue from high execution time surpasses the cost of programmer time.

Name: Anonymous 2012-12-04 15:09

>>63
I don't always install le Gentoo but when I do I take an arrow to the knee.

Name: Anonymous 2012-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.

Name: Anonymous 2012-12-04 17:29

>>64
Fuck off, ``ironic shitposting'' fagshit.

Name: Anonymous 2012-12-04 22:24

>>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.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -