No matter how much memory is available, real or virtual, how fast the processor, one or many, there will always be problems too big to solve with the available resources. In addition, the precision of calculations is limited. The more significant digits, the slower the calculations. The less significant digits, round off errors get you.
Forcing a particular way to solve a problem is like trying to drive a Ferrari up a mountain bike trail, then complaining because it won't do it. Look for other ways to solve the problem with the resources available. Maybe there's a paved road on the other side of the mountain. In the 60's at my job we ran a 600 line per minute printer, card reader and punch, all at full speed simultaneously with a 16k IBM 1401 computer. In the 70's or 80's we satisfied hundreds of time sharing users with an IBM 168 with only 1 meg of memory. We did it because that was all there was available. Now we can hold more computing power in the palm of our hand than what would fill a city block back then. The challenge today is the same as it was back then. Find a way to solve the problem with what's available. On Tue, Jan 19, 2010 at 3:38 AM, Ian Clark <[email protected]>wrote: > Here's my two-penn'orth, which will have everyone shaking their heads in > pity... > > Why don't you post the code which blows up for you, Dieter? Or maybe a > simplified sample which reproduces the problem. Then I can try it on > my new g-wiz iMac -- I haven't seen an out-of-memory yet. That's > because as a coder I'm a timid old dinosaur and haven't got used to > 4MB of RAM, let alone 4GB. But the Mac may have some VM tricks up its > sleeve: those Apple folk have been fitting quarts into pint pots since > 1985. Perhaps I'll be treated to the sight of 603GB of disk filling up > before my eyes with (presumably) meaningful calculations. :) > > Bill is right though -- the iMac under Snow Leopard can only run J32, > not J64. But AFAIK this is to do with the Mac version of J being > confined to 32-bit Java for its top-end (Snow Leopard now includes > 64-bit Java). The problem may go away (...will go away?) with the new > J in beta. > > Alex's post caught my eye, as a modern variation on multiprocessing a > big algorithm as discussed by Eugene McDonnell (1994) in APWJ. Maybe > the chapter is still worth reading to cast light on your problem. > http://www.jsoftware.com/jwiki/Doc/Articles/Play104 > > Ian > > > On Tue, Jan 19, 2010 at 5:20 AM, DIETER ENSSLEN <[email protected]> > wrote: > > thanks > > > > that would be a shame, that the J program is RAM limited to 2 GB, I > assumed the out of memory problem was hardware and hence pocket book > limited. > > > > So no benefit from 8, 16, 32, 64 etc GB RAM machines, unless running 64 > bits which they would. > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
