IRC log of #cubox of Wed 18 Sep 2013. All times are in CEST < Back to index

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