I was wondering what the latest is on 64-bit Operating System compatibility (both OS X and Windows) in Igor Pro. I want to load many large data files (sometimes each is greater than 1GB). My current experiences have only allowed up to about 1 GB worth of data in memory on an OS X machine with 4GB RAM installed. I was hoping to use all available memory now, and in the future, that would definitely exceed 4 GB, on either a Windows or an OS X machine. Any information regarding memory use in Igor Pro would be greatly appreciated.
I'm not sure why you can load only 1 GB. I tried this on a Mac OS X 10.5 system with 10 GB (though Igor's virtual memory is 4 GB):
Make/B/U/N=(1E9) big0 // Worked Make/B/U/N=(1E9) big1 // Worked Make/B/U/N=(1E9) big2 // Worked Make/B/U/N=(1E9) big3 // Failed
This behavior is what I would expect. If you have not already done it, execute this and read the help:
DisplayHelpTopic"Memory Management"
As to the larger question of a 64-bit Igor, this is on our to-do list with fairly high priority. However, it will be for Windows only because Apple does not support 64 bit Carbon programs. To make a 64-bit Macintosh Igor, we will have to port the entire program to a different Apple API (Cocoa). This will take a long time if we do it at all.
The 64-bit Windows port is also a big job as we have to make hundreds of source files and many libraries 64-bit clean. And that's before we get to XOPs. In other words, although a 64-bit Windows is on our list, it will take months of additional work. And we may run into a show-stopper along the way.
I am all for 64 bit Igor on Windows. I am concerned about Wavemetrics' approach to the Mac side of things. As of OS X 10.6, support for programs running under Carbon is waning. It would seem to me that if Igor is to be sustainable on the Mac, it will require a rewrite of the code to be directly compatible with the Intel processors.
I am all for 64 bit Igor on Windows. I am concerned about Wavemetrics' approach to the Mac side of things. As of OS X 10.6, support for programs running under Carbon is waning. It would seem to me that if Igor is to be sustainable on the Mac, it will require a rewrite of the code to be directly compatible with the Intel processors.
Carbon will still run under Rosetta, so support has not gone identically to zero at this stage. Igor will IMHO still continue to be a top choice for serious data analysis well throughout all of OS 10.6.x and perhaps even into 10.7.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
I am all for 64 bit Igor on Windows. I am concerned about Wavemetrics' approach to the Mac side of things. As of OS X 10.6, support for programs running under Carbon is waning. It would seem to me that if Igor is to be sustainable on the Mac, it will require a rewrite of the code to be directly compatible with the Intel processors.
Thats not strictly true. Carbon is an OS X API that was designed to give backward compatibility to Mac operating systems previous to OS X. Carbon + Igor are directly compatible with Intel processors, that's not the issue at all. Igor does not have to be run through Rosetta.
The trouble is that Apple has only got a 32 bit version of the Carbon API, all new development for 64 bit Mac applications is through the Cocoa API, which is Objective C. For IGOR to be 64 bit on Mac it would have to be rewritten to use the Cocoa API, which is an enormous task.
Carbon will still run under Rosetta, so support has not gone identically to zero at this stage. Igor will IMHO still continue to be a top choice for serious data analysis well throughout all of OS 10.6.x and perhaps even into 10.7.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
Does this mean that Igor will NEVER be ported from Carbon? If so, as a Mac user, I need to start looking elsewhere for an alternative analysis platform.
Thats not strictly true. Carbon is an OS X API that was designed to give backward compatibility to Mac operating systems previous to OS X. Carbon + Igor are directly compatible with Intel processors, that's not the issue at all. Igor does not have to be run through Rosetta.
The trouble is that Apple has only got a 32 bit version of the Carbon API, all new development for 64 bit Mac applications is through the Cocoa API, which is Objective C. For IGOR to be 64 bit on Mac it would have to be rewritten to use the Cocoa API, which is an enormous task.
Thanks for the clarification.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
I would like to add my application to the wish list for 64-bit Igor.
In other words, this would be a very useful feature for me.
I am currently running Igor on 64-bit Windows 8 on a quad-core machine with 4 GB RAM. I could easily get my hands on more RAM if there were a benefit to it. For example, I could just run the code on Windows Azure.
The application:
My colleagues in the lab are running experiments in situations where stochastic behavior is important. They measure large numbers of time courses and calculate the stochastic variance instead of just looking at the averages. I am working on a Monte Carlo simulation for this lab work, where each simulation creates a time-course file. In Igor, I read the file (producing multiple waves) and create some distributions, histograms, and plots. Then I fit the analytic solution of a few differential equations to all time courses, and use the results to create more distributions, histograms, and plots. In the fit function, I am using exactly the same Igor code that the experimentalists used to fit their data, so I don't want to change that.
My simulation currently creates a time course with 1,000 points, and runs 500 times. I would like to increase that to 10,000x10,000, but I am running into paging issues at 1,000x1,000.
Thanks
Tom
Hello Howard,
thanks for the tip! This has really helped me.
On a sample calculation of 1,000 time courses of 1,000 points each, Igor64 required 2:37 (157s) and Igor32 required 1:43:11 (6191s), meaning that it was faster by a factor of 40. I don't know enough to say exactly where the difference is, because I don't know enough about how Windows allocates memory and how to interpret Task Manager / Resource Monitor, but this looks very much like paging.
Tom
Make/B/U/N=(1E9) big1 // Worked
Make/B/U/N=(1E9) big2 // Worked
Make/B/U/N=(1E9) big3 // Failed
This behavior is what I would expect. If you have not already done it, execute this and read the help:
As to the larger question of a 64-bit Igor, this is on our to-do list with fairly high priority. However, it will be for Windows only because Apple does not support 64 bit Carbon programs. To make a 64-bit Macintosh Igor, we will have to port the entire program to a different Apple API (Cocoa). This will take a long time if we do it at all.
The 64-bit Windows port is also a big job as we have to make hundreds of source files and many libraries 64-bit clean. And that's before we get to XOPs. In other words, although a 64-bit Windows is on our list, it will take months of additional work. And we may run into a show-stopper along the way.
April 18, 2009 at 09:13 pm - Permalink
September 14, 2009 at 03:00 pm - Permalink
Carbon will still run under Rosetta, so support has not gone identically to zero at this stage. Igor will IMHO still continue to be a top choice for serious data analysis well throughout all of OS 10.6.x and perhaps even into 10.7.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
September 14, 2009 at 05:08 pm - Permalink
Thats not strictly true. Carbon is an OS X API that was designed to give backward compatibility to Mac operating systems previous to OS X. Carbon + Igor are directly compatible with Intel processors, that's not the issue at all. Igor does not have to be run through Rosetta.
The trouble is that Apple has only got a 32 bit version of the Carbon API, all new development for 64 bit Mac applications is through the Cocoa API, which is Objective C. For IGOR to be 64 bit on Mac it would have to be rewritten to use the Cocoa API, which is an enormous task.
September 14, 2009 at 05:24 pm - Permalink
http://en.wikipedia.org/wiki/Carbon_%28API%29
for more info. Also see the links in the notes at the bottom of the Wiki page.
September 14, 2009 at 05:32 pm - Permalink
Does this mean that Igor will NEVER be ported from Carbon? If so, as a Mac user, I need to start looking elsewhere for an alternative analysis platform.
September 14, 2009 at 08:07 pm - Permalink
Thanks for the clarification.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
September 15, 2009 at 08:28 am - Permalink
We do plan to rewrite Macintosh Igor so that it will be able to run as a 64-bit application. That will take a long time, like a year or two.
An experimental 64-bit Windows version will be available probably in the next few months.
September 15, 2009 at 09:44 am - Permalink
And to make it explicit, the rewrite would remove all the Carbon code and replace it with Cocoa-using code.
Software Engineer, WaveMetrics, Inc.
September 15, 2009 at 10:42 am - Permalink
September 16, 2009 at 11:10 am - Permalink
September 16, 2009 at 11:44 am - Permalink
In other words, this would be a very useful feature for me.
I am currently running Igor on 64-bit Windows 8 on a quad-core machine with 4 GB RAM. I could easily get my hands on more RAM if there were a benefit to it. For example, I could just run the code on Windows Azure.
The application:
My colleagues in the lab are running experiments in situations where stochastic behavior is important. They measure large numbers of time courses and calculate the stochastic variance instead of just looking at the averages. I am working on a Monte Carlo simulation for this lab work, where each simulation creates a time-course file. In Igor, I read the file (producing multiple waves) and create some distributions, histograms, and plots. Then I fit the analytic solution of a few differential equations to all time courses, and use the results to create more distributions, histograms, and plots. In the fit function, I am using exactly the same Igor code that the experimentalists used to fit their data, so I don't want to change that.
My simulation currently creates a time course with 1,000 points, and runs 500 times. I would like to increase that to 10,000x10,000, but I am running into paging issues at 1,000x1,000.
Thanks
Tom
September 16, 2013 at 08:24 am - Permalink
September 16, 2013 at 09:19 am - Permalink
thanks for the tip! This has really helped me.
On a sample calculation of 1,000 time courses of 1,000 points each, Igor64 required 2:37 (157s) and Igor32 required 1:43:11 (6191s), meaning that it was faster by a factor of 40. I don't know enough to say exactly where the difference is, because I don't know enough about how Windows allocates memory and how to interpret Task Manager / Resource Monitor, but this looks very much like paging.
Tom
September 17, 2013 at 10:18 am - Permalink
Yes, that explains the difference.
September 17, 2013 at 02:03 pm - Permalink