+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Who is the ISE developer/maintainer? (/showthread.php?tid=2898)
Who is the ISE developer/maintainer? - desA - 07-31-2024
Hi everyone,
Who is the ISE developer/maintainer?
Reason for request:
Recent compilation of the Linux version of qp64pe forces all cpus to run - for a Xeon box, but not for an i7-7500U box. This occurs for identical versions of Linux Mint (both 21.3 and 22 versions).
This did not occur on the ISE release around a year ago - also Linux Mint OS.
Is there a specific statement in the IDE that forces/allow all cpus to be engaged?
RE: Who is the ISE developer/maintainer? - DSMan195276 - 07-31-2024
(07-31-2024, 02:23 AM)desA Wrote: Is there a specific statement in the IDE that forces/allow all cpus to be engaged?There's nothing in the IDE code that controls this, the IDE uses threads internally and the OS is the one that picks where they run and when. Technically you could configure this at the OS level so that qb64pe only get scheduled on a couple cores, but that's probably not worth it, that IDE shouldn't cause that level of CPU usage on multiple cores so I would assume something is going wrong. Am I right in understanding this is just during normal usage of typing into the IDE? Not during compilation?
I'm assuming you ran htop or a similar process monitor to verify this, did you see `qb64pe` threads running on all the cores? Or did you also see instances of g++, ld, etc.?
RE: Who is the ISE developer/maintainer? - desA - 08-01-2024
(07-31-2024, 02:03 PM)DSMan195276 Wrote:I monitor using: gkrellm, xosview, htop.(07-31-2024, 02:23 AM)desA Wrote: Is there a specific statement in the IDE that forces/allow all cpus to be engaged?There's nothing in the IDE code that controls this, the IDE uses threads internally and the OS is the one that picks where they run and when. Technically you could configure this at the OS level so that qb64pe only get scheduled on a couple cores, but that's probably not worth it, that IDE shouldn't cause that level of CPU usage on multiple cores so I would assume something is going wrong. Am I right in understanding this is just during normal usage of typing into the IDE? Not during compilation?
I'm assuming you ran htop or a similar process monitor to verify this, did you see `qb64pe` threads running on all the cores? Or did you also see instances of g++, ld, etc.?
This occurs immediately when opening the IDE. Load begins to climb substantially. Using 'nice' only helps a little with mouse response.
I have now enabled OS frequency control in the BIOS, and use various cpu-frequency control software to check. No change.
These Xeons have limited frequency control between 1.6 and 1.89 GHz, whereas the i7-7500U drops down as low as 400 MHz. This is obvious when running qb64pe on the i7 when it backs off.
I re-checked older qb64pe versions on Linux Mint and they respond the same way. I did not see this on previous Debian versions last year. Weird.
It's a pity as I really liked the IDE.
RE: Who is the ISE developer/maintainer? - grymmjack - 08-02-2024
I am not seeing this issue on Debian 12.
What I see is 7% CPU use from qb64pe. Opened with nothing it.
I compile it from scratch from latest github source.
Specs:
Code: (Select All)
grymmjack@funkunit:~
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
CPU family: 6
Model: 58
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 9
CPU(s) scaling MHz: 86%
CPU max MHz: 3400.0000
CPU min MHz: 1600.0000
BogoMIPS: 6784.59
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon peb
s bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_d
eadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln
pts md_clear flush_l1d
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 8 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Vulnerable: No microcode
Tsx async abort: Not affected