Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

FlapYoJacks: Feb 12, 2009

I have been overinflating my ticket time for the last 3 months and not only has nobody caught on, but I just got a glowing review.
I've been working ~25 hours a week for the last 3 months and nobody cares.

Moral of the story: Never ever work free overtime, and lie about ticket times.

# ? Mar 13, 2020 17:12

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 13:08

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

C�s strength is that it is implementable as a mostly literal translation of code into the lowest-level abstraction expressible by programmers. It also tends to have essentially every lower-level hardware capability directly surfaced in it in some way, often as some sort of builtin. This means that you can write a C program that does essentially anything the hardware can do without worrying too much about the implementation interfering with what you�re trying to do, although compilers do sometimes make that difficult. (It also means, of course, that is very difficult to make holistic, high-level guarantees about correctness, which is usually much more important to your program.) This is much less true of higher-level languages, where there are almost always limitations or unavoidable abstraction costs.

# ? Mar 13, 2020 18:03

QuarkJets: Sep 8, 2008

Dr. Stab posted:

Which language has the most torque?

Fortran, unironically.

# ? Mar 13, 2020 18:36

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

NtotheTC posted:

can't argue with that. footguns are just as powerful as regular guns

Just try to line up your foot with the problem <taps noggin>

Munkeymon fucked around with this message at 21:11 on Mar 13, 2020

# ? Mar 13, 2020 19:18

namlosh: Feb 11, 2014; I name this haircut "The Sad Rhino".

So node.js is the most powerful since it has a V8?

# ? Mar 13, 2020 20:28

redleader: Aug 18, 2005; Engage according to operational parameters

if c was meant to be a portable assembly, then c compilers wouldn't do any optimising, since assemblers don't do any optimising

it also wouldn't have types

# ? Mar 14, 2020 03:09

OddObserver: Apr 3, 2009

redleader posted:

if c was meant to be a portable assembly, then c compilers wouldn't do any optimising, since assemblers don't do any optimising

it also wouldn't have types

There is a huge difference between C as it was first created and modern C as standardized.

# ? Mar 14, 2020 05:59

redleader: Aug 18, 2005; Engage according to operational parameters

OddObserver posted:

There is a huge difference between C as it was first created and modern C as standardized.

i refuse to acknowledge this fact

# ? Mar 14, 2020 06:44

Tei: Feb 19, 2011

redleader posted:

if c was meant to be a portable assembly, then c compilers wouldn't do any optimising, since assemblers don't do any optimising

it also wouldn't have types

Many c compilers have the option to print the C lines has comments next to the assembler it would generate. Is was not a 1:1 and not even a perfect 1:2, but it was generally similar enough to follow.

I saw a compiler do this (it was a Wacom compiler with all the optimizations enabled):

c = 0;
c ++;
printf("%d",c)

this would print 0.

looking at the assembler code would tell you what the gently caress is going on and what the compiler is doing wrong.

# ? Mar 14, 2020 11:13

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

redleader posted:

it also wouldn't have types

listen it's trying as hard as it can

# ? Mar 14, 2020 12:59

Soricidus: Oct 21, 2010; freedom-hating statist shill

Tei posted:

Many c compilers have the option to print the C lines has comments next to the assembler it would generate. Is was not a 1:1 and not even a perfect 1:2, but it was generally similar enough to follow.

I saw a compiler do this (it was a Wacom compiler with all the optimizations enabled):

c = 0;
c ++;
printf("%d",c)

this would print 0.

looking at the assembler code would tell you what the gently caress is going on and what the compiler is doing wrong.

What the gently caress is going on there?

# ? Mar 14, 2020 13:22

Volte: Oct 4, 2004; woosh woosh

Soricidus posted:

What the gently caress is going on there?

Looks like that compiler didn't support c++

# ? Mar 14, 2020 13:24

Tei: Feb 19, 2011

Soricidus posted:

What the gently caress is going on there?

A compiler error. Lowering the optimization level fixed it.

Tei fucked around with this message at 18:02 on Mar 14, 2020

# ? Mar 14, 2020 17:54

Nth Doctor: Sep 7, 2010; Darkrai used Dream Eater!
It's super effective!

Volte posted:

Looks like that compiler didn't support c++

# ? Mar 14, 2020 18:01

JawnV6: Jul 4, 2004; So hot ...

Phobeste posted:

listen it's trying as hard as it can

Volte posted:

Looks like that compiler didn't support c++

# ? Mar 14, 2020 18:57

Ola: Jul 19, 2004

Volte posted:

Looks like that compiler didn't support c++

Dammit I wanted to do that one. :mad:

Tei posted:

A compiler error. Lowering the optimization level fixed it.

Optimization levels:

Medium: If the value is not used after assignment, don't perform any calculations on it.
High: If the value is just used for bullshit like printf after assignment, don't perform any calculations on it.

# ? Mar 14, 2020 21:05

Tei: Feb 19, 2011

Ola posted:

