this is the example I pointed out, s/network/filesystem :-) (I apologize if the smiley is passive aggressive, it's not intended that way..)
kris On Mon, Jan 16, 2012 at 11:15 PM, Zsolt Vasvari <zvasv...@gmail.com> wrote: > Or let's take a networking example (since the communactions between a > CPU and the GPU is a network) > > Which one is faster? > > Sending a 1MB file in ONE CHUNK over a 56kbps dial-up line or sending > the same file, ONE BIT AT A TIME, using TCP/IP over high speed > internet? My guess is the former... > > On Jan 17, 12:09 pm, Zsolt Vasvari <zvasv...@gmail.com> wrote: >> Holy macaroni!!!! >> >> What a thread. >> >> Let's take an anology: >> >> First vehicle: A bicycle. You can go reasonably fast with it by the >> power of a single human. >> Second vehicle: A Ferrari with a fifth wheel powered by a pedal. >> >> Which one is faster? The point is, the Ferrari has 10,000x times the >> horsepower of human powered bicycle, but if you are not using it >> correctly, you still end up going slower. >> >> On Jan 17, 10:22 am, Kristopher Micinski <krismicin...@gmail.com> >> wrote: >> >> >> >> > On Mon, Jan 16, 2012 at 6:57 PM, sblantipodi >> >> > <perini.dav...@dpsoftware.org> wrote: >> > >> I am not avoiding anything but you have failed to far to provide me >> > >> with something I could use to find such a flaw and fix it. >> >> > > I have provided you three lines of code that works bad as the other >> > > primitives. >> >> > >> Me neither, but you could be bandwidth limited for instance. Again, >> > >> the CPU has nothing to do with performance of the GPU so this >> > >> discussion is really not helpful. If your performance in software is >> > >> good enough, there is no point in drawing a comparison with other >> > >> devices that also run in software. >> >> > > Bandwidth? Have you ever thought on how much bandwidth have a feature >> > > phone? >> > > Why the software runs better on gingerbread? >> > > Sincerely I'm not satisfied with the performance I get on CPU neither >> > > because I can >> > > do better with other OS. >> > > Talking about CPU performance the software runs far better on Galaxy >> > > Note (Gingerbread 1280x800) >> > > than on Galaxy Nexus (ICS 1280x720). >> > > Why? >> >> > >> This piece of code is exactly what I was talking about in previous >> > >> message. Sending 640 rendering instructions to the GPU is extremely >> > >> expensive. The CPU will perform a lot better at this. Changing this >> > >> loop to a single drawLines() will likely fix the issue. >> >> > > A feature phone is able to do it, gingerbread is able to do it, >> > > why ICS do it slow? >> > > You know that that was only an example, in real life drawLine can't >> > > be >> > > replaced with drawLines at least not always. >> >> > >> Again, the problem is that a GPU performs very differently from a CPU. >> > >> Batching rendering operations is one of the best optimizations you can >> > >> do when running on the GPU. >> >> > >> > In any case on the android documentation (API Level 11) I finded that >> > >> > drawLines() doesn't support antialiasing: >> > >> >http://developer.android.com/guide/topics/graphics/hardware-accel.html >> > >> > why do you call this a bug? >> >> > >> This documentation is out of date. Antialiasing is supported with >> > >> drawLine() and drawLines() as of API level 12 or 13. >> >> > > Are you really asking to drop Level 11 support or double the code to >> > > draw some lines? >> >> > Maybe it's not true, but I think that it seems to me (and I suspect >> > many others on this list), that you fundamentally lack an >> > understanding of the differences between CPUs and GPUs. >> >> > For example, parallelizing the previous bit of code will *obviously* >> > be better on a GPU because of the dispatch than multiple instances of >> > drawLine(), and this isn't a point that make the perf bad: it's just >> > bad coding. >> >> > At *worst* you could argue that the compiler should somehow optimize >> > this to a drawLines call and do some fancy loop transformation based >> > on what it would know about the semantics of those functions and the >> > trade offs you were willing to make. But the example you make seems a >> > lot like a novice saying "Android is slow, I'm reading a megabyte file >> > and it's taking a few hundred milliseconds" when they're doing >> > multiple calls to read one byte... >> >> > kris- Hide quoted text - >> >> > - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
