Page 2 of 2

Re: Finale or Sibelius

Posted: 01 Apr 2018, 11:11
by OCTO
Right Laurence, so it is. I'v just started with Sib on a smaller-size project (chamber opera), where no particular extended technique is used. It works good so far. It works more quick for what I do now.
Yet I am missing some features of "total control" what is found within Finale.

Re: Finale or Sibelius

Posted: 16 Apr 2018, 13:48
by benwiggy
jan wrote: 11 Jan 2018, 12:01And there is one thing one may not forget: Finale is single-threaded.
Are you sure? Finale on the Mac typically runs between 10 and 20 threads. It has done so for several versions.

It would be interesting to run your tests on Finale 25.5, across the board. Also I'd like to run it on some Macs, to get a reference for that platform. That would be helpful to see if Macs were generally slower than Windows in Finale.

Of course, it's not really surprising that faster computers are faster. :)

Re: Finale or Sibelius

Posted: 17 Apr 2018, 06:21
by jan
The Finale core is single-threaded, i.e. where the note/layout processing is done. I don't know if Finale/MacOS opens up threads for other reasons (for example Window handling). But have you noticed that Finale really handles multiple things at the same time? On Windows it doesn't. This is different in a program made for multiple-CPUs like the video editing software Adobe Premiere where many processes are running in the background (e.g. converting audio/video files to the correct format).

If you look at this video where two slow Finale plugins are processed, you'll see that the CPU usage never exceeds 10% - so it definitely does not make use of multiple CPU cores:
https://www.youtube.com/watch?v=oLOdDW4pzMg
I suggested some things for parallelizing tasks in Finale plugins on the JW Lua mailing list back in 2014 and in a feature request to MM.

Re: Finale or Sibelius

Posted: 10 Jun 2018, 22:48
by ttw
Having 64-bit words usually gives some increase in bandwidth for the same clock speeds. Of course, I worked for Cray for some years so some of the byte or bit- addressable stuff may not speed up. The bus widths are usually twice as wide. This means that scalar accesses for instructions are faster. I have seen some architectures which tried to be byte-addressable and so got little improvement from wider busses.

I don't know how FInale or Dorico or Sibelius (or even Igor) is programmed. If they pack 8 bytes per word they can get come advantage over an architecture that only packs 4 bytes per word. If 32- bit and 64-bit machines are programmed with a single byte per word, only the clock speed matters. (Seems a poor way to do things, but I've seen lots of that type of programming over the last 50 or so years.)

There's nearly always an advantage in disk transfers with the wider word size. The disk architects are pretty good.