03:12 | dbsx | rabeeh: will you continue to manufacture and support the cubox and cubox/pro? |
03:23 | Coburn | dbsx: did I miss something? |
03:24 | dbsx | http://server.vijge.net/static/cubox/irclog |
03:27 | Coburn | hmm |
03:27 | Coburn | so cubox original family might be getting the axe? |
03:27 | Coburn | in favor for the iSeries... |
03:27 | Coburn | Well, I guess one thing, it's moving away from Marvell |
03:28 | Coburn | We know how well they support drivers :P |
03:28 | Coburn | Still, I wonder how many headaches they'll cause |
13:11 | dbsx | jnettlet: 20k/sec is the answer |
13:12 | jnettlet | dbsx, right so depending on the workload and the fs that can cause some bottlenecks. |
13:13 | jnettlet | depending on your workload that may not make a difference |
13:13 | dbsx | The other figures are not too far away from my USB hard drive |
13:15 | dbsx | Any word on the iwmmxt string functions? |
13:17 | jnettlet | dbsx, just followed up with them and haven't heard anything. Still stuck in legal is my guess. |
13:18 | dbsx | ok |
13:19 | jnettlet | I started working on a patch to glibc to add them to IFUNC |
13:21 | dbsx | i figure that faster string functions must help perl, python and lua. |
13:22 | jnettlet | I actually haven't benchmarked any of the str functions. I was mostly focused on mem* stuff for my project, but it all came in one tarball. |
13:23 | jnettlet | It was dumb of me not to get it cleared for release right away. But that was when I was dumb and naive of the ways of Marvell's legal dept. |
13:23 | jnettlet | :-) |
13:24 | dbsx | The interpreters are usually mem based. |
13:24 | dbsx | I have noticed with my last kenrel (3.11) that /proc/cpuinfo now shows "idivt", anyone know what it is? |
13:30 | jnettlet | it is for thumb instructions I believe |
13:32 | jnettlet | idivt: SDIV and UDIV hardware division in Thumb mode |
13:36 | dbsx | On Cubox I had one application compiled as thumb (just to see what happened). -mthumb 10% faster than -marm |
13:37 | dbsx | gcc 4.8 |
13:39 | jnettlet | which compiler settings were you using? |
13:40 | dbsx | -march=armv7-a -mfpu=vfpv3-d16 -mtune=marvell-pj4 -fomit-frame-pointer -mfloat-abi=hard -mthumb |
13:46 | jnettlet | do you see a difference if you don't use -mtune=marvell-pj4? |
13:46 | dbsx | checking... |
13:47 | jnettlet | that was a new code submission by Marvell. I looked over the patch but never bothered to benchmark it at all. |
13:52 | dbsx | It changes things, but I dont have test figures for an exact comparison of marvell-pj4. |
13:52 | dbsx | I ended up using -mcpu=iwmmxt2 -mfpu=vfpv3-d16 -mtune=marvell-pj4 because it was either faster or competitive, depending on the test app. |
13:55 | jnettlet | that is one of the things on my list. with gcc 4.7 I was only using mcpu=iwmmxt2 for iwmmxt optimized apps because I was seeing some problems. That went away with 4.8 but I still need to make sure it is best to use that everywhere |
13:57 | dbsx | looking again I found one case that gave -mtune=marvell-pj4 an extra 20 seconds in 600 vs no -mtune |
13:57 | dbsx | I must tidy this up, I left comments in the makefiles |
13:58 | jnettlet | I am sorry I forgot. Is this for a specific app? |
13:58 | dbsx | yes |
13:58 | dbsx | A C and Lua mix (a PDF parser). |
14:09 | purch | any information when preordered CuBox-i4Pro's are shipped? |
15:16 | rabeeh | purch: end of Nov |
15:21 | jnettlet | oh just in time for Christmas!!! |
16:25 | purch | nice |
21:28 | cbxbiker61 | I just posted on Xbmc forum about my current Radeon/Vdpau status http://forum.xbmc.org/showthread.php?tid=173812 |
23:05 | rabeeh | Waseem just edited the blog - http://cubox-i.com/carrier-one/ |
23:05 | rabeeh | this is actually the development board that will be sent to devs next week |
23:06 | rabeeh | more pics will come soon |
23:16 | _rmk_ | rabeeh: it's spdif out rather than toslink? |
23:16 | rabeeh | CuBox-i is optical out |
23:17 | rabeeh | C1 is coax out |
23:17 | rabeeh | both spdif |
23:17 | rabeeh | C1 === Carrier one |