Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Who is the ISE developer/maintainer?
#1
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?
Reply
#2
(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.?
Reply
#3
(07-31-2024, 02:03 PM)DSMan195276 Wrote:
(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.?
I monitor using: gkrellm, xosview, htop.

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.
Reply
#4
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
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply




Users browsing this thread: 2 Guest(s)