Optimization levels:

Medium: If the value is not used after assignment, don't perform any calculations on it.
High: If the value is just used for bullshit like printf after assignment, don't perform any calculations on it.

I wish I remember more of the details, but It was 20 years ago.

# ? Mar 14, 2020 22:51

redleader: Aug 18, 2005; Engage according to operational parameters

seems to me that optimisations shouldn't change the observable behavior of a program, but then my brain is far too small and inadequate to comprehend the glory of c/++ :shrug:

# ? Mar 15, 2020 03:34

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Optimizing C++ is very hard because it requires the compiler to be able to reason about arbitrary program behaviors. Good optimizing compilers do it well, but not every compiler is good, and this is one of the more common sources of compiler bugs. I remember an instance where a compiler optimized one of my destructors to something like this:

code:

while (p != 0) 
{
    p += 8;
}

Sometimes that took a while to hit zero, and sometimes it just looped. Needless to say we turned off optimizations for that particular library.

# ? Mar 15, 2020 03:37

Kazinsal: Dec 13, 2011

GCC's -O3 optimization level is also historically known to break the standard and often even break programs in the quest for more optimization. Officially it no longer performs standards-breaking optimizations (those have been moved to -Ofast) but it also makes some assumptions about variable lifetime, caching and side-effects that can cause you nasty problems in, say, kernel or driver code.

Also -O3 sometimes unrolls loops enough that they won't fit into your instruction cache anymore and as a result your program is both bigger AND slower on -O3 than on -O2.

# ? Mar 15, 2020 04:17

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

redleader posted:

seems to me that optimisations shouldn't change the observable behavior of a program, but then my brain is far too small and inadequate to comprehend the glory of c/++

It's a bug.

# ? Mar 15, 2020 05:03

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Ola posted:

Optimization levels:

Medium: If the value is not used after assignment, don't perform any calculations on it.
High: If the value is just used for bullshit like printf after assignment, don't perform any calculations on it.

code:

  if(sizeof(variable->name) == 1) {
    // probably just a debug variable, optimize it away
   variable = nullptr;
}

# ? Mar 15, 2020 12:24

Beef: Jul 26, 2004

Optimizing compilers for C is in essence running contrary to its design philosophy, its entire purpose was to just simplify some common asm patterns and to give the programmer all the power to do the optimization himself. There are tons of features that even in the 80's they knew hosed with automatic optimization: C calling convention forcing copy to stack, random bullshit that can be linked in from literally anywhere and of course the aliasing problem compounded with arrays degenerating to pointers. There is a reason, beyond legacy, that FORTRAN is still common in numerical applications. Most of the compiler advancements for decades was in that space and only later awkwardly ported to C/C++.

All the UB bullshit is mostly to allow the compiler to make some assumptions to get any decent optimization done. There are plenty of instances of "faster than C" in other languages for certain workloads.

Don't mind me, I'm just venting, I spend a lot of time these days looking at asm output and screaming abuse at the compiler.

# ? Mar 15, 2020 14:09

Ola: Jul 19, 2004

NihilCredo posted:

code:

  if(sizeof(variable->name) == 1) {
    // probably just a debug variable, optimize it away
   variable = nullptr;
}

This is why professor code is so blistering fast and has no bad side effects.

# ? Mar 15, 2020 15:46

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Plorkyeran posted:

It's a bug.

My brain has the same bug

# ? Mar 15, 2020 15:59

Spatial: Nov 15, 2007

Beef posted:

Don't mind me, I'm just venting, I spend a lot of time these days looking at asm output and screaming abuse at the compiler.

lol same. I often have to go to assembly for speed critical stuff on embedded.

Here's a recent compiler horror of that nature... How does this switch get compiled? All the inputs and cases are chars and their range is limited. Pretty easy right? I'm practically whispering into the compiler's ear to use a jump table.

code:

switch (input) {
    case 'a': thingX(); break;
    case 'b': thingX(); break;
    case 'c': thingY(); break;
    case 'd': thingY(); break;
    case 'f': thingY(); break;
    case 'p': thingZ(); break;
    case 'o': thingZ(); break;
    case 'j': thingZ(); break;
    case 'x': thingZ(); break;
    case 'y': thingZ(); break;
}

Nope! It produces a series of conditional branches, about the worst possible thing to do that is technically correct. Not only is this suboptimal in general, on this particular platform there is literally a dedicated instruction for doing byte-indexed jump tables!

code:

cmp r0,#'a'
beq casea
cmp r0,#'b'
beq caseb
cmp r0,#'c'
beq casec
cmp r0,#'d'
beq cased
cmp r0,#'f'
beq casef
cmp r0,#'p'
beq casep
cmp r0,#'o'
beq caseo
cmp r0,#'j'
beq casej
cmp r0,#'x'
beq casex
cmp r0,#'y'
beq casey
b   nomatches

Here is what the code would look like with a jump table. Subtract the offset of the smallest case, range check, and jump to table.

code:

subs r0, r0, #'a'
cmp  r0, #'y' - 'a'
bgt  nomatches
tbb  [pc, r0]
<table of 25 bytes here>

# ? Mar 15, 2020 18:34

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Is it any smarter if you do this?

code:

switch (input) {
    case 'a':
    case 'b':
       thingX();
       break;
    case 'c':
    case 'd':
    case 'f':
        thingY();
        break;
    case 'p':
    case 'o':
    case 'j':
    case 'x':
    case 'y':
        thingZ();
        break;
}

# ? Mar 15, 2020 19:16

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

Spatial posted:

lol same. I often have to go to assembly for speed critical stuff on embedded.

Here's a recent compiler horror of that nature... How does this switch get compiled? All the inputs and cases are chars and their range is limited. Pretty easy right? I'm practically whispering into the compiler's ear to use a jump table.
code:
switch (input) {
    case 'a': thingX(); break;
    case 'b': thingX(); break;
    case 'c': thingY(); break;
    case 'd': thingY(); break;
    case 'f': thingY(); break;
    case 'p': thingZ(); break;
    case 'o': thingZ(); break;
    case 'j': thingZ(); break;
    case 'x': thingZ(); break;
    case 'y': thingZ(); break;
}
Nope! It produces a series of conditional branches, about the worst possible thing to do that is technically correct. Not only is this suboptimal in general, on this particular platform there is literally a dedicated instruction for doing byte-indexed jump tables!
code:
cmp r0,#'a'
beq casea
cmp r0,#'b'
beq caseb
cmp r0,#'c'
beq casec
cmp r0,#'d'
beq cased
cmp r0,#'f'
beq casef
cmp r0,#'p'
beq casep
cmp r0,#'o'
beq caseo
cmp r0,#'j'
beq casej
cmp r0,#'x'
beq casex
cmp r0,#'y'
beq casey
b   nomatches
Here is what the code would look like with a jump table. Subtract the offset of the smallest case, range check, and jump to table.
code:
subs r0, r0, #'a'
cmp  r0, #'y' - 'a'
bgt  nomatches
tbb  [pc, r0]
<table of 25 bytes here>

Try putting in a few dummy cases? That might bias the compiler towards using a table.

Comedy option: do it by hand using GCC's computed goto.

Slightly less comedy option: if these are just simple function calls, use a table of function pointers.

# ? Mar 15, 2020 19:54

Spatial: Nov 15, 2007

In reality they're all different cases with different code, the thingxyz stuff is just filler to make it easy to read. There is a way to get it to behave and that's to offset the cases so they range from 0-N. Then it'll generate the table.

I imagine GCC will do a perfect job here. This is IAR ICCARM which is enterprise grade software: slower, worse, and several thousand dollars

e: Yup!

Spatial fucked around with this message at 21:06 on Mar 15, 2020

# ? Mar 15, 2020 20:07

Beef: Jul 26, 2004

I'm seeing relative jumps to the next instruction being generated by the compiler, which is interesting.

# ? Mar 15, 2020 21:09

OddObserver: Apr 3, 2009

Beef posted:

I'm seeing relative jumps to the next instruction being generated by the compiler, which is interesting.

Did you check the relocation records? Sometimes those are placeholders till dynamic linking.

# ? Mar 15, 2020 21:15

Beef: Jul 26, 2004

Good suggestion, I'll check. The whole thing is statically linked, and in this case I think it's libm being statically linked into the object file.

# ? Mar 15, 2020 21:42

Athas: Aug 6, 2007; fuck that joker

'switch' has always been a weird wart in C, since it is not at all obvious what kind of assembly it's going to turn into (unless you assume a chain of conditionals).

And of course, the ease with which case fallthrough has lead to bugs (although I think all modern compilers now warn by default).

# ? Mar 15, 2020 23:21

Carbon dioxide: Oct 9, 2012

https://github.blog/2020-03-16-npm-is-joining-github/

Can github make npm great?

# ? Mar 16, 2020 21:55

taqueso: Mar 8, 2004

rip github

# ? Mar 16, 2020 22:13

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

GitHub is Microsoft right, so npm is Microsoft?

# ? Mar 16, 2020 22:30

Kazinsal: Dec 13, 2011

It's been a long time since Microsoft has done the whole embrace-extend-extinguish thing but I wouldn't mind if they brought it back just this once

# ? Mar 16, 2020 22:36

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Kazinsal posted:

It's been a long time since Microsoft has done the whole embrace-extend-extinguish thing but I wouldn't mind if they brought it back just this once

What if they replaced nuget with npm though?

# ? Mar 16, 2020 22:48

JawnV6: Jul 4, 2004; So hot ...

leper khan posted:

What if they replaced nuget with npm though?

other way 'round

# ? Mar 16, 2020 23:02

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 13:08

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

JawnV6 posted:

other way 'round

How sure are you that we live in the good timeline?

# ? Mar 16, 2020 23:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »