OpenCL Kernels get compiled at execution time (Just in Time, JIT).
This means that any error inside the kernel is discovered at that time.
The error message I get till now are very silent about what the problem of the kernel is.
So there is just one method of commenting and uncommenting to get a kernel debugged just for compilation.
Intel however recently released it’s first beta version of OpenCL with a lot of tools.
As with early Parallel Studio, these tools are only available for Windows (in particular Win Vista + and Server 2008) and not for Linux.
Note, that the runtime for compiling and running OpenCL is available for Linux, Mac and Windows!
Included is the Intel OpenCL Offline Compiler where you can load your kernel and precompile it.
Here the error messages are much more helpfull (of course, helpfull in a way ordinary compiler messages are helpfull :-)).
Nevertheless, a great tool which makes daily programming a lot easier.
When connecting to a wireless N-Network my Xt2 drops quite often connection if certain amounts of data are transferred, i.e. mostly when the data rate is quite high > 5 MB/s.
Following different suggestions about disabling powermanagement, N-Network compatibility and even encryption, I tried different settings in the device driver in Win7.
Basically I changed just one entry:
Fat Channel Intolerant
and the disconnects went away.
Intels states to Fat Cannel Intolerant:
Fat Channel Intolerant
This setting communicates to surrounding networks that this Wi-Fi adapter is not tolerant of 40MHz channels in the 2.4GHz band. The default setting is for this to be disabled (turned off) so that the adapter does not send this notification.
Note These settings are available only if the adapter is an Intel® WiMAX/WiFi Link 5350, Intel® WiMAX/WiFi Link 5150, Intel® WiFi Link 5300, Intel® WiFi Link 5100 or Intel® Wireless WiFi Link 4965AGN.
My opinion is, that the driver did not send this properly, got a wide 40 Mhz Channel and then dropped out.
This often occurs, if the data rate is increasing and quite large in order to ensure maximum bandwidth.
Any comments appreciated that would clear up this behaviour. Even more interesting would be some insights how this behaves in Linux.
Still the disconnects occur, but not so often.
With the newest driver from the dell Homepage the problems are gone till now. (27.08.2010)
It works till now with the current driver 3.15.0 directly from the Intel Homepage
Finally I did a reinstall of Win7 due to some other concerns (Partitioning etc.) and with the default Win7 or Windows Update Driver it works completely flawless since 2 weeks.
Maybe the installs and uninstalls flawed something in the networking, basically, I don’t care.
Thread pinning is very important in order to get feasible and reliable results on todays multi and manycore architectures. Otherwise threads will migrate from one core to another, causing the waste of clock cycles. Even more important, if you placed your memory correctly by first touch on ccNUMA systems, e.g. SGI Altix or every dual socket Intel XEON Core i7, the thread accessing the memory has to go over the QPI interface connecting the two sockets to access the memory if it is migrated to another socket.
Jan Treibig developed a tool for that called likwid-pin.
A sample usage would be as follows:
likwid-pin -s 0 -c”0,1,2,3,4,5,6,7″ ./Exec
This would pin 8 Threads of the executable of the cores 0 to 8.
For information about the topology, just use the other tool, called likwid-topology which gives you cache and core hierarchy.
The skipmask is important and thread implementation specific. Also consider, that in hybrid programs, e.g. OpenMP and MPI, multiple shepard threads are present.