Status: Accepted
Owner: [hidden email] Labels: Type-Bug Importance-High New issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 NativeBoost is not usable in deployment scenarios without sources. See http://lists.gforge.inria.fr/pipermail/pharo-project/2013-January/072833.html -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #1 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 In 3.0, we will solve that by putting the source in the image and get rid of .sources and .changes -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #2 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 Put the sources into the image? You can arque that memory/storage is cheap. But 1. still we have a growing number of mobile platforms/devices with limited resources and when I deploy the source makes no sense. 2. There is another reason to better work on a smaller (than larger image with sources and changes): in web scenarios where one wants to scale by balancing load to more than one image: http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing Pharo should IMHO be clean AND lean. So I think we should really think about the IMAGE-SOURCE-CHANGES-AppPACKAGE relations for the different scenarios. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: Milestone-3.0 Comment #3 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 sources go into the image in 3.0, there might be other solutions but that's the way we go. Whether they are user-visible and can be removed is a different question. 1. Doesn't count, Pharo is roughly 30MB in Memory WITH the sources 2. Again 30BM? really? by the time 3.0 is going to be released the memory will have doubled. On my 4 year old desktop machine I have 4GB RAM, that translates to roughly 60 images if only 2GB are available. Which IMO will serve for a very high-traffic website. So all your arguments are fairly shady. Changes will be handled as described here https://github.com/dh83/pharo-dev-text/blob/master/pharo30Changes.md -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #4 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 With 60 VMs running, the dupication you get from every JIT having it's own code cache is quite large, too. Or CompiledMethods... could be shared, too. What makes the source special? Why should it be special? Why don't we solve that problem in a general way? and 25MB is not large even for Mobile or even embedded. We live in a world where you can boy a whole machine with 512MB RAM for $35. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #5 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 Sorry but this is a very single sided view. Speed and size still matters. I agree that there are more and more cases where you can savely ignore them and time will work for us here too. But why do you write a JIT when computer get speedier? Why do you care about single bits in VM object headers, fuel serialized monticello packages to get small and fast package downloads, ... I want to see a pharo that works also on exactly the tiny and cheap machines that now appear to provide apps, ... and where you dont need the sources if you just deploy. Or were a company want to secure its intellectual property by not giving the sources away. Also think of a Pharo written app that runs on a JS bootstrapped Amber like Pharo environment on a webpage. Similar to Linux on JS http://bellard.org/jslinux I worked with SmalltalkMT and Smallscript/S# in the past, they were fast and created lean components that were small and easily able to transfer over any slow connection. Maybe I'm therefore biased and just have to be convinced with Pharo 3.0 ... -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #6 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 And is it the same Marcus writing here who wrote today: "Did you solve the problem that it was wasting ca. 4MB if memory because it had a copy of the complete catalog (everything but the files) on the client?" http://lists.gforge.inria.fr/pipermail/pharo-project/2013-February/075164.html Sorry - couldnt resist ;) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #7 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 I think the idea is to reify the sources as individual source objects in the image itself. That creates the option of having an empty or missing source object, or an object that refers to source somewhere else, right ? In any case, I think that abandoning sources will remain possible for special use cases. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #8 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 Exactly. People where arguing in Squeak (many many Moore's doublings ago, when they might have had a point even) that is *impossible* to put the source into memory. Because you can't ever waste 4MB (which is the compressed size). At the same time, they where using Squeak with a SqueakMap catalog that was wasting 4MB and they did not even know it. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #9 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 OK, then stop the discussion about in-image sources and move on to 3.0 and see how I can be convinced :) Nonetheless the topic of this issue is that NB always requires the sources to work and if abondened it will not be usable. This will be the same issue in 3.0 because we just changed the place where the source is stored. I also dont think this is a special use case. We want NB to be the next FFI and in commercial environments you typically need a good FFI to interface with existing code/components. Mostly in these scenarios you want to throw out the sources since companies do not want to give intelectual property away... -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #10 on issue 7525 by [hidden email]: NativeBoost not usable in deployment scenarios without sources http://code.google.com/p/pharo/issues/detail?id=7525 statistics what one needs to build Android from source: -6GB of download. -25GB disk space to do a single build. -80GB disk space to build all AOSP configs at the same time. -16GB RAM recommended, more preferred, anything less will measurably benefit from using an SSD. -5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on my workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD). -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Free forum by Nabble | Edit this page |