• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

related to fork join and its performance

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  •  
    Marshal
    Posts: 28193
    95
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic