Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Chameleon Chameleon
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 19
    • Issues 19
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • solverstack
  • ChameleonChameleon
  • Issues
  • #16
Closed
Open
Issue created Feb 21, 2017 by THIBAULT Samuel@thibaultDeveloper

Default number of threads does not count cores

When running on a hyperthreaded system, chameleon's timing examples uses by default as many threads as logical CPUs, not cores, resulting in overloading which is detrimental to performance.

This is due to timing.c's get_thread_count() which just calls sysconf().

Is there a reason for not just letting the runtime automatically detect what it prefers? (and if a runtime can not detect itself, the corresponding runtime/ directory could use get_thread_count())

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking