OS X Lion, Open CL and Logos 4

This is a question to tech support. Is Logos 4 going to take advantage of Open CL in OS/X Lion.

My understanding is that if an application does and your graphics card supports Open CL you can expect significant graphics performance benefits in the application.

I am setting up for 3 monitors and am deciding on a second graphics card. The selection I make will in part be determined by the response I get to this query.

Find more posts tagged with

Comments

David Mitchell

OpenCL is a technology for doing parallelizable, computationally intensive tasks (not necessarily related to graphics). While it is possible to run OpenCL computations on a video card, it doesn't make sense for all computations. However, our use (or non-use) of the feature will not have a significant effect on graphics performance.

I don't have any comment right now about what technologies we may be planning to adopt in future versions of Logos Bible Software.

Mr. Simple

OpenCL is a technology for doing parallelizable, computationally intensive tasks (not necessarily related to graphics). While it is possible to run OpenCL computations on a video card, it doesn't make sense for all computations. However, our use (or non-use) of the feature will not have a significant effect on graphics performance.

I don't have any comment right now about what technologies we may be planning to adopt in future versions of Logos Bible Software.

Thanks David -

Daniel Bergquist

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}

I would like to expand on David's comment. (WARNING! fairly technical content ahead!)

OpenCL (first introduced in 10.6 Snow Leopard) is geared towards highly parallelizable and computationally intensive mathematical tasks. This makes it great for many scientific, graphic and video/audio processing tasks. Weather and other physics applications are well suited, as are video compression, image manipulation and anything making heavy use of linear algebra.

It is not well suited to text oriented systems such as Logos. OS X already does a lot of UI graphics processing on the graphics card through the standard UI methods.

Based on what is publicly known about Lion, there's not a lot of new performance oriented tech in it. Snow Leopard was chock full of new tech for performance such as OpenCL and Grand Central Dispatch.

Grand Central Dispatch makes it a lot easier for programmers to utilize the extra cores in your CPU. This is a technology that Logos could use to make some speed improvements for things that can be parallelized at a higher level (in computing, low level means you have to pay attention to detail, high level means you talk about larger concepts. Eg compare letters 'a' and 'b' is a low level task while search documents x,y,z for 'foo' is high level task which would entail the low level task of comparing letters) or things that can be done in the background.

There is a new technology in Lion called ARC that could give an overall speed improvement as well as reduce memory usage and some types of crashes. http://blogs.remobjects.com/blogs/mh/2011/06/20/p2571 has details on what that is.

Mr. Simple

I believe that some of the development frameworks that the Logos Application team uses precludes them from basic things like using over 4 gig of RAM and more than 4 Cores even if they structured the code for greater course grain parallelism.

From the end user perspective the UI is slow relative the the computing and GPU resources available on the machine I operate from. I suspect that part of that is due to the cross platform API's that have been chosen to support both Windows and OS/X. Probably out of the sphere of influence and control of the Logos Team.

Daniel Bergquist

Unless I am mistaken, the UI is native to OS X and the under the hood stuff uses the cross-platform Mono framework.

An app's UI code can be easily made sluggish either through drawing complex custom UI elements (or even simple ones) too often, creating and destroying too many objects while working with the UI, refreshing content too often or through tying up the main thread with non UI code. There's probably other ways too, but these are the main causes.

I am not familiar with Mono's limitations or even if there is a 64bit OS X version of the framework. If the limitations you mention are present, there's ways around those too.

Daniel Bergquist

I should add, it's easy to armchair engineer, without the pressures of actually running a software projects. ;-)

Patrick S.

Unless I am mistaken, the UI is native to OS X and the under the hood stuff uses the cross-platform Mono framework.

An app's UI code can be easily made sluggish either through drawing complex custom UI elements (or even simple ones) too often, creating and destroying too many objects while working with the UI, refreshing content too often or through tying up the main thread with non UI code. There's probably other ways too, but these are the main causes.

I am not familiar with Mono's limitations or even if there is a 64bit OS X version of the framework. If the limitations you mention are present, there's ways around those too.

L4M is, I think it is fairly broadly accepted, held back/hamstrung by Mono. If one looks at an app like L4M (& L4W) there would be a lot of heavy lifting going on with computation over what to display (indexed searches, cross reference of book titles/words, text analysis) before it gets to the how to display (the UI). I believe the 'what' depends on Mono which is overdue for revision, and is itself still based on a couple of versions old .NET. Strongly doubt is 64 bit. Unfortunately don't believe the extra horsepower capabilities in OS X (Grand Central) etc. can be used in L4M back-end as the 'engine' is the closed box Mono/.NET running DLLs - no doubt impervious to improvement.

The L4M UI uses some non-standard UI components (?and programming methods?) to make it look and act close to the Windows version. On the UI side there is no reason that once content (data) is available that the screen can't be drawn very quickly. Obviously many other 'big' OS X apps can do it.

I'm sure the L4M team are doing all they can to improve things, you sure you don't want to move to Bellingham [;)]