Apollo 11 Guidance Computer vs. USB-C Chargers • Hacker News Board

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#191

Post by lunias » Sat, Feb 08, 2020, 3:48 PM UTC

folli wrote: post #173

lunias wrote: post #134

Earlier quoted context omitted.

You forgot: Would you like a receipt? (wait) It makes no sense at all. As soon as you input payment it should output gas. There's really no need for buttons or a screen at all (well, maybe except for entering a zip). If they really have to show all that stuff, it can come after I have my gas. Note: languages aren't slow, it's the programs that are slow.

As a non-US citizen: What's the deal with entering ZIP codes in some gas stations in the US? Tax reasons?

I think it's just fraud protection, but data farming makes sense too... It's only required some times at some stations it seems. At the station that I frequent I don't have to enter a ZIP, but other stations owned by the same company just miles away require one.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#192

Post by Someone » Sat, Feb 08, 2020, 3:51 PM UTC

vardump wrote: post #59

TazeTSchnitzel wrote: post #29

Earlier quoted context omitted.

If it can be done efficiently in asm then it can be done in C, C++, perhaps even Rust. But there are sacrifices to be made: unmaintainable “clever” code without clean abstractions.

There are architectures that are just fundamentally C-hostile. Perhaps the most famous one is 6502. No efficient way to implement stack based parameter passing, generic pointer arithmetic, and lots of other bits and pieces. You can still use C on 6502, it's just not very fast. I guess you could define another language that mostly looks like C, but built around particular CPU architecture quirks.

I think that, partly, that it isn’t as much C-hostile as that C compilers mostly target other architectures, and that many C programs take too much for granted, such as the existence of huge 16-bit Numbers or efficient multiplication.

A compiler/linker combo for the 6502 should, for example, analyse the call graph of the entire program to figure out what return addresses it needs to store on the stack at all (alternative 1: store it at a forced address in main memory (will work in single-threaded code that isn’t recursive). Alternative 2: instead of RTS, jump back to the caller (will work for functions that get called from only one place. Aggressively inlining those is an alternative, but may turn short branches into long ones, with their own problems)

Similarly, a compiler/linker for the 6502 probably should try really hard to move function arguments to fixed addresses, and to reuse such memory between different functions (if foo isn’t (indirectly) recursive and doesn’t (indirectly) call bar and vice versa, their function arguments can share memory)

And yes, self-hosting such a compiler would be even more challenging, given the 64kB memory limit.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#193

Post by stevenjgarner » Sat, Feb 08, 2020, 3:53 PM UTC

xp84 wrote: post #114

I'd like to also see an article examining these computing power attributes on the piece of garbage embedded computer on the front of the gas pumps where the lag between registering every keypress is like 800ms, and every screen redraw takes about 2000ms. It takes me an extra 60 seconds to get gas now thanks to how slow these things are, and it is nearly universal despite whether they appear to be 20 year old or new d…

I wonder if any of that performance is due to the intrinsic safety requirements, especially the need to select only intrinsically safe components that will never produce enough energy to ignite gasoline vapors under any transient condition - https://en.wikipedia.org/wiki/Intrinsic_safety

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#194

Post by seszett » Sat, Feb 08, 2020, 4:01 PM UTC

lunias wrote: post #188

seszett wrote: post #163

Earlier quoted context omitted.

I'm a bit surprised to see the comments here on automated gas station pumps. I've used quite a few different ones in a few different countries of Europe (where I go outside Europe, usually the stations are not automated so I can't compare) and I have never had this kind of slow experience. Here in Belgium I don't even get asked if I want a receipt, I can just ask it afterwards if I like (just like for the rewards car…

I'm surprised to see that you (and obviously lots of other people) were able to affect a reduction in advertising by boycotting ad-playing stations. I wonder if it would work here... I live in Minnesota and I'm pretty limited on where I can fill up with 98 RON (called 93 Pump here in the US for some reason...). A lot of stations play video ads with sounds while you stand there.

I don't know if boycott was the only reason, I wouldn't be surprised to hear they were often vandalized.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#195

Post by dna_polymerase » Sat, Feb 08, 2020, 5:47 PM UTC

judge2020 wrote: post #128

Implicated wrote: post #124

Earlier quoted context omitted.

I think about this every time I used one of these machines... isn't it in the businesses best interest to get people through as fast as possible? I have the same experience at grocery stores and convenience stores, I'm always amazed at how slow the machines are with such seemingly simple tasks.

The machines on brand new gas stations and self-checkouts are much faster [also support mobile payment], but performing upgrades to older systems usually isn't worth the cost since they're only at max. throughput for a few hours every week, if that.

Saving a few seconds is only the immediately measurable effect of such an investment, but as you can see in this post it seems the added friction is a major headache for people, and removing it may have long term customer loyalty effects.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#196

Post by Dylan16807 » Sat, Feb 08, 2020, 5:56 PM UTC

masklinn wrote: post #174

Dylan16807 wrote: post #169

Earlier quoted context omitted.

Are you actually trying to argue that smooth scrolling is hard, and specifically because of the display size? On the CPU side, you can figure out how to position a line of text in less than 100 instructions if you store it right. But even if you use 10 million instructions to lay out a handful of lines, you'll never have to hitch. On the GPU side, the pre-retina A5 had a fill rate of 2 billion pixels per second, and…

> Are you actually trying to argue that smooth scrolling is hard, and specifically because of the display size? What I'm arguing is that the problems have little to do with one another, and I'm guessing so do the means. That's like saying building a viaduct is easy because the pyramids exist.

It's all about quickly responding to input.

Because it's the CPU stuff that's the problem here, and that's not fundamentally different. The display differences are a very separate thing and not the cause of the problem.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#197

Post by StillBored » Sat, Feb 08, 2020, 6:00 PM UTC

judge2020 wrote: post #128

Implicated wrote: post #124

Earlier quoted context omitted.

I think about this every time I used one of these machines... isn't it in the businesses best interest to get people through as fast as possible? I have the same experience at grocery stores and convenience stores, I'm always amazed at how slow the machines are with such seemingly simple tasks.

The machines on brand new gas stations and self-checkouts are much faster [also support mobile payment], but performing upgrades to older systems usually isn't worth the cost since they're only at max. throughput for a few hours every week, if that.

I find its the opposite, in the US they weren't this slow when they were rolling out 20 years ago. Probably 10-15 years ago they started to get a lot slower, they went from basically instant to increasingly laggy. Gas stations have been rolling out chip aware ones for the past couple years and overwhelmingly they seem fairly laggy. It seems like there are a couple brands that are faster, and the rest are timeslicing 10k pumps inputs on a mainframe in new jersy (ok that's a joke but wouldn't surprise me if they are javascript based and round-tripping over dial-up to a linux machine fronting a AS400 or something).

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#198

Post by StillBored » Sat, Feb 08, 2020, 6:05 PM UTC

lunias wrote: post #188

seszett wrote: post #163

Earlier quoted context omitted.

I'm a bit surprised to see the comments here on automated gas station pumps. I've used quite a few different ones in a few different countries of Europe (where I go outside Europe, usually the stations are not automated so I can't compare) and I have never had this kind of slow experience. Here in Belgium I don't even get asked if I want a receipt, I can just ask it afterwards if I like (just like for the rewards car…

I'm surprised to see that you (and obviously lots of other people) were able to affect a reduction in advertising by boycotting ad-playing stations. I wonder if it would work here... I live in Minnesota and I'm pretty limited on where I can fill up with 98 RON (called 93 Pump here in the US for some reason...). A lot of stations play video ads with sounds while you stand there.

Well, for a long time the population as a whole in the US managed to kill pay first gas stations. Pretty much everyone just kept driving when they saw the "pay first" signs and the pumps refused to just pump gas. The inconvenience of guessing how much gas you need give the attendant a $10 or $20, pump gas, go back and collect your change was a far worse experience than pump the gas, pay whatever you owe.

Wouldn't surprise me if the ad based gas stations just lost a 10-20% drop in customers if there was an alternative nearby without the ads.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#199

Post by StillBored » Sat, Feb 08, 2020, 6:13 PM UTC

lunias wrote: post #190

clarry wrote: post #172

Earlier quoted context omitted.

> But the interface itself always asks for the least possible things. Diesel/gasoline 95/gasoline 98 then the card PIN, and you can fill up. In Finland, they don't even ask what you're going to pump. You just grab the right nozzle and go.

In the US there are separate buttons to select the grade of gasoline (I always push them to see if I can just bypass all the nonsense, but alas it doesn't work that way). The screens are an add-on gatekeeper that disables the grade selection until all its questions have been answered (NO, NO, NO, NO).

My process has been pick up the handle, hit the grade button, attempt to start pumping since the pay at the pump machines started to roll out a couple decades ago.

This used to work for probably better than half of them due to the fact that they had pay after pumping policies for the cash customers. Hardly ever works anymore, but I keep doing it and sometimes am surprised, while on a road-trip out in the country, when it works. OTOH, I also tend to stop at old crotchety gas stations on principal and have been known to make a U turn if a station has pumps that look like they are older than a couple decades. A few years ago, I stopped at one where there was a $3 taped over one of the digits. I asked the owner about it, apparently his pumps could only charge .01-$1.50 (or some range like that) so every-time gas prices went over or under some threshold he had to physically flip some mechanical gear in the pump and get the state to come back out and recertify the pump. This of course apparently cost more than the poor guy was making in gas, so he was saying that likely the next time it happened he would simply shutdown.

Re: Apollo 11 Guidance Computer vs. USB-C Chargers

#200

Post by bsder » Sat, Feb 08, 2020, 7:27 PM UTC

TazeTSchnitzel wrote: post #90

vardump wrote: post #59

Earlier quoted context omitted.

There are architectures that are just fundamentally C-hostile. Perhaps the most famous one is 6502. No efficient way to implement stack based parameter passing, generic pointer arithmetic, and lots of other bits and pieces. You can still use C on 6502, it's just not very fast. I guess you could define another language that mostly looks like C, but built around particular CPU architecture quirks.

I wonder if you can write fast C for the 6502, though, but you'll have to constrain your use of the language considerably?

The main problem is that most compilers really need lots of registers to optimize well. Without lots of registers, you're constantly spilling to memory and that makes things slow. If you program in assembly, you have visceral knowledge of when you overrun you registers and you will restructure the entire architecture of your program to avoid that.