We are migrating our multi-threaded application to Delphi XE7 and are testing the new TParallel.For function. We have found that it parallelizes well on laptops (Core I-5/Windows 7 with 4 cores) achieving close to consistent 100% cpu usage.
When we run exactly the same code on an Intel Xeon/Windows 2008 R2 with 2x12 cores, it only achieves about 3% usage and appears to be only using 2 of the cores.
The same problem is evident using the Conways Life demo sample application.
We have tried using the OTL which parallelizes close to 100% on the Xeon, but unfortunately we have run into the "Not enough quota" issue and can't seem to resolve that, either.
Has anyone else run into this? We have tried using the Stride parameter, SetMinWorkerThreads and SetMaxWorkerThreads() methods but to no avail.
Related
I have an electron app that renders to a 1280x720 canvas and is using requestAnimationFrame. The app works perfectly on my machine running, 16GB ram, i7, x64, with a GTX 1080 GPU. When I run the same app on other computers it runs extremely slow. I have tried a surface go, but also my friends computer who is running much new and better hardware than mine and it still runs at a potatoes rate. Any idea what could cause this discrepancy?
I have tried using setInterval to see if there was a difference and there was a minimal difference but the app is still unplayable. I also tried to combine all my modules into a singleton as per their advice and I noticed a slight increase.
I have the following weird behaviour on a machine with 40 cores: calling System.Environment.ProcessorCount in fsi (12.0.30815.0) and fsianycpu (12.0.30815.0) leads to different results.
In fsi I get System.Environment.ProcessorCount = 32 in fsianycpu I get System.Environment.ProcessorCount = 40. This also seems to affect the task parallel library which only uses 80% of all available cores when a simple test code is run from fsi (which has the wrong processor count).
What could be the reason?
FSI is probably running under 32 bit mode by default. You should be able to check via Task Manager assuming you are running under Windows of course. I suspect this is a limitation of apps running under WoW64 (what you run your 32 bit apps in using a 64 bit Windows).
See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384228%28v=vs.85%29.aspx. Doesn't confirm it exactly (no documented behavior of WoW64) but it mentions that 32 bit Windows only supports 32 processors.
EDIT: See this other stack overflow post as well: Detecting the number of processors
I upgraded to the latest Dart Editor (28355) both on Win7-32 and Win8-64 today. On Win7 it appears to run extremely slowly, on Win8 it is fine. Running both the Dart-Editor and the browser concurrently on Win7 I found unworkable. With just the dart-Editor running, it was still very slow to respond to input, but much better (4 v 25 seconds). I did reboot a couple of times in desperation. The Win7 machine is an older dual-core pentium with 4gb Ram running at about 2ghz (I'm on Win8 now). Previously I've had no major problems with the Dart-Editor on Win7 over a period of 6-months or more.
Is this a known problem with 28355?
Do you have a lot of folders in the 'Files' tab?
I find reducing the number of folders or right-clicking and selecting 'Don't Analyse' on some folders helps performance.
I have not experienced anything as dramatically slow as you have reported though.
I've found that 28355 uses much more RAM than before (about 1GB total now, for me). If you have a browser running and a couple of other programs, 4GB will be used up pretty fast and cause slowdowns. I'm not sure about the difference with Windows 8, perhaps it has better memory efficiency.
I am developing Delphi application on Delphi 2010 XE RAD Studio under Windows 7. My application talks on the serial port non-stop. I am using AsyncPro for Delphi 2010. Serial communication and everything else on the computer I develop with works great without any problem. However, when my release version of my application is run on another Windows 7 system, serial communication completely fails. We probed the serial communication itself for an answer and found out that Request to Send (RTS) line is not dropped right after sending all the bytes, whereas on my development computer RTS line is dropped correctly.
Even when I explicitly drop the RTS line to low or false state, RTS line doesn't drop right away but after good 15 milliseconds. Thus, serial communication on my release version is failing.
Am I missing important information about Windows 7 and serial communication issues?
UPDATE: I just found the bug with my Aysncpro 5.0 for Delphi XE. It is weird. When my Delphi XE IDE is open or running, my program is communicating flawlessly. When I shutdown or close my Delphi XE IDE while my program is running, the same program doesn't communicate very well or it times out.
Chime in if you have any idea why it is happening.
Any help will be appreciated.
Thank you,
Sounds like a timer resolution problem to me. I had the same problem trying to write to a USB FTDI driver using an event based timer with timeSetEvent()... When Delphi loads, it changes the timer resolution to less than 20ms, which made my app work fine. When the IDE wasn't running I couldn't get things to work below 20ms +/- 5ms (the default Windows resolution I believe).
To fix the problem, I call timeBeginPeriod(1) in the thread to set the minimum system wide timer resolution.
I believe this affects the resolution of other time based events, because I get better than +/-5ms accuracy on other (non-multimedia timer) wait events in my app when I use timeBeginPeriod().
So, what I'm suggesting is that somewhere in the AsyncPro code it's using some time based event or call back... That would be affected by Delphi's change to the timer resolution when it is loaded. Try calling timeBeginPeriod(1) somewhere in your app when it starts and see if there is a change.
Oh, and don't forget to call timeEndPeriod(1) when your app shuts down.
N#
Last few times I saw random inexplicable crap like I tried everything, and was unable to solve it for months.
I found two different common causes:
ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to TComPort.
I found all kinds of strange flow control bugs in USB drivers. I found FTDI chipset USB-to-serial more reliable than others.
The Debug build not having the problem could be two things:
Certain timing changes cause the USB device driver that was failing, not to fail.
You actually have some kind of a thread problem, like a race condition, leading to your ASync Pro components messing up in a way that looks like something's happening to your port, but really it's ASYNC pro.
The easiest thing to do is to try it with a different USB to serial adapter, and if that doesn't solve your problem, I would be tempted to pull out AsyncPro which I have also had many random problems with, and either write your own serial port class, or use TComPort. I have some long experience using a TThread that uses a com port "reader/writer" class and have found this the most reliable way to go, because you can tweak low level elements of the Win32 overlapped-IO calls, directly to meet your needs, and also be sure that you don't have some extra complexity/overhead getting in your way. (AsyncPro's complexity and overhead, are a significant potential source of bugs.)
This has to be a driver problem on the other machine, surely? Hardware flow control works fine on my W7 test box as well, (and Vista development machine). If your Apro has set the DCB correctly, and it sounds like it does because of your 'manual' tests, the driver should work...
15ms for a 'manual' RTS change from user mode is sad, but not at all unusual on Windows - that's why the driver should do it.
Rgds,
Martin
Can a 64bit Citrix server running a 32bit app through WoW64 handle just as many instances/users as the 32bit Citrix server equivalent?
And if so if I up the memory in the 64bit server will the number of instances/users scale too?
Or are there some strange memory considerations with a 64bit server running a 32bit app?
Just as an example - We're currently piloting running a 32-bit app on 64-bit.
Increasing memory on the server to around 12G (from 4), allows us to run around 130 instances of the app comfortably. On 32-bit, it's more like forty instances.
Of course, Your mileage may vary.
There may be other concerns to interest you though, especially printer drivers, depending on what solution you use there.
The constraints for a 32 bit Citrix (or Terminal) server are usually in the kernel resources: paged pool, non paged pool, session view space and system page table. On 64 bit OS this is no longer a limit so yes you could run more instances/users. At some point other resources like cpu and disk i/o will become a bottleneck of course.