Newish buggy

**jwiede** · 12-01-2019, 06:28 PM

Originally Posted by MonroePoteet

Yeah, without access to the source code (including maps), it's all guesswork for me. RE: parameter validation, handling error states, etc. there's always a problem with robust code being slow. At the inner loops (like the raster block transfers into graphics memory and the code directly feeding those routines), I can imagine error checking and parameter validation is fairly minimal to keep the performance up.

Actually with modern CPU's branch-prediction architectures, you can construct error code checks (any simple, non-loop branches, really) in such a way that they're effectively "free" as long as the code remains on the "expected"/"non-branching" path, and performance in error paths is generally (not always, but generally) moot. Most modern compiler toolchains do so automatically.

The notion that checking for error codes on API returns implies a performance hit hasn't been an accurate assumption for some time now. Obviously, additional checking like range checks, parameter validation, etc. incur performance cost, but simple error code return checks (typically a 0/!0 or !0/0 compare), as well as other such simple, non-loop branches, do not generally impact performance any longer.

I can give the TL ; DR explanation if desired, but if you understand the basics of instruction speculation and branch prediction, you should be able to figure out why for yourselves.

**scallahan1** · 12-01-2019, 07:18 PM

It does the same crash in Layout AND Modeler 2019.1.2 and 2019.1.3 but okay in 2019.0.3

**Ma3rk** · 12-01-2019, 08:53 PM

Originally Posted by jwiede

I can give the TL ; DR explanation if desired, but if you understand the basics of instruction speculation and branch prediction, you should be able to figure out why for yourselves.

Quite alright John. My eyes rolled up into their sockets some postings back. I thank all of you for talking a look & demonstrating how discriminating it is.

I'm going to assume for now that along with my initial report & the attention given here, someone either in the high towers, or mid to lower dungeons has caught wind by now.

**MonroePoteet** · 12-01-2019, 09:25 PM

Originally Posted by jwiede

Actually with modern CPU's branch-prediction architectures, you can construct error code checks (any simple, non-loop branches, really) in such a way that they're effectively "free" as long as the code remains on the "expected"/"non-branching" path, and performance in error paths is generally (not always, but generally) moot. Most modern compiler toolchains do so automatically.

<snip>

OK, thanks. Unfortunately, at the "trusted interface" level (such as inner loop code) if a caller violates that trust it may be the only desirable error handling technique is to crash and find the culprit. Dunno. I think the BitBlt code can't afford ANY sort of parameter checking without a serious performance hit (i.e. it's executed millions of times so is optimized to the maximum), so if someone passes something in that's wrong, an ACCVIO, the associated crash, and the dump analysis is the "error handling" - *hopefully* before the product ships!

RE:

Originally Posted by Ma3rk

I'm going to assume for now that along with my initial report & the attention given here, someone either in the high towers, or mid to lower dungeons has caught wind by now.

I wouldn't count on it unless you submit a bug report. I'm not pursuing further LW time investment post-PBR until I have a *LOT* more time to learn it well, so I'm not submitting / debugging for a while. Other stuff to do!

mTp

**Ma3rk** · 12-01-2019, 11:48 PM

Originally Posted by MonroePoteet

RE:

I wouldn't count on it unless you submit a bug report. I'm not pursuing further LW time investment post-PBR until I have a *LOT* more time to learn it well, so I'm not submitting / debugging for a while. Other stuff to do!

mTp

That's what I meant. I did file a bug report.