John Carmack Goes On Coding Retreat With OpenBSD

[grok]

It was too early for "quad core" gaming.
Someone did a highly multithreaded, SIMD software Quake 1 a few years ago. As a curiosity and exercize I suppose, but it did work and is incredibly fast, at least if you have lots of CPU and bandwith.

[coder]

It was too early for "quad core" gaming.

Oh, for sure. We just had one of these Compaq servers at work, and wanted to try doing something cool with it. I figured that, if any game had SMP support, it was probably Quake. So, we dropped a Matrox Millenium in there and gave it a whirl. With the rendering being done in software, the potential performance gains would've been substantial.

Remember that the original Pentium introduced SMP support (again, I think for up to quad-CPU setups) back in 1993. So, SMP wasn't that new to PCs. Oddly, I seem to recall that dual-socket Pentium motherboards weren't that uncommon. I had a friend with one, anyhow. I think he just used it for better multitasking, rather than any specific multi-threaded apps.

BTW, at that job, I wrote a toy ray tracer that ran on a quad-Pentium Pro and 8x 400 MFLOPS DSPs. All 12 processors. It was the first time I ever saw interactive ray tracing, although the scenes were quite trivial and the resolution was pretty low.

[coder]

BTW, does anyone think this is at all odd?

I was a little surprised that the C++ support wasn’t very good. G++ didn’t support C++11

I mean, what the heck version was he using?!? Pretty far back in the 4.x series, they had support for --std=c++0x and --std=gnu++0x (from before they even knew what year the new standard would happen). So, the version he was using must've been positively ancient not even to have that. I think he just found --std=c++11 wasn't enabled by default (I know there was some lag between when they introduced that option and when it became the default), and didn't bother to RTFM to see how to switch it on.

I guess he immediately went to Clang and then threw up his hands when his archaic gdb build didn't like it (not that it's exactly hard to download, configure, and make gdb).

[b15hop]

Some limits are time based like no limit between 20:00-6:00 else 120km/h.
The first time you go 320km/h (200mph) and overtake a police car it feels a bit strange.
No matter how fast you go there's always someone going faster.

This literally made my day. Haha! So frigging wish you could do that here in Australia and get away with it...

[Nille_kungen]

This literally made my day. Haha! So frigging wish you could do that here in Australia and get away with it...

You would get away with it, police cars doesn't go that fast and i don't think the helicopter does either
But i don't recommend it.

[Zan Lynx]

Sure, you could drive 200 MPH. For about 10 minutes. Then you'd be out of fuel.

[AndyChow]

That's not the banks' doing - that's what credit card companies like Visa and Mastercard do.

...and for that, they're rewarded with a very handsome tax on a substantial portion of all financial transactions in the countries they dominate. Hopefully, there will one day be a crypto currency that can scale well enough to give them real competition.

Humm, no. I can't blame you for not knowing how the field works, but terminals are owned by banks, of the acquisition supplier. This is not credit cards. There are the issuers (banks), which push the money, the acquirers (banks mostly, a few other players), and intermidiaries (credit card companies, interact (people do use debit cards), and stuff like ApplePay and AndroidPay). When your credit card transaction goes through, it goes throught at least two parties, and three systems (say minimally, bank, credit card, then bank).

To make it more complicated, often credit card companies offer both branding (the credit card you have in your wallet may have the brand Visa, MasterCard, but it also has the name of your bank or a company where you applied for the credit card (ex: Amazon's Chase card)). So it gets a lot complicated very quickly.

[AndyChow]

I said CORE banking operations. Banks do transactions and store them in some bigass list, or look in this list to get information out of it. This didn't change in the last centuries.

Compare with industries like oil and gas where they are now running physical simulations to decide where is best to drill, or a generic big company marketing that does shenaningans with search statistics from Google or other tracking while in the 80s they just snorted cocaine and followed their feelings.

Writing down transactions is a parallelizable task. The only thing that has to be a single thing (or be a centralized system with local caches) is the database itself, and a banking software is usually using a DBMS so it's already designed to send stuff to a database server which can be scaled independently.

Just add more servers running the banking software and split/share the load, while sending the SQL to the same DBMS.

More parallelizable stuff = more copies of the same program running on more physical servers, talking to a more beefy (remote?) database server or a smaller local copy/cache of the main one which then syncs the transactions over. This is a job for IT admins, not developers.

That's just some additional checks (i.e. more sql queries), or data mining happening regardless of the main operation.

Did I say massively parallelizable task? Yeah I did.

Did I also say dedicated DBMS? Yeah I also did that too.

They just add more servers running the same COBOL software and talking to the same database server(s).

If there are traffic issues they add local databases caching the most common requests, but again this is all irrelevant for the COBOL program doing the business logic as it 100% happens behind its back. It gets messages to tell it of new transactions to make and it sends SQL queries to a database (decided by the IT administrators that set up the infrastructure), the same thing that did even in the stone age of computing, what magic does the database server is none of its business.

And being newer, the logic dealing with keeping databases in sync is either something commercial, sold by the DBMS provider (Oracle has something for this I think), or it's something in Java or something.

Credit card companies do this, not banks. And even then, it's not really instantaneous. It takes from 1 to 10 seconds to process a transaction, which for a computer is a pretty long time. And I suspect that they are also exploiting the time you need to physically type the password to also do stuff in the background (another 3-4 seconds).

It's much worse than java just because it is a script language, not compiled. I've seen so much dumb mistakes allowing code injections for PHP that would plain not be possible in Java.

Your post is interesting as a theoretical exercise, but has absolutely nothing to do with how things work in the real world. See my other reply above to understand a tiny portion of how things really work in banking.

Credit card companies do virtually nothing. They don't issue cards, handle transactions, or anything like that. They neither handle acquisition or issuing of funds, and don't process transactions.

I understand why you might think that, but while what you say makes sense, it has absolutely no relationship to reality. Look at any merchant terminal, none will be branded Visa or Mastercard. And try to apply for a Visa card from visa, a MasterCard from mastercard. It's not going to happen. You have to pass through a bank or a corporation (which is a branded card. Even Amazon or Costco can't issue cards, they passed through Chase, and Costco through CapitalOne, which is a very special case and game changer type of company). And when you pass through GooglePay or ApplePay, that's another layer.

The truth is a lot more complicated than how you paint it.

[coder]

You would get away with it, police cars doesn't go that fast and i don't think the helicopter does either
But i don't recommend it.

I imagine it'd be something like if you did that in the Great Plains states of the US. Sure, you can outrun one car, but they'd just setup a roadblock ahead of you. Not easy to hide, in those big, open spaces.

Speaking of which, I remember hearing something about some northwestern state, like North Dakota, erasing its speed limit, during daylight hours. That was a long time ago (and before fracking trucks probably ripped up all the roadways), so I'm skeptical it's still that way.

Anyway, I'm sure some manage to get away with it, but it's the type of thing that can land you in jail (not to mention the whole thing about roads not setup or maintained for it, and possibly endangering others). Not worth it. Especially not when you can just go to a race track.

[coder]

Humm, no. I can't blame you for not knowing how the field works, but terminals are owned by banks, of the acquisition supplier. This is not credit cards. There are the issuers (banks), which push the money, the acquirers (banks mostly, a few other players), and intermidiaries (credit card companies, interact (people do use debit cards), and stuff like ApplePay and AndroidPay). When your credit card transaction goes through, it goes throught at least two parties, and three systems (say minimally, bank, credit card, then bank).

To make it more complicated, often credit card companies offer both branding (the credit card you have in your wallet may have the brand Visa, MasterCard, but it also has the name of your bank or a company where you applied for the credit card (ex: Amazon's Chase card)). So it gets a lot complicated very quickly.

What you paint as the complex part (i.e. the interworking of all these systems) is the part you dismissively ascribe to the credit card companies. I think that's what Starship & I are saying.

The interface between banks and the credit card companies should be a fairly simple API. Otherwise, this stuff just couldn't work as well as it pretty much always has, and the credit card companies wouldn't have been able to entrench themselves in such hegemonic positions.