Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Null Pointer
May 20, 2004

Oh no!
A couple of years ago I started making a compiler for a toy language. I ended up getting busy, so it got pushed onto the back-back-back burner. Usually that's where my projects go to die, but I really liked some of my ideas and wanted something to come of it.

This weekend I finally found the time and the inspiration. I opened up the code and... hey, it's pretty good! It's well-commented and well-designed. All of my missing AST visitors are generating errors so I know exactly where I left off. I'll have no problem jumping back in and getting to work.

Unfortunately, I lost the documentation for the language.

Adbot
ADBOT LOVES YOU

Null Pointer
May 20, 2004

Oh no!

Scaevolus posted:

This is a horror.

Yes.

De Morgan's laws.

Null Pointer
May 20, 2004

Oh no!

Scaevolus posted:

No, the problem is about cache aliasing.

Well, the first problem is conflict misses in the cache. The graphs they created show capacity misses, which is an unrelated problem.

The real horror is microbenchmarking without taking at least one computer architecture course.

quote:

Every low-level performance related question on StackOverflow should be required to provide MFLOPS information for the whole range of cache relevant data sizes!

Null Pointer
May 20, 2004

Oh no!

Zombywuf posted:

To be fair the compiler designer is supposed to have done that for you.

"Any sufficiently smart compiler..." is the start of a lot of questionable ideas, not the least of which is Itanium. A lot of really simple-sounding optimizations turn out to be very difficult or impossible.

Null Pointer
May 20, 2004

Oh no!

yaoi prophet posted:

What exactly happened with Itanium?
IA-64 makes the compiler (or assembly programmer) responsible for almost everything, including instruction scheduling and data hazard resolution. The first Itanium chip was delayed for some years, in large part due to the fact that compilers turned out to be harder to write than the HP engineers thought. As far as I know the compilers still aren't very good.

Some day, when the space aliens come and give us their hypothetical future space alien compiler technology, we will all be running Itanium processors.

Null Pointer
May 20, 2004

Oh no!

Zombywuf posted:

It's not a particularly complex bit of code, and it seems like nearly every single CPU tech enhancement of the last 20 years has been about making this kind of code faster. The horror is that all the enhancements have made it nearly impossible to optimise for.

This specific loop splitting example is not a trivial optimization. For example, synonymous virtual addresses could introduce a true (RAW) dependency between loop iterations, and it is either impractical or impossible to detect this situation. This is obviously a rare counter-example, but it can happen, and as a language implementer you now have a choice to make about how you will allow the user to express this possibility.

For these sorts of optimizations in general, at compile-time you know absolutely nothing about the memory hierarchy of the target machine. There are very many possible configurations and they all have distinct pathological cases which are potentially dependent on input. This means any optimization needs to be chosen at run-time, which effectively means you will need to emit a different branch for every known type of cache.

Null Pointer
May 20, 2004

Oh no!

Zombywuf posted:

Soooo, what you're saying is that optimising for modern hardware is the real horror?

No, the real horror is expecting the compiler to solve a design problem.

If you are interested in high performance there are many safe assumptions you can make at the design level: spatial and temporal locality, and sequential access with a short stride, are all good decisions regardless of the specific processor you are using. You can't say nearly as much at the level of bit fiddling. (Edit: try the loop example from the Stack Overflow post using a single array with the values from A, B, C and D interleaved. The compiler and CPU cannot help you when you choose a stupid data structure like four arbitrary arrays.)

Modern hardware might be difficult to understand, but it really is a lot faster. Keep in mind that the pathological cases are simply the same as not having a cache at all.

Null Pointer fucked around with this message at 22:33 on Dec 20, 2011

Null Pointer
May 20, 2004

Oh no!

feedmegin posted:

Not really. In theory the idea was that the Itanium chips could be very simple (and thus very highly clocked)

This is the point of explicit instruction scheduling instead of using hardware, yes.

Null Pointer
May 20, 2004

Oh no!

pigdog posted:

His game is a very good example though of a quality product. Code quality isn't in fact about how good the code looks, how reliable it is or whether it runs as fast as it could -- it's about whether people would want to use it. In this case, whether they'd want to play the game. Even it (in comparison) runs like rear end and is written badly, the game has still sold millions of copies and is by any means an unabashed success.

The fact is that people don't care about the code or the performance being terrible, or at least don't care enough not to play the game. Other developers may look at his code and find it terrible, but it doesn't matter while he's laughing all the way to the bank.

That's a serious lesson to consider. People with different background put different importance on different aspects of software. Things that a developer may consider important, such as cleanliness of code, reliability, etc, may but may also not necessarily be what the customer, or the users consider important. Don't get me wrong, I love fully tested, clean and bulletproof code, but there may be cases where making tradeoffs is the right thing to do.

This is a software engineering horror.

'Fitness for purpose' is not the same thing as quality. Consider PSN, before last April. Millions of people wanted to use it. Sure, Sony was transmitting and storing unencrypted credit card numbers, but nobody cared - information security just wasn't important to their customers. Hell, even after the breach, most people blamed the "hackers" for everything. By your definition, PSN was a very good example of a quality product. Do you think Visa and Mastercard agree with you?

Picking on an indie game is low-hanging fruit, but Mojang's success and proven ability to deliver does not change the fact that Minecraft has serious defects.

Null Pointer
May 20, 2004

Oh no!

how!! posted:

The fact that my theoretical refactor broke it and resulted in a fine is actually a good thing. At least now we can re-implement the Kwijybo Act of 1873 code, and this time we can do it so that its comprehensible and documented. The fine we had to pay is the price it costs to improve the business.
Warning: the programming advice contained herein will most likely get you fired/sued/prosecuted.

Adbot
ADBOT LOVES YOU

Null Pointer
May 20, 2004

Oh no!

GrumpyDoctor posted:

how!!, do you have a blog? If not, you should start one. I'd love to read it.

Subject: Not updating for a while

I broke the Kwijybo Act of 1873 code during a rewrite, and as it turns out that the Kwijybo Act of 1873 is an important part of Kwijybian environmental conservation law. Long story short, I'm now being prosecuted under the Lacey Act and I will probably go to prison.

- how!!

Current mood: apprehensive
Current music: ~ One Winged Angel ~ Nobuo Uematsu

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply