OSX Mavericks and Performance

It seems to be getting a bit ridiculous that Logos 5 is lagging so far behind what the hardware environment enables these days in the Mac World.
Given that Logos can only support 32 bit memory map, 4 threads etc when the hardware can support 24 processor threads, 128 gig RAM you would think things would move along
Comments
-
There has been a discussion about the 'limitations" of the software and the reasons for 32-bit vs 64-bit (http://community.logos.com/forums/t/75492.aspx, etc) The "4 threads" is imposed by indexing up to four resources at a time; otherwise Logos allocates as many threads as it needs (without limit). 128 GB RAM makes sense for 64-bit software, but 32 bit software would only benefit from 16 - 32 GB for multi-tasking, whilst each program is locked into a 2 GB / 4 GB space!
Dave
===Windows 11 & Android 13
0 -
http://community.logos.com/forums/t/75492.aspx is not a working link.
0 -
Phil Mills said:
http://community.logos.com/forums/t/75492.aspx is not a working link.
Dave may have meant http://community.logos.com/forums/t/74295.aspx - but we would need him to confirm.
0 -
The fact remains- Logos is one of the most poorly written programs one can buy and load unto a Mac.
I really don't care to her all the excuses any more- what I want is a library system that works in accordance with it's cost.
Logos is not cheap, yet , there is no software I can find, of any kind, that runs as poorly on a Mac- as Logos.They should actually be quite ashamed of themselves in my opinion.
I used to race cars- If I could not field a competitive car- it stayed on the trailer or at the shop. If something broke, We fixed it, if it needed improvements, they were made, but never, ever, would I put a noncompetitive car on the track and then make excuses.
I don't allow a bunch of excuses at Church either - one does their work or they don't .
Being responsible, owning up and taking care should be things Christians do at a higher level than others.Logos has made in plain- there is "NO PLAN" to make Logos Mac any better than its current state.
I find this extremely sad.
0 -
Fr. Charles R. Matheny said:
The fact remains- Logos is one of the most poorly written programs one can buy and load unto a Mac.
If you are this unhappy with Logos, you really should move to Accordance. Frankly, I find L5 Mac's performance quite acceptable.
0 -
Fr. Charles R. Matheny said:
Logos has made in plain- there is "NO PLAN" to make Logos Mac any better than its current state.
I'm pretty pleased with the current state of Logos 5 on my Macbook!
__________
15" rMBP 2.6 GHz i7 | 16 GB RAM | 1.0 TB Flash Drive | OS X 10.12.3 | Logos 7.0 (7.3.0.0062)
0 -
Found several tips to improve OS X Mavericks performance => http://blogs.computerworld.com/mac-os-x/23025/how-improve-mac-performance-os-x-mavericks-edition and => http://www.macworld.co.uk/news/mac/mac-too-slow-tips-speed-apple-mac-computer-3490637/
Apple Support has => OS X Mavericks: If graphics-intensive tasks slow down your Mac
Fr. Charles R. Matheny said:I used to race cars- If I could not field a competitive car- it stayed on the trailer or at the shop. If something broke, We fixed it, if it needed improvements, they were made, but never, ever, would I put a noncompetitive car on the track and then make excuses.
To be competitive, appropriate hard ware is needed.
Logos is a resource intensive application whose performance is affected by hard ware choices. For example, a Windows tablet with an Atom Z670 CPU always responds slowly; am using performance tweaks of always running Logos offline (have not connected Tablet to a network) and not running anti-virus software. Noticed Z670 CPU is # 729 on a benchmark list => http://www.notebookcheck.net/Mobile-Processors-Benchmarklist.2436.0.html Thankful for slow tablet that can show Logos 5 visual filter highlighting, which cannot be done on an iPad.
Keep Smiling [:)}
0 -
Graham Criddle said:
Dave may have meant http://community.logos.com/forums/t/74295.aspx
I meant http://community.logos.com/forums/t/75492.aspx. [:)]
Dave
===Windows 11 & Android 13
0 -
Missed the point Jac: If you bought a brand new, top of the Line Mac Pro: Logos would be the most poorly written program running on it.
Keep smiling: Hardware does not change software code.
Jac: I have accordance and, have to use it most days for original language work.
Yet, I should be able to use Logos with the same level of reliability. These are not "toys" for me. I have thousands invested. It's not my hardware, as Logo's tech support tells me.Usual response is: Yes, this is a known issue, we have an open case on it, but will add yours. They are very nice about it- they just can't fix it or, when fixed to at least run, cannot get it to stay that way. I am, like some, scared to death to get a program or resource update, once I get Logos working functionally.
I will also give Logos tech support praise for their honesty- they understand the frustration and, don't try to sugar coat it- they know these problems are there.
Thus, your comment is not helpful at all.
There are many, like myself, who just want the program to operate as advertised and do so with stability, for us, it is a tool, workmen need to have dependable reliable tools.Its as simple as that, its no more than that.
Not expecting perfection, just a much higher norm .
0 -
Jack Caviness said:
If you are this unhappy with Logos, you really should move to Accordance. Frankly, I find L5 Mac's performance quite acceptable.
I will agree that Logos MAC is not as stable or fast as Accordance but I use both programs and do not find Logos unusable. I would agree with Jack, if you are unhappy consider using only Accordance. I do know Logos is improving all the time but i am not sure it is going to get to a point you are happy with.
-Dan
0 -
Fr. Charles R. Matheny said:
Not expecting perfection, just a much higher norm .
Sorry you are feeling this way. I hope you have better luck with other tools. God help you in your search for the proper tools for you..
-Dan
0 -
Fr. Charles R. Matheny said:
Missed the point Jac:
I did not miss your point—not in the dozens of times you have expressed it.
Fr. Charles R. Matheny said:If you bought a brand new, top of the Line Mac Pro: Logos would be the most poorly written program running on it.
I may have a top of the line iMac now, but my previous machines were an eight year old Mac Pro and a 4 year old Mac Book Pro. I got good performance from L5 on both. You talk as if every Mac user is unsatisfied with the performance of L5 Mac, and that is simply not true. I understand that there are some with problems, and I sympathize, but those few do not warrant the blanket condemnations of the software that you continually post.
Now, I have said enough on this subject—Many would probably say more than enough.
0 -
Uh, gee. The original point of this thread was to highlight the fact that the software is way behind the curve when it comes to utilizing current hardware capabilities in the Mac Pro line. That's all.
0 -
Om not speaking to your install Jac, so glad your happy.
Im not, and it's ok for me so say so, I paid about 3 grand , I guess so I could say so. According to Logos support, these problems are widespread , their own words, so, you are wrong. They are aware, they know, they have tickets on them.
Lord have mercy.0 -
Agree Mr Simple: Its behind. My understanding is it's in the Mono and .net ( if I got that correct, that Logos has a bottleneck and, is where most of the intermittent issues seems to arise.
Performance and issues seems to "float" and some of this is due to differing resources with different tagging etc, from what Logos tells me.
I think the UI is written for Osx, but thats it.
I am told the software interface between the windows platform and Mac ( Mono .NET) will not be changing. I do not know how that effects cores/threads. I do not know when they we get more memory address than 32 bit.
Hope that helps.
0 -
Makes sense - It seems unfortunate that the foundational fundamental infrastructure/architecture for the product has these issues. It may be the case there is no way out of the box canyon for logos on the mac side of the house. It probably would cost more $$ to fundamentally fix than the revenue stream it might protect and/or generate down the road on the mac side of the house. Otherwise they would fix it. I am not going to delude myself, that will not likely happen. Two years forward my sense is this will still be an issue on these forums. Could be wrong, hope I am, but I am a sceptic.
When I first bought the software I thought I can live with the growing pains because surely it will get addressed and improve over time. Sadly in terms of quality/stability that has not been the case and I am truly surprised by that outcome.
0 -
Fr. Charles R. Matheny said:
My understanding is it's in the Mono and .net ( if I got that correct, that Logos has a bottleneck and, is where most of the intermittent issues seems to arise.
Yes. The Mono code emulates .NET so that Logos can ostensibly use the same code for both Windows and Mac, but any emulation software will have its weak points and bugs (as does .NET).
Fr. Charles R. Matheny said:I am told the software interface between the windows platform and Mac ( Mono .NET) will not be changing. I do not know how that effects cores/threads. I do not know when they we get more memory address than 32 bit.
Previous responses from Logos (quoted in this thread) have stated that cores/threads are handled the same. So if the code changes thread behaviour it will be reflected in both Windows and Mac e.g. the OP's assertion about 4 threads is misleading as I indicated; so if Logos decide to index up to 6 resources at a time you will see (in Logos.log) six threads allocated for those resources. To effectively use more memory (e.g. 128 GB) the software would have to be 64-bit, but a 32-bit version would also have to be available for users on 32-bit hardware (many Windows 8 tablets) or who have only 4 - 6 GB memory!
Dave
===Windows 11 & Android 13
0 -
Conditional coding and testing for 32/64 universal binaries is not cutting edge. Nothing is misleading regarding 4 threads. It is what it is for whatever reason.
The bottleneck is there because of human decisions. I have often led software development teams where some "genius" tells me why they can't do something. I generally just found someone who "can do" and replace the "can't do".
0 -
Mr. Simple said:
Nothing is misleading regarding 4 threads
It is when Logos can support more than 4 threads! You need to clarify your assertion.
Dave
===Windows 11 & Android 13
0 -
Someone at Logos Technical support stated to me that they could not use more than 4 threads due to the development environment. If that is not the case then my assertion would be that certain functions could benefit from additional multi threading.
Regarding RAM. I believe that if the product was able to more aggressively use available RAM that certain functions within the program could benefit from that.Having said all that - I find that real I/O is a significant bottleneck. I have two SSD's installed and will be installing the latest SanForce SSD when it comes out shortly. It will have a 1.8 Gigabyte I/O bandwidth on a PCI-E 2.0 4 lane slot and who knows how many IOP's. I am currently at 1 Gigabyte/sec and 150,000 IOPS. At that point for my hardware setup RAM bottlenecks become much less significant for this application. None the less I have 48 gig of RAM. It would be nice to see it used.
Am I off base here?
0 -
Mr. Simple said:
When I first bought the software I thought I can live with the growing pains because surely it will get addressed and improve over time. Sadly in terms of quality/stability that has not been the case and I am truly surprised by that outcome.
Please elaborate on quality/stability issues. With substantial feature parity, many Logos 5 issues happen on Windows and OS X.
Logos 5.2a Beta has a race condition fix for Mac => http://community.logos.com/forums/p/78218/547017.aspx#547017 that is being considered for 4.6 and 5.2 stable release => http://community.logos.com/forums/p/78218/559676.aspx#559676
Thread => Logos 64 bit includes reply by Bob Pritchett => http://community.logos.com/forums/p/39363/294500.aspx#294500
Bob Pritchett said:The other issue is that some code needs to be re-written for 64-bit compatibility, and we use quite a few bits of code written and maintained by others. Some of this code isn't yet ported to 64-bit, and it's a better use of our resources to wait for that to happen -- which it will -- than to do the port for every module ourselves. (And it'll be easier for the company/person who wrote it, than for people who don't know it.)
Observation: Windows is technically challenging since a 64 bit application cannot run on 32 bit Windows; hence would need 32 bit and 64 bit Windows application configurations until Logos user community migrates to 64 bit Windows or Mac OS X.
Fr. Charles R. Matheny said:Keep smiling: Hardware does not change software code.
Software can query hardware capability and modify execution. Logos indexing of resource(s) queries number of logical processors followed by spawning thread(s). If a computer has one CPU, then one indexing thread is spawned. If hardware has four CPU's, then four indexing threads are spawned.
Keep Smiling [:)]
0 -
I have 8 it spawns 4 on my hardware. Regarding your observation on 64 bit. Software suppliers do this all the time.
0 -
MR Simple: Agreed on outcomes vs hopes- smile.
Understand decisions are made on marketshare cost/profit analysis .
Sadly.;Logos is the only 32 bit program I have for Mac or Windows.
Don't understand why recommendations are made for large amounts of ram- Logos cannot see it. Unless one is rendering video while using Logos, 12 gig isn't doing much.
0 -
Mr. Simple said:
Someone at Logos Technical support stated to me that they could not use more than 4 threads due to the development environment. If that is not the case then my assertion would be that certain functions could benefit from additional multi threading.
Re-read my responses on this. Logos does use more than 4 threads! If you want to observe this then enable logging and look at your Logos.log and LogosIndexer.log. The thread number appears after the timestamp.
Mr. Simple said:Having said all that - I find that real I/O is a significant bottleneck. I have two SSD's installed and will be installing the latest SanForce SSD when it comes out shortly. It will have a 1.8 Gigabyte I/O bandwidth on a PCI-E 2.0 4 lane slot and who knows how many IOP's. I am currently at 1 Gigabyte/sec and 150,000 IOPS. At that point for my hardware setup RAM bottlenecks become much less significant for this application. None the less I have 48 gig of RAM. It would be nice to see it used.
What application requires those resources? You don't get top level hardware and then say your applications should be able to utilise it...that's the sort of bandwidth you need for a server.
Mr. Simple said:Am I off base here?
My concern is that the Mac version of Logos is not sufficiently robust/reliable due to the emulation (Mono) of Windows .NET API. Mavericks may play a part but the performance issues existed before Mavericks. So I'd rather not be debating the merits of utilising 48 GB of RAM, or 150 000 IOPS when Logos doesn't play nicely in a typical (Mac) user computing environment. Let's urge the developers to attend to the real issues!
Dave
===Windows 11 & Android 13
0 -
Ok - Advice taken - Thanks -
Not sure about the threads issue - All I can tell you is when indexing fires up on my machine it uses 4 of the 8 processor threads available. I take what you say at face value, but for whatever reason that is not what occurs on my hardware.
To answer you question on what application requires this - My astrometrics programs which process very large data sets that can be collected over 8 hour intervals or even multi-evening projects spread out over weeks. The solutions can utilize all the hardware I can throw at it and hours to compute. I could still use more, but have not set up clusters yet
0 -
Gee, Mr Simple, we don't want you to leave! Discussions between you, Dave and KSFJ are educational.
As regards our good friend from Maryland (if I remember right), he should know that software that doesn't work right should simply be discarded, albeit $3,000 worth. Complaining and expecting improvements is unnerving to the Logosian community. It's very much like being on a bus next to an open window on a freezing day. Asking to close the window is upsetting to the other riders. The correct answer: get off the bus (at least in Logosian logic).
"If myth is ideology in narrative form, then scholarship is myth with footnotes." B. Lincolm 1999.
0 -
Logosian Logic, Ha ! - [H]
When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory. — William Gates, chairman of Microsoft
“There is no reason anyone would want a computer in their home”
- Ken Olson, 1977
One of the all-time classic tech prediction flubs, this quote came from the lips of president, chairman and founder of Digital Equipment Corp., Ken Olson, way back in 1977.
0 -
Gee, thanks Denise: I will remember this when others have issues- just get rid of logos- thats the answer.
Off the bus.
0 -
Mr. Simple said:
Not sure about the threads issue - All I can tell you is when indexing fires up on my machine it uses 4 of the 8 processor threads available. I take what you say at face value, but for whatever reason that is not what occurs on my hardware.
I'm talking about logical threads allocated by the software. So I'm not sure why they would not utilise the available processor threads when the OS ostensibly allocates logical threads to processor threads.
Dave
===Windows 11 & Android 13
0 -
-
Mr. Simple said:
Not sure about the threads issue - All I can tell you is when indexing fires up on my machine it uses 4 of the 8 processor threads available.
This is by design, based on our current performance profiling and the indexer workload. Using 6 threads currently takes the same amount of wall time to finish indexing as 4, because threads end up being bottlenecked on a shared resource. Future releases of Logos may improve the design of the shared resource and enable more threads. (OTOH, at the end of the day you only have one disk--and most users' aren't as fast as yours--so there's a fundamental limit on how fast an index can be built, regardless of how many CPU cores are available.)
The app has no limit on the number of threads it can use concurrently.
0 -
Mr. Simple said:
Here are the screen shots while indexing -
But what does that prove? We know, and can easily see, that Logos heavily uses four processor threads during indexing.
EDIT: just saw Bradley's rationale, but note his last statement.
Dave
===Windows 11 & Android 13
0 -
Bradley - That is a clear explanation and makes sense to me. I did suspect that my PCI-E attached SSD could do more work, but as you stated most users probably have a SATA attached or slower disk interface. The next version am getting will be over twice as fast and lower latency. It really shines in some of the workload that I toss it's way in high end astro work I do. I can get all 8 processor threads working over 90% and the I/O rates at a sustained 700 MB/sec. RAM usage close to 32 gig in the process as well. As you state that is not typical. Just as a note that was an application running with OS/X using Parallels and Windows 7. Kudo's to the emulator as well.
If the data was more aggressively cached in RAM would that reduce the I/O bottleneck in this function you describe? I've configured filesystems for parallel supercomputers that cached massive amounts in available RAM so I've got a particular filter in my head when asking these questions.
Thanks again for the response. It tied together some loose ends for me.0 -
Mr. Simple said:
If the data was more aggressively cached in RAM would that reduce the I/O bottleneck in this function you describe?
Yes, definitely.
The Logos search engine and indexer were originally designed in an era where a high-end customer system might have 2GB of RAM. We designed under the constraints that we would not have the freedom to put very much data in RAM without causing a massive amount of paging (which would degrade the performance of the whole OS, not just Logos itself).
Obviously time has moved on (computers routinely come with 8+ GB of RAM) but the implementation hasn't always kept up.
A 64-bit transition should give us more ability to eliminate many of these bottlenecks (primarily due to the greatly increased virtual address space) and I hope we can make many improvements in these areas to take advantage of powerful hardware now on the market.
0 -
Again, thanks for the response. Much appreciated -
0 -
Bradley - Any updates on the indexing algorithms? I am about to buy an SSD that has about 3/Gigabyte throughput and 750,000 Read IOPS transaction rate.
0 -
Are you running L6 (you should be). If so, and if you don't get a response, try creating a new thread in the L6 forum.
macOS, iOS & iPadOS |Logs| Install
Choose Truth Over Tribe | Become a Joyful Outsider!0 -
I am running L6 and will create a new thread.
0