Commercial Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

127 Excellent

1 Follower

About Luke

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Sweat Mountain, GA

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
    I belong to both VATSIM & IVAO
  • Virtual Airlines

Recent Profile Visitors

2,848 profile views
  1. I think we both agree on the importance of single-thread performance to current simulations, but my point is that simulators are an extreme niche that in no way are driving processor design. The center of gravity is towards lower power consumption and more cores, or some combination of the two. Cheers!
  2. If it's more than 10%, I'll be shocked. There's a world of difference between early marketing materials and then what makes it out into production. Intel has been caught out several times by challenges with chip architecture and fabrication issues, so I'll believe it when I see it. If you're waiting for input, then you're clocked down to 800Mhz or whatever the chip will scale down to. LOL Apps are single-threaded because for 99% of the use cases, performance is already "fast enough" and what you need is simplicity in the code base over an optimization that only the programmer cares about. The vast majority of times, your apps are waiting for user input, I/O or some other long-blocking tasks, and the compute-intensive portions run for maybe 10-15ms at a time. Shaving off a millisecond doesn't matter. I'll stand by what I said earlier - anything valuable that was performance sensitive has by and large been ported to multi-core and scales with core count, not single-thread speed. The reason why most stuff is still dependent on a single thread is because it's a simpler coding mechanism and it's already fast enough. Cheers!
  3. If it relies on new instructions and a recompile by software authors, it's not going to go anywhere. This reminds me of the days with new instructions in the 80286 and 80386 that we simply couldn't take advantage of without multiple code paths and versions, and all of the attending support nightmares. Unless you're in a very specific niche where the need for performance is almost unlimited and the user base asymptotically approaches 1, this is a non-starter. Where I see significant possibilities is in managed code. If you're running in MSIL or on a JVM, you're not actually compiling your app to machine code, just an intermediate version that can be executed on the client machine using whatever capabilities the local processor has. I could see a .NET VM taking advantage of these paths on a particular processor family, but again it's a question on Microsoft's end whether they want to go down that road and what the cost/benefit ratio would be. Let's face it, single-thread performance is a niche, getting smaller and smaller every day, intersecting with the equally small and declining niche of compiling code directly to machine instructions. Cheers!
  4. Luke

    Hyperthreading for P3D. Yes or no?

    SMT in and of itself isn't "old tech". While it's been around for a few years (since the P4 in the x86 world) it's become increasingly necessary as CPUs got faster and faster and cache/memory (never mind I/O) didn't keep pace. The premise of HT was that if your core was stalled for several thousand cycles waiting on L2 or L3 cache or (gasp) RAM, you could have the execution units do something else while that thread was stalled. The challenge with SMT is that it's a security risk - with speculative execution and timing attacks, you don't want to have other processes (or users) executing on and changing the state of your core. That's what Spectre and Meltdown were all about. In our worlds, they don't matter much, but then again to Intel and AMD, we don't matter much compared to the Amazons, Googles and Microsofts of the world who buy very, very large processors to be used in a multi-tenant world. Given the security risks and almost unlimited transistor budgets, it makes more sense just to have more real cores and to take a pass on SMT. Just like in the Intel world, where it appeared in the P4, then disappeared until Sandy Bridge, I expect SMT may make a comeback if at some point we either work around the security implications or start getting limited transistor budgets again. Cheers! Luke
  5. If he's hitting the 32-bit VAS limit, a faster CPU will not help him. He needs to turn down the detail not to lighten the burden on the CPU, but to use less memory.
  6. I'm not disagreeing with you - I don't see any need or purpose to defragmenting an SSD. My point is merely that even if the SSD was 100% fragmented, a defrag would add an extra 200GB or so to lifetime writes (trivial compared to total lifespan) and would not likely be needed again (the vast majority of files on a drive are never overwritten). The SSD failed for some other reason, which happened often for early SSDs. Cheers!
  7. Defrag is just reading and writing, nothing more, just into specific locations. It won't make a drive fail any earlier than an equivalent amount of "regular" writes. Plenty of early SSDs failed prematurely for reasons utterly unrelated to flash wearing out. Cheers!
  8. What's the GPU usage at? Cheers!
  9. Luke

    DXGI Prepar3d V4 Help!!

    Jim, please stop for a second. I tried mentioning this in the last page and you accused me of being untruthful and saying I knew that what I was saying was not correct. I write FS software add-ons and I've had them crash my simulator more than a few times - I know how this works. (And with respect, I would never accuse you of deliberately stating something you knew to be incorrect, but if I did I expect you would ban me post-haste. Please extend to me the same courtesy.) First, if Prepar3D.exe (or FSX.exe) is terminated by Windows then the fault was either the executable or a DLL it loaded. End of story, no ifs, ands or buts. Is this code written by MS or LM? Not necessarily in the case of a DLL but it is certainly that process. Windows does NOT terminate a random process if it gets an error, it terminates the process that caused said error. It's the same with Linux and MacOS. This is Operating Systems 101. Second, you stated earlier in this thread that it couldn't be an LM bug since everyone would encounter it. That's not correct either - many bugs need a specific combination of system, hardware, OS, and data to be triggered. L-M has fixed many bugs that I personally have never encountered (nor have a majority of P3D users) but that doesn't make them "not a bug in P3D". My software has had bugs triggered by specific simulator, OS and aircraft combos and many users never encountered them. That's what made them so hard to track down. I've personally never encountered this issue, but given that the user reports indicate it only happens with P3D and it occurs with stock systems and configurations strongly suggests it's something in P3D's core DirectX/Graphics code, but it's very sensitive to hardware and/or OS. I have a lot of sympathy for L-M is this is doubtless very difficult to track down, but that doesn't make it any less their problem. It's easy to blame the user's configuration - but to piggyback on another thread here there are plenty of times where it really is a software bug, just very, very obscure. I've had a bug where a .NET assembly depended on a specific MS Visual C++ runtime but the error message was rare and cryptic. Not too long ago FSDreamTeam broke GSX by inadvertently including a Windows API call that didn't exist prior to Windows 8 but spent a few days blaming anti-virus packages. They are hard, obscure bugs, but they remain bugs. You have said in the past that you are defensive of L-M because you appreciate what they have done to move the Microsoft-based franchise forward. I too appreciate what they have done - most of us that have FSX (or FS9) still installed will fire it up from time to time and it is light years behind what P3Dv3 or P3Dv4 bring to the table. We are in L-M's debt, but we do them no favors when we improperly dismiss legitimate or plausible flaws in their software. The most trustworthy ally is one who is honest, not a sycophant or a cheerleader. You and I disagree so much because I am a professional software author, in both the FS world as well as externally. I've lived and breathed this for over 30 years. My .NET apps have been used by thousands of people in millions of simulated flights. What I've done professionally has been used by more people than FS itself. I greatly respect your efforts in helping people here, but on certain core areas of software design your understanding of the way Windows apps work is incorrect and it does AVSIM's audience a disservice. There's something here. The right approach (for everyone, not just you Jim) is to see if we can find the commonality between the cases to track it down. It's likely a bug in P3D or the NV drivers (less likely, unless there's a NV-provided P3D profile in them). Either way you will need L-M to get this fixed. Cheers!
  10. FSUIPC flight saving is likely to cause freezes of under five seconds in the case of an improperly configured anti-virus package. I use software with similar functionality that can safely log flights of over 14 hours without issue. You should make sure that your anti-virus excludes the FS directories, the My Documents\FSX files directories as well as the FSX process itself. IIRC correctly ActiveSky had a race condition issue back in the AS2012 days where they got a hang (for 18 minutes) every now and then when running FSX on >4 cores. Cheers!
  11. What exactly is your application - does it require a server? If so, is it Windows/Linux? Does it require a database, cache or network access? Lots depends on what you need done in AWS. Cheers!
  12. I suspect this is more about reducing (or maintaining) the raw number of PCIe lanes out of the CPU rather than increasing an individual graphics device's bandwidth. I don't know of anything that would require PCIe x16 over x8 or x4. I'm pretty certain no one is saturating PCIe x16 with P3D or (definitely) FSX. Cheers! Luke
  13. Luke

    DXGI Prepar3d V4 Help!!

    Actually, it does. The terminated program was the one that made the bad call. Cheers!
  14. Luke

    Why the World is Running Out of Pilots

    1) Probably fewer than prevented by automation. There are certainly going to be new classes of fatal incidents created by automation; so long as they are fewer than caused without it's a net win. 2) If the airfare is 5% cheaper, people will likely do it. I've seen no evidence that people consider much beyond price. Cheers!
  15. No, they use totally different registry entries. Cheers!