| viric | can it be that the nanonote is faster than the raspberry pi (for non fp code, of course) | 09:34 |
|---|---|---|
| viric | ? | 09:34 |
| larsc | I doubt it | 10:58 |
| larsc | as far as I know the cpu freq of the rpi is twice that of the nanonote. And usually ARM is not a factor two slower than MIPS when it comes to instructions per clock cycle | 10:59 |
| viric | ok | 10:59 |
| wpwrak | viric: did anyone make such a claim ? or was this just speculation ? | 12:01 |
| viric | my speculation | 12:03 |
| viric | I've seen the nanonote quite capable, and the pi a bit slow. But maybe I simply gave too different jobs to them | 12:03 |
| wpwrak | the display resolution may also make a difference. the ben has only a few pixels to move. | 12:17 |
| larsc | yea, I have seen ben like hardware connected to a 800x600 display, it wasn't pretty ;) | 12:19 |
| viric | I've been only compiling | 12:21 |
| viric | I've 'openssl speed' numbers somewhere | 12:21 |
| viric | of both. | 12:21 |
| DocScrutinizer05 | compiling is 90% IO | 15:06 |
| DocScrutinizer05 | IO in turn is massively depending on your actual hw design, like in "ZX81 computed during the VSYNC period of display only, other time the RAM been busy with video buffer readout" | 15:08 |
| DocScrutinizer05 | well, odd example since that's not even IO | 15:09 |
| DocScrutinizer05 | but anyway I guess you get the picture, regarding using a RAMdisk vs slow MMC flash storage raped by constant swapping and thus slowing down to <1 IOPS for real file access | 15:11 |
| DocScrutinizer05 | the latter commonly known as swap hell on e.g. Nokia N900 | 15:12 |
| DocScrutinizer05 | compiler runs are *very* prone for running into swap hell on any architecture that has small amounts of RAM, compared to filesize of the compiled project | 15:14 |
| DocScrutinizer05 | -j 64 doesn't help either ;-) | 15:15 |
| wpwrak | -j 64 at least makes the situation obvious ;-) | 15:18 |
| qi-bot | [commit] Werner Almesberger: libubb/: helper library for UBB access (master) http://qi-hw.com/p/ben-blinkenlights/2c52dac | 15:31 |
| qi-bot | [commit] Werner Almesberger: swuart/: half-duplex software UART for UBB (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/4689882 | 15:31 |
| qi-bot | [commit] Werner Almesberger: swuart/: use a hardware timer and allow full-duplex operation (master) http://qi-hw.com/p/ben-blinkenlights/8816dcf | 15:31 |
| larsc | gpio uart? | 15:33 |
| wpwrak | yeah | 16:59 |
| wpwrak | and in user space | 16:59 |
| wpwrak | well, with the usual dirty tricks :) | 17:00 |
| wpwrak | for example, i turn off interrupts while sending/receiving | 17:00 |
| wpwrak | of course, it's not perfect. i.e., it has to be ready and polling when a new byte arrives. in a typical request-response dialog, that is normally no problem, but if you have fully independent operation, it would lose receive data | 17:02 |
| wpwrak | what the full-duplex capability does is that it allows responses to begin while still sending. e.g., an echo or maybe in the future xon/xoff flow control | 17:05 |
| DocScrutinizer05 | roh: you've been the rider or the driver of Rudi? ;-D | 18:19 |
| DocScrutinizer05 | ooh, didi senft ... http://www.stern.de/panorama/raddesigner-didi-senft-rentierfahrrad-begeistert-berlin-1942361.html | 18:26 |
| roh | 'touristenscheisse' | 18:33 |
| viric | DocScrutinizer05: hm yes, a lot of IO. | 18:41 |
| DocScrutinizer05 | roh: yup ;-P | 18:42 |
| DocScrutinizer05 | roh: nevertheless I seen two guys with hoods on a weird bike... Instantly thought of you and gismo, you both looked similar in a certain way on Camp | 18:43 |
| DocScrutinizer05 | ;-) | 18:43 |
| wpwrak | wolfspraul: btw, how about adding "antorcha" to the commit notifications on this channel ? http://projects.qi-hardware.com/index.php/p/antorcha/ | 21:05 |
| --- Tue Dec 18 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!