I'm not an EE either, but - very politely, of course [:)] - I suspect that's a serious load of bollox. Sorry.

The reason you need RAM in pairs is because of the way the RAM works. DIMMs - *dual* inline memory modules - are there because of the 64-bit memory bus (2x32 bits), not with one set of memory being dedicated to one processor.

Here you go:

http://en.wikipedia.org/wiki/DIMM

Thanks for the link, Nick.... another piece of the puzzle.

The following is clear:

1. ...that I need to spend much more time researching how dual cpu's really interact with RAM and virtual memory-- and I need to do so before the technoogy becomes entirely antiquated-- could be a moot point in a matter of months. It was because of the misleading explanations I've gotten (from Apple, no less) that I've not put more than 4.5 GB of RAM in my system. Even on this forum, there have been discussions without resolution on the RAM limits of Logic and DP being less than 4 GB, and with OSX magically handling RAM management that there was no real need to add more RAM than your applications will allow.

I'm also wondering when/if the VSL team will continue its PPC Mac tests, knowing that their present stress tests were all done with less than 4GB of RAM installed (and knowing that part of their focus for the rest of the year will be dedicated to the IntelMacs). I'd be most interested in what performance benefits there may be when using VI on a Quad loaded with 16GB RAM... or if there is a point of diminishing returns.

2. ...that further study of how to accurately read the Activity Monitor is needed-- or even a more accurate Activity Monitor is needed. For someone who has no idea other than common visceral sense, there would be no reason to believe that more RAM would improve performance as long as the AM indicates that only half your current RAM is in use. Would be off the mark to now suspect that when AM says that 2GB is left unused that a more accurate reading would be that all or part of the "unused" RAM has actually been "reserved for use according to demands of the applications running"? Could the point at which virtual memory kicks in actually be the point at which OSX sums its used RAM plus its reserved RAM? (if there is a such thing as RAM in reserve)

Understanding how to read this will do much to tell the user what demands one's applications will place on a system, how quickly these demands reach their limit, and at what point more RAM needs to be installed-- until such time one realises that they're overloading their system and should probably get a new computer!

One of the things I appreciated about OS8-9 was that it would tell you when an application needed to have more RAM allocated. It was much easier to know in an instant when to make the adjustments in the Extensions Manager or when to add additional physical RAM.

3. ...that I need to thank the Brits for the word "bollox". Makes me laugh every time!

bollocks (also ballocks or bollix): vulgar slang chiefly Brit. noun
1 [in pl. ] the testicles.
2 used to express contempt, annoyance, or defiance.

Thought you'd like to know..... [[;)]]

Getting back on topic, there has been some discussion over at Logic-users about virtual memory and someone posted this interesting titbit:

@Another User said:

VM is only expensive if swapping *out* is actually
happening, and swapping out only happens if there are more *active*
processes than there is memory to hold them all. Further, the only
bits that swap in are the ones being accessed, so even if a process
is waking up periodically and looking for something to do (and there
isn't anything) only a small bit of the process memory will stay in RAM.

Beyond that, all code associated with a process is mapped into VM
when it is launched. This just means that the program as it sits in
the .app package on disk is considered to be swapped out; if code
actually needs to execute, it will be loaded in by the VM system.
This code does not take up swap space, and most of it never ends up
in RAM (since most of it is never executed.)

Beyond that, code never swaps out, since it is marked as read-only
(and a copy is known to be on disk already); only the data swaps
out. So the RAM taken up by the code of formerly active processes is
gained back essentially for free.

All of this is why the swap in count is always nonzero (it's how all
programs load). If the swap out count is nonzero, then swapping has
taken place at some point.

All of this aside, if you launch Logic and the system does need to
swap other stuff out to make enough room for it, you may have
performance problems at first as everything gets pushed out to disk,
but then things should mellow out.

Regards - Colin

http://dictionary.reference.com/search?q=bollox

You can also spell it the way I did. [:)]

So, 'bollox' or 'bollix' can be used as a noun or a verb! I've also heard it used as the adjective "bollicky" (sp?). "Chuffed" is another favorite-- different meaning, of course.

Back OT--

Thanks Colin for the quote-explanation. It confirms my second round of suspicions that once the potentially flagged data is identified, subsequent loads of this data tends to be faster. It also supports Nick's observation of the 2 x 32-bit RAM process, making the benefits of having more RAM less fuzzy-- which itself supports your recent experience of performance improvements.

So, while I continue to kick and scream about adding some sort VI farm, the most effective thing I can do in the meantime is to load up my current system with 8GB.

[quote=JWL]So, 'bollox' or 'bollix' can be used as a noun or a verb! I've also heard it used as the adjective "bollicky" (sp?). "Chuffed" is another favorite-- different meaning, of course.

Bollocks... as in the dog's is what us Limey's regard as "Oxford English" !

Regarding RAM I have often appeared to have more performance on my G5 when running 6.5GB than say 4GB. And when I was doing a large project across 4 G5's a couple of years ago we had to reduce 1 to 2GB for a while and performance definately suffered - it was only really running 1 app (Logic) with mainly a lot of audio files and tracks. So there is something beyond the single app limit that makes a difference.

Also I was able to get over 5GB of VI instruments by using a plug-in within Logic and a standalone - you can get even more if you re-name the stand alone app and open a second instance.

Julian

@julian said:

...Also I was able to get over 5GB of VI instruments by using a plug-in within Logic and a standalone - you can get even more if you re-name the stand alone app and open a second instance.

Julian

Renaming the standalone for a second instance? Interesting.

Hmm... alias or copy?

I'm amazed that this even works with app/file associations. Are there any potential problems with directories?

Copy app, re-name, and off you go

julian

As far as I know you can't run multiple instances of Logic 7. You could in Logic 6, but my experience is that this isn't a great loss.

@julian said:

Copy app, re-name, and off you go

julian

Well, now if that's not a kick in the head. [[:|]]

Thanks for the tip, Julian. This gives me ideas about other apps not related to VI.

Please read my last post, JWL. I'm telling you, it won't work. [:)]

@Nick Batzdorf said:

Please read my last post, JWL. I'm telling you, it won't work. [:)]

I'm not referring to the Logic app but the standalone VI app.

julian

www.julianscott.com/Vienna_7GB.jpg

This link is a screen shot of 2 Standalone instances of VI and Logic running a plug-in VI. The total sample load, as defined in the VI windows is a total of 112931 samples - just short of 7GB. They do actually play as well!

I would suggest, as it is such a simple task, that anyone interested try on their own system see what results they obtain.

Julian[/url]

@Nick Batzdorf said:

Please read my last post, JWL. I'm telling you, it won't work. [:)]

Hi Nick:

I was certain multiples of Logic wouldn't work, but as julian said it was VI and not Logic to which he was referring.

At present, I'm just looking on with curiosity and not trying any new tricks right off until I feel a little better about how Syncrosoft will behave.

But in honesty, if the big question for VI users is how to get more instances running, knowing that people are *at least* running Standalone and the Plugin version concurrently is good to know. Running another instance under a different name-- daring-- but these are considerably more cost effective interim solutions shy of buying a second mac or pc.