Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

related to fork join and its performance  RSS feed

Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Everyone,
i have started exploring various features in java 7 and 8 for parallelism. i have started going through verious articles on net and try to check if it is really providing me performance benefit with fork join.

following code when i tested sequentially and with fork join it was to my surprise that i found fork join is not giving better performance. i guess i am missing something or doing something wrong.

when i ran this code i found following result
Seq Time For execution 8565153 max value 999
Parallel Time For execution 201782136 maxValueParallel 999

ideally my fork join must give me faster response but i am unable to see same.
author & internet detective
Posts: 38564
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two common reasons for parallelization not being faster that might apply here:
  • The data set is too small to be worth splitting up
  • Parallel CPUs aren't available
    Posts: 23706
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If I understand your parameters right: you used 10 million tasks in your test, and when run sequentially the elapsed time was about 8.5 million nanoseconds. In other words, each task took less than one nanosecond to run. And the parallel version took about 200 million nanoseconds.

    If that's right, then my feeling is that most of the extra time used in the parallel version was the cost of setting up and managing the thread pool. It might be interesting to reduce the time required for your tasks down to zero -- i.e. change the task so that it does nothing -- and see what numbers you get. And then modify the task so that it uses a non-trivial amount of elapsed time, see what you get then.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!