08-09-2010 12:10 PM
Only when booting as 64bit (using Apple boot plist to toggle between 64 and 32bit boot so I can use ⌘v to verbose log the boot process).
08-09-2010 12:37 PM
landol,
When you state "64bit kernel is useful when I'm running other applications such as Adobe suite." that just means that you need the Adobe suite to run 64 bit which is perfectly possible using a 32 bit kernel. There is not a lot of reason to need a 64 bit kernel at the moment. 64 bit drivers for hardware are the necessary thing and there are not a lot of 3rd party 64 bit drivers at the moment. Maybe Joe can tell us when NI will be issuing 64 bit drivers? My guess is about a year after Mac OS X 10.7 Feral Cat comes out which does not have a 32 bit mode.
For information on running Adobe with 32 bit kernel see this post.
08-09-2010 12:59 PM
No, I do mean that running especially 32bit apps on a 64bit kernel affords from a few up to 30% performance boost due to the TLB:
[quote]Snow Leopard will deliver both a 64-bit kernel and a full set of 64-bit bundled apps, erasing the entire TLB flush issue because the new kernel won't have to share any address space, even when running 32-bit apps (below right).[/quote] http://www.appleinsider.com/articles/08/09/04/road_to_snow_leopard_twice_the_ram_half_the_price_64_b...
See http://macperformanceguide.com/SnowLeopard-64bit.html -- an up to 30% improvement using 32bit Photoshop CS4, that is like getting a significant hardware upgrade for free!
08-09-2010 01:14 PM - edited 08-09-2010 01:16 PM
Also, there may be minor security benefits** to the kernel itself, and, apart from my NI card, all my drivers are working perfectly on my 64bit kernel.
As I am a scientist and not a full time programmer, I can't waste so much time anymore chasing bugs in the NI drivers. I think the Labjack, which is cheaper and has very robust 32/64bit drivers without all the 330MB mass of NI-DAQmx will hopefully save us time and grey hairs: http://labjack.com/support/linux-and-mac-os-x-drivers
** To quote apple: "...64-bit applications can use more advanced security techniques to fend off malicious code. First, 64-bit applications can keep their data out of harm's way thanks to a more secure function argument-passing mechanism and the use of hardware-based execute disable for heap memory. In addition, memory on the system heap is marked using strengthened checksums, helping to prevent attacks that rely on corrupting memory." -- I assume that applies to the kernel as well as individual application...
Joe, here is the crashlog I get:
Process: enumerateDevices [162] Path: /System/Library/Extensions/nipalk.kext/Contents/Resources/enumerateDevices Identifier: enumerateDevices Version: ??? (???) Code Type: X86 (Native) Parent Process: sh [152] PlugIn Path: /Library/Frameworks/nipalu.framework/Versions/1/nipalu PlugIn Identifier: com.ni.framework.nipalu PlugIn Version: 2.5.4 (2.5.4f0) Date/Time: 2010-08-09 18:39:56.858 +0100 OS Version: Mac OS X 10.6.4 (10F569) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x92aecef6 __kill + 10 1 libSystem.B.dylib 0x92aecee8 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x92b7f62d raise + 26 3 libSystem.B.dylib 0x92b956e4 abort + 93 4 com.ni.framework.nipalu 0x001237df _palPrintToLog + 1547 5 com.ni.framework.nipalu 0x0012efc3 0xa5000 + 565187 6 dyld 0x8fe0ed6d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 235 7 dyld 0x8fe0d31e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 246 8 dyld 0x8fe0d2c2 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 154 9 dyld 0x8fe0d3d1 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 61 10 dyld 0x8fe024a9 dyld::initializeMainExecutable() + 134 11 dyld 0x8fe07950 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**) + 4189 12 dyld 0x8fe018b1 dyldbootstrap::start(macho_header const*, int, char const**, long) + 779 13 dyld 0x8fe01057 _dyld_start + 39 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x92b95693 ecx: 0xbfffd74c edx: 0x92aecef6 edi: 0x0012efea esi: 0xbfffd7ec ebp: 0xbfffd768 esp: 0xbfffd74c ss: 0x00000023 efl: 0x00000286 eip: 0x92aecef6 cs: 0x0000000b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x92b7f613 Binary Images: 0x1000 - 0xafff enumerateDevices ??? (???) /System/Library/Extensions/nipalk.kext/Contents/Resources/enumerateDevices 0xa5000 - 0x12effc +com.ni.framework.nipalu 2.5.4 (2.5.4f0) /Library/Frameworks/nipalu.framework/Versions/1/nipalu 0x8fe00000 - 0x8fe4162b dyld 132.1 (???) /usr/lib/dyld 0x9155a000 - 0x91568fe7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <3CE8AA79-F077-F1B0-A039-9103A4A02E92> /usr/lib/libz.1.dylib 0x9231f000 - 0x92365ff7 libauto.dylib ??? (???) <85670A64-3B67-8162-D441-D8E0BE15CA94> /usr/lib/libauto.dylib 0x92a8b000 - 0x92c31feb libSystem.B.dylib 125.2.0 (compatibility 1.0.0) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib 0x94984000 - 0x949eefe7 libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib 0x94d8a000 - 0x94e37fe7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) /usr/lib/libobjc.A.dylib 0x95d9e000 - 0x95da1fe7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib 0x95f3e000 - 0x960c0fe7 libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <2314BD12-0821-75BB-F3BC-98D324CFD30A> /usr/lib/libicucore.A.dylib 0x96108000 - 0x96163ff7 com.apple.framework.IOKit 2.0 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x96268000 - 0x963e2fe3 com.apple.CoreFoundation 6.6.3 (550.29) <00373783-3744-F47D-2191-BEEA658F0C3D> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x98c23000 - 0x98c2fff7 libkxld.dylib ??? (???) <322A4B52-8305-3081-6B74-813C3A87A56D> /usr/lib/system/libkxld.dylib 0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib
08-09-2010 01:34 PM
Yeah, I've seen those claims. But look at the actual benchmarks. If you do the math on all the graphs, the difference between SL-32 and SL-64 is between 3% and 6% with one graph out of the 7 showing a 14%. At the end they seem to throw out the 30% number but I think that is the difference between L and SL.
Have you benchmarked an actual 30% gain? That seems to be one of those numbers for a benchmark that is specifically engineered to give a high value rather than real world experience.
Other than that, you will just have to disable the NIDAQ drivers and startup before booting into 64 bit mode.
08-09-2010 02:11 PM
Ah, sorry for misrepresenting the 30% value. Personally I see about 5% improvement in Matlab, and a bit more in Lightroom 3 (seconds *do* matter when you just want to get something done quickly!). anyway this is getting OT, so I'll stop there
08-09-2010 03:27 PM
I agree seconds do matter. I gather you really really want to run in 64 bit mode. Also having looked at device driver kernel programming I don't believe that there is any security differences between 32 and 64 bit kernels. Once a bad guy is in the kernel it is all over and there are no "memory areas" that can be isolated unlike user space.
The easiest thing is to ignore the NIPAL crash when booting into 64 bit mode. It is unnecessary unless you are using VISA for GPIB, Serial or DAQ operations. Since you can't do that in 64 bit mode it doesn't matter.
The enumerate devices routine fails since the KEXT didn't load. So it expects a KEXT that isn't there and then crashes. Let it crash since it is non-functional anyway.
I think the best is to ask Joe F. here to work on having a 64 bit kernel ready when Apple has a 64 bit kernel only system. My guess is release data for 10.7. I would rather have that ready on release date rather than a year later like this release for 10.6. Since there are developer versions out there, I would hope that NI starts working on it soon! The fact that we are now getting a 10.6 compatible release a year after 10.6 was released is not good.
08-09-2010 04:24 PM
Thanks sth, I'll probably remove nipal as I only need basic I/O and a single analog read, and I suppose that also means I don't need /Library/Application Support/National Instruments/NI-VISA/niLxiDiscovery.app/Contents/MacOS/niLxiDiscovery in my launch daemons either? And for completness sake, as I don't use Labview, do I need that plugin?
08-09-2010 07:27 PM
<Sarcasm ignored mode>
No, it won't work. If you need single analog read then you need the nipal and the VISA kext drivers. See I am not sure what your basic needs are. As far as I can tell the best way to get the combination you want is to boot into 64 bit kernel and run your Adobe applications. Ignore the nipal crash. Do not remove nipal. When you want to do labview data acq you will have to reboot into 32 bit mode. If you need 64 bit kernel for speed in using Adobe while doing hardware I/O using NI products simultaneously then you are out of luck.
</Sarcasm ignored mode>
There is no 64 bit kext from NI for Mac OS X. Thus you cannot do any NI hardware operations when your kernel is in 64 bit mode. You have a trade off between running Adobe with a 64 bit kernel and the time to reboot to use the NI hardware. The nipal crash is expected and irrelevant in 64 bit mode.
Have you bothered to add the need for 64 bit OS X drivers to the NI product suggestion page. This would be a most useful action.
If other vendors have better products then go ahead and use them. Pick the best hardware/software configuration for your needs.
08-11-2010 09:22 AM
Yes, I've added my voice to the product suggestion page and politely moaned at my NI support engineer too for good measure! 🙂
And yes, I've just removed NI-DAQmx base for the moment on my work laptop, my desktop is an older Mac Pro which doesn't support 64bit kernel so I'll limit the DAQ to that machine.
We have to buy several new PCIe cards, and I suppose I'll just see if anyone else has better driver support (sadly LabJack only make USB devices).