Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fastcodeml fastcodeml
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 12
    • Issues 12
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • phylo
  • fastcodemlfastcodeml
  • Issues
  • #30

Closed
Open
Created Feb 25, 2016 by Omid Shahmirzadi@oshahmirMaintainer

'number of threads VS performance' is not as expected

Increasing number of threads does not constantly improves performance. After a certain threshold, increasing number of threads seems to have adverse effects on performance. This observation is more obvious when fcml is compiled with lapack library. The reason is not clear.

For now adjusting number of threads to the optimum value (which is not the maximum number of cores) can have considerable performance gains.

A side issue regarding correctness: in case of compilation with lapack, #threads = #cores/2 (and not other values) can lead to completely wrong results.

Assignee
Assign to
Time tracking