Jump to content

Multi-Processing Software


Thom

Recommended Posts

Is there a third party software that will configure a quad-core processor to function as one large processor or to spread out processing out over more than one core when the one core is running at 100%. I find that I am running one core at 100% much of the time without the files being too large. A couple of thousand plants will cause my machine to creep along and be very unworkable.

Link to comment

I doubt it. Writing multi threaded code that is needed to run over multiples processors or cores is a non trivial exercise for all but the simplist code.

I can't see that we are at the stage yet where a software app working blind on an application can do better what a human can do with the source code in front of them. The closest we have got to that is pipe lining within the processor which is far simpler than having to deal with mutual exclusion, race conditions and predicting concurrent data and resource contention.

However, I last worked on large multi threaded and distributed apps 4 years ago, and technology is a fast mover, so could be wrong.

That said, it would be nice if NNA could run the UI and app in separate threads to make the UI more responsive when performing time intensive processes - like some rendering modes or placing large numbers of plants.

Link to comment

Grand Central, coming middle of next year:

http://www.apple.com/macosx/snowleopard/

?Grand Central,? a new set of technologies built into Snow Leopard, brings unrivaled support for multicore systems to Mac OS X. More cores, not faster clock speeds, drive performance increases in today?s processors. Grand Central takes full advantage by making all of Mac OS X multicore aware and optimizing it for allocating tasks across multiple cores and processors. Grand Central also makes it much easier for developers to create programs that squeeze every last drop of power from multicore systems.
Link to comment
Grand Central, coming middle of next year:

http://www.apple.com/macosx/snowleopard/

?Grand Central,? a new set of technologies built into Snow Leopard, brings unrivaled support for multicore systems to Mac OS X. More cores, not faster clock speeds, drive performance increases in today?s processors. Grand Central takes full advantage by making all of Mac OS X multicore aware and optimizing it for allocating tasks across multiple cores and processors. Grand Central also makes it much easier for developers to create programs that squeeze every last drop of power from multicore systems.

Good bit of marketing blurb to make people think they are getting something new.

My take on this is that Grand Central is simply going to become more multi threaded. It does very little to enable an app to run across multiple cores. Multi threading has been around for ages - Posix for example, is a standard that has offered multi threading since mid 90's, and some "proper OS's" offered multi threading of sorts much before that. OS-X is Posix compliant, so the only thing that I see that has changed is that the new OS version is more multi threaded - sorry, multicore aware - same thing, different marketing speak. This offers very little benefit to the end application unless the app needs to call a OS routine that was previously not 'thread safe' and thus not able to be used within a multi threaded portion of the application.

What I don't see it easing is making a single application more multi threaded. Yes, it talks about making it easier for developers to make multi threaded apps, but that's not the tricky part. The tricky part is making algorithms and data structures able to be multi threaded - and that's the bit that is non trivial.

Link to comment
Ian

It seems like you often have projects with many thousand plant symbols. Once I get over a couple thousand, my machine drags. How do you deal with this. I am starting to break large planting plans into several mini projects just to be able to work.

I'm not a plant tool fan, only using it for indicative spot planting in 3D views or mass planting areas. For planting plans, where placement and labelling is important, I developed my workflow using my own symbols and custom Vectorscript as the VW plant tool does not meet my needs.

My projects are much smaller, but even with several hundred massed plants, I have time to make a cup of tea. I generally reverted to the revision or planting line tools and now with 2009, will probably use the landscape area tool as this offers the graphic styles of the revision and planting line tools, under one tool.

Link to comment

Yes. If possible, use layers as Ozzie suggests to separate planting areas.

I use layers when I am adding textures to a plan. For planting I use three. One for specimen plants that I may want to show in other views - possibly 3D view and another for complex plant massing - the one that kills the machine when you need to update an area. The final one is for canopies where the layer simply gives me a third dimension.

I do similar for stipples and gradients as these are also slow to redraw and I'm only interested in them on the final presentation plan.

Link to comment

Ozzie - Good idea, did not think of making each bed a different layer.

IanH - I have modified the classes of the symbols provided by VWL to be able to switch on and off complete graphics to the simplest graphic form. Even in the simplest form my machine is bogging down.

I have all my background bases setup through viewports, so the only thing that actually resides in the dwg are plant symbols.

Link to comment

Ian, the whole point of Grand Central, as far as Apple is concerned, is to provide multi-threading as a core part of the OS, that application programmers (including themselves) can hook into, instead of having to write multi-threading into each app from scratch. It?s a similar philosophy, I think, to their other ?core? technologies, such as Core Image, Core Data, Core Video, etc.

How you manage to conclude the opposite from their blurb I?m not sure. Do you know something about Grand Central that Apple doesn't?

Link to comment
Ian, the whole point of Grand Central, as far as Apple is concerned, is to provide multi-threading as a core part of the OS, that application programmers (including themselves) can hook into, instead of having to write multi-threading into each app from scratch. It?s a similar philosophy, I think, to their other ?core? technologies, such as Core Image, Core Data, Core Video, etc.

How you manage to conclude the opposite from their blurb I?m not sure. Do you know something about Grand Central that Apple doesn't?

Christiaan

My interpretation is based on the expectation that what you have just said had already been built into the OS along time ago. What you are saying makes me doubt that the Apple OS is particularly advanced in multi threading. But I do not think that this can be the case, since Apple OS is Posix compliant and as such multi threading via Posix has been around for the last decade or so.

Multi threading is both very simple and very complex. To code a multi threaded app is very easy, to write a multi threaded algorithm and code is can be extremely difficult or impossible. You cannot just take an application and make it multi threaded - it may not suit itself to that. Actually I should clarify this - "and make it concurrently multi threaded". You can take any app and make it multi threaded, but not necessarily run the threads concurrently.

I am happy to stand corrected, but my interpretation of what Apple have done is to make their whole/majority of their OS thread safe. What this means is that an application can call an OS routine without having to worry about whether that call interferes with, or interfered with a simultaneous call from another thread. They also hint at technologies to help newer apps.

Can I please quite from the apple developers website:

Guidelines for using Cocoa from multiple threads include the following:

* Immutable objects are generally thread-safe. Once you create them, you can safely pass these objects to and from threads. On the other hand, mutable objects are generally not thread-safe. To use mutable objects in a threaded application, the application must synchronize appropriately. For more information, see ?Mutable Versus Immutable.?

* The main thread of the application is responsible for handling events. Although the Application Kit continues to work if other threads are involved in the event path, operations can occur out of sequence.

* If you want to use a thread to draw to a view, bracket all drawing code between the lockFocusIfCanDraw and unlockFocus methods of NSView.

* To use POSIX threads with Cocoa, you must first put Cocoa into multithreaded mode. For more information, see ?Creating POSIX Threads in a Cocoa Application.?

And

Core Foundation

Core Foundation is sufficiently thread-safe that, if you program with care, you should not run into any problems related to competing threads. It is thread-safe in the common cases, such as when you query, retain, release, and pass around immutable objects. Even central shared objects that might be queried from more than one thread are reliably thread-safe.

Like Cocoa, Core Foundation is not thread-safe when it comes to mutations to objects or their contents. For example, modifying a mutable data or mutable array object is not thread-safe, as you might expect, but neither is modifying an object inside of an immutable array. One reason for this is performance, which is critical in these situations. Moreover, it is usually not possible to achieve absolute thread safety at this level. You cannot rule out, for example, indeterminate behavior resulting from retaining an object obtained from a collection. The collection itself might be freed before the call to retain the contained object is made.

In those cases where Core Foundation objects are to be accessed from multiple threads and mutated, your code should protect against simultaneous access by using locks at the access points. For instance, the code that enumerates the objects of a Core Foundation array should use the appropriate locking calls around the enumerating block to protect against someone else mutating the array.

You can see from this that OS-X is, like may other OS's, not totally thread safe and it is up to the application programmer to make their application and algorithm thread aware. I think that apple are just going to make this job easier for the developer - not that it was hard for the coder in the first place.

My interpretation from what you and the Apple website have said is that apple are making it easier for applications to become thread aware, which is quite different from running an existing application and having it run across multiple threads as the original post was asking.

Some applications are better suited for multi threading than others. Renderworks is multi threaded because rendering scales very well across threads, each scan line is often treated as a separate thread. As is separating an applications user interface from the computational guts of the code. But not all apps will scale so well. Back to the original post - would making each tree run under a different core be useful? Possibly, but only if they did not interact with each other and the overhead of running them across cores did not outweigh the benefits. Some languages are inherently suited to multi threaded applications - object orientation suits MT very well if correctly programmed. How much of VW is object orientated - I don't know, but considering its heritage I would bet money on it not being up there with the most OO of appliations.

The ZDNet article posted by Mr Gog does hint at some things that Apple may be looking into. But I don't think its going to transform an old app like Vectorworks like the OP was hoping.

I don't want to get into a Mac vs PC war (I first programmed a Mac/Lisa 20 years ago and the application model was beautifully thought out and a joy to work with compared to the MS rubbish), but both camps seem to be about 20 years behind in multi processing technology.

In early 90's, I was working on an application that was partly based on the Meiko Computing Surface, an array of 64 Inmos transputers. It was great at doing one job, each rendering their own part of a screen, but, despite its cost, it was left mostly/totally unused as it was simply unsuited to the other applications that we developed and used - despite how much we wanted to use it. It was not a fault of the hardware, nor a fault of the OS, but simply that the application algorithms did not suit multi tasking. No matter what clever technology someone develops, its not going to change for very many apps that simply remain unsuitable for multi threading/tasking/processing/distributed/cored or whatever other grand buzzword people want to use.

Link to comment

Well, looks like I'll have to take your word for it Ian. Your knowledge is far beyond mine.

But just to be clear, the gist I got from Thom's query was (and putting aside that he's on Windows): is there a non-NNA software package that will help Vectorworks in processor intensive scenarios to take advantage of multiple processors, ultimately speeding up his work?

Assuming for a moment that NNA rewrite VW in Cocoa and build in support for Grand Central in the process, you're saying this will make no difference to the scenario that Thom presents?

Link to comment

I obviously don't know the VW code, but:

1. NNA need to support 2 platforms - it is unlikely that the majority of the code base will differ much, thus IMHO a rewrite is unlikely although some of the OS specific middleware/application framework could be optimised for each OS.

2. There is more than NNA involved in this. Parasolid, possibly a third part application framework/middleware etc.

3. There will be bits of VW that may well benefit from multi processors/cores but there will be bits that will not.

4. With #1,2 in mind, I doubt that Grand Central will make them any more willing to support full multi core/processor than those features that are already available to them. Even just changing a compiler option (ie optimisation setting), let alone compiler or application framework requires significant testing.

5. There are easier ways to achieve better CPU utilisation than multi threading a single application.

6. Parts of the above will need to be addressed if/when moving to 64bit native so never say never.

Re Thom's scenario, I do not believe that an add on package will help existing apps achieve better CPU utilisation. Where existing apps may benefit in the future is from core parts of the OS becoming thread safe, so parts of the OS that currently have to run on a single thread, may in the future benefit from more concurrent execution. This will benefit the app in quicker response from OS calls. But to get most from multi cores/processors, the underlying app needs to be more aware of multi cores - and the benefit of this will be nothing (or even detrimental) for some apps and approaching 100% in other apps. Very much like 32 vs 64bit.

Link to comment

Thom,

I use Layers to separate things like a site model, referenced in files, sometimes the buildings and like Ian if the file is large and there are lots of them ? stipples as they are resource hogs

I have completed projects with upwards of 5000 plants ? say 50 residential houses ?

Large projects like that for clarity I separate into two views if you like ? Surfaces and Finishes and Planting Plans ? so a project of that size could have 12 A1 Sheet Layers of Planting Plans and the same for Surfaces and Finishes

As on each Planting Plan I require a Plant Legend Worksheet I use Classes to separate the plants allowing me to count them for each Sheet ? this means as I work in a project this big if I choose I can have only one twelfth of my Plants turned on

I also have another Class I am beginning to use for my Plants ? Plants-Component-Circle meaning for each Plant I can use a simple circle if I choose whilst working and when presenting through my Sheet Layers have my intricate and details plants showing

I have built quite complex Plant Symbols for my individual Plants and now have about 250 structured this way ? I can turn on my Blooms, Colour fill, all of that or just have a simple circle

Works well for me

I use the Plant Database ? ditched all of NNAs plants and only use my own and am disciplined as I work ? if I use a new Plant I put it in the database, create the symbol and then use the plant ? takes time but always then I have the Plant as a resource into the future

Link to comment

Want to share or sell you symbol package. I have been developing my own, but am just getting started as I do not spend too much time doing planting plans.

Do you see any advantage to using layer vs. classes to control what is on or off? I usually use layers for my primary control - landscape vs. irrigation vs. hard surfacing vs. models and use classes to turn plants on/off. That way it leaves more control for the AC user I end exporting to.

Link to comment

Thom,

here are pictures of some of my plants - I do not really want to sell or give them away - they are a work in progress

If you like though I have the original base file of 2D symbols I collected from the internet and other files that I used to get started - I can send that to you to get you going

It is about 9 mb - do not know if I can post it here

You just have to be diciplined - I started mine back in VW 11 - ditched them all when I went to 2008 and now have I think about 200 plus

Just yesterday whilst working on a domestic project I built about 15 new ones

As you go along they just become an asset

Tell me what version you want them in if you want them - be aware though some have lots of lines and un closed polys - so you have to be a bit careful

Link to comment
  • 3 weeks later...

If you like though I have the original base file of 2D symbols I collected from the internet and other files that I used to get started - I can send that to you to get you going

Ozzie, if you could provide me with the 2D symbols I would be so hugely appreciative. I have been using AutoCAD for the last 5 years and just realised the power of planting plans on this program.

I hope I'm not too late!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...