Issue 7525 in pharo: NativeBoost not usable in deployment scenarios without sources

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