Re: Group prefix on messages
All my messages to jvm-languages@googlegroups.com are automatically filtered based on a 'to:jvm-languages@googlegroups.com', which then applies a label and archives it. Having a subject doesn't give you anything extra that you can't get from automatic filters applying labels. Alex. On Dec 1, 2007 3:12 AM, David Pollak [EMAIL PROTECTED] wrote: +1 GMail is easier to deal with if stuff is in the title On 11/30/07, Alex Lam S.L. [EMAIL PROTECTED] wrote: Just my 2 cents: I use jvm-languages@googlegroups.com as the filter criterion, and so far it's been working like a charm. Alex. On Nov 30, 2007 11:35 PM, Fernando Meyer [EMAIL PROTECTED] wrote: Hi, Could someone ( managers ) add the [jvm-languages] as prefix for every message, I think it's better for organization/classification. as well we can quickly spot some interesting message between all those unnecessary emails :) regards -- Fernando Meyer http://fmeyer.org JBoss Rules Core Developer [EMAIL PROTECTED] -- lift, the secure, simple, powerful web framework http://liftweb.net Collaborative Task Management http://much4.us --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
Re: A HotSpot oddity
More interesting data points:
On a 64-bit machine running linux there's no difference between the
client and server times. I don't know whether this is because the
64-bit client and server VM optimisations aren't as different as they
are in 32-bit mode or whether there's some advantage to 64-bit here
(if there is, gcc isn't taking advantage of it, see below).
The obvious C translation of
#include stdio.h
int main(){
long bits = 0L;
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
printf(%d, bits);
}
Seems to take longer than the client time, regardless of whether it's
in 64 or 32 bit mode.
On Dec 1, 2007 3:18 AM, David Pollak [EMAIL PROTECTED] wrote:
Yeah, the Scala code was a port of Java code that does similar things. With
the Scala command line and some other Scala tools, it's much faster to make
a change and test the change with Scala than with Java.
On 11/30/07, David MacIver [EMAIL PROTECTED] wrote:
For what it's worth, the obvious Java translation does the same thing:
class Foo{
public static void main(String[] args){
long bits = 0L;
long start = System.currentTimeMillis();
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
System.out.println(bits);
long end = System.currentTimeMillis();
System.out.println(end-start);
}
}
So it isn't a quirk of the bytecode scala produces
On Nov 30, 2007 11:18 PM, Erik Engbrecht [EMAIL PROTECTED] wrote:
David,
For me 1.5 and 1.6 perform about the same...1.6 is a little faster.
However, -server yields the surprisingly fast results that you are
seeing
under 1.6 and -client yields the slow results that you are seeing under
1.5.
It still doesn't explain why it's so fast...but it's another data point.
I'm using an ancient computer with Linux.
-Erik
On Nov 30, 2007 5:49 PM, David Pollak [EMAIL PROTECTED]
wrote:
I've got the following Scala code:
object Foo {
def main(argv: Array[String]) {
var bits = 0L
val start = System.currentTimeMillis()
var n = 21
// var n = 21L // makes things very slow
while (n 0) {
bits = bits ^ (1 5)
n = n - 1
}
System.out.println(bits)
val end = System.currentTimeMillis()
System.out.println (end-start)
}
}
I'm enclosing the source and the bytecode.
There are 2B iterations.
On my Core 2 Quad running JDK 1.6 (32 bit), the code takes 2 ms to
run.
On my Mac Book Pro (Core Duo, JDK 1.5) it takes 6,600 ms.
The run time on the Mac seems more reasonable. What's going on?
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
http://erikengbrecht.blogspot.com/
http://liftweb.net
Collaborative Task Management http://much4.us
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~--~~~~--~~--~--~---
Re: A HotSpot oddity
Scala faster than C post to reddit, anyone? ;-)
On 1 Dec 2007, at 10:53, David MacIver wrote:
More interesting data points:
On a 64-bit machine running linux there's no difference between the
client and server times. I don't know whether this is because the
64-bit client and server VM optimisations aren't as different as they
are in 32-bit mode or whether there's some advantage to 64-bit here
(if there is, gcc isn't taking advantage of it, see below).
The obvious C translation of
#include stdio.h
int main(){
long bits = 0L;
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
printf(%d, bits);
}
Seems to take longer than the client time, regardless of whether it's
in 64 or 32 bit mode.
On Dec 1, 2007 3:18 AM, David Pollak [EMAIL PROTECTED]
wrote:
Yeah, the Scala code was a port of Java code that does similar
things. With
the Scala command line and some other Scala tools, it's much faster
to make
a change and test the change with Scala than with Java.
On 11/30/07, David MacIver [EMAIL PROTECTED] wrote:
For what it's worth, the obvious Java translation does the same
thing:
class Foo{
public static void main(String[] args){
long bits = 0L;
long start = System.currentTimeMillis();
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
System.out.println(bits);
long end = System.currentTimeMillis();
System.out.println(end-start);
}
}
So it isn't a quirk of the bytecode scala produces
On Nov 30, 2007 11:18 PM, Erik Engbrecht
[EMAIL PROTECTED] wrote:
David,
For me 1.5 and 1.6 perform about the same...1.6 is a little faster.
However, -server yields the surprisingly fast results that you are
seeing
under 1.6 and -client yields the slow results that you are seeing
under
1.5.
It still doesn't explain why it's so fast...but it's another data
point.
I'm using an ancient computer with Linux.
-Erik
On Nov 30, 2007 5:49 PM, David Pollak [EMAIL PROTECTED]
wrote:
I've got the following Scala code:
object Foo {
def main(argv: Array[String]) {
var bits = 0L
val start = System.currentTimeMillis()
var n = 21
// var n = 21L // makes things very slow
while (n 0) {
bits = bits ^ (1 5)
n = n - 1
}
System.out.println(bits)
val end = System.currentTimeMillis()
System.out.println (end-start)
}
}
I'm enclosing the source and the bytecode.
There are 2B iterations.
On my Core 2 Quad running JDK 1.6 (32 bit), the code takes 2 ms to
run.
On my Mac Book Pro (Core Duo, JDK 1.5) it takes 6,600 ms.
The run time on the Mac seems more reasonable. What's going on?
--
lift, the secure, simple, powerful web framework http://
liftweb.net
Collaborative Task Management http://much4.us
--
http://erikengbrecht.blogspot.com/
http://liftweb.net
Collaborative Task Management http://much4.us
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~--~~~~--~~--~--~---
Re: A HotSpot oddity
Surely it's no news that Java is competitive with C for pure numeric
operations.
On Dec 1, 2007 11:02 AM, Neil Bartlett [EMAIL PROTECTED] wrote:
Scala faster than C post to reddit, anyone? ;-)
On 1 Dec 2007, at 10:53, David MacIver wrote:
More interesting data points:
On a 64-bit machine running linux there's no difference between the
client and server times. I don't know whether this is because the
64-bit client and server VM optimisations aren't as different as they
are in 32-bit mode or whether there's some advantage to 64-bit here
(if there is, gcc isn't taking advantage of it, see below).
The obvious C translation of
#include stdio.h
int main(){
long bits = 0L;
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
printf(%d, bits);
}
Seems to take longer than the client time, regardless of whether it's
in 64 or 32 bit mode.
On Dec 1, 2007 3:18 AM, David Pollak [EMAIL PROTECTED]
wrote:
Yeah, the Scala code was a port of Java code that does similar
things. With
the Scala command line and some other Scala tools, it's much faster
to make
a change and test the change with Scala than with Java.
On 11/30/07, David MacIver [EMAIL PROTECTED] wrote:
For what it's worth, the obvious Java translation does the same
thing:
class Foo{
public static void main(String[] args){
long bits = 0L;
long start = System.currentTimeMillis();
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
System.out.println(bits);
long end = System.currentTimeMillis();
System.out.println(end-start);
}
}
So it isn't a quirk of the bytecode scala produces
On Nov 30, 2007 11:18 PM, Erik Engbrecht
[EMAIL PROTECTED] wrote:
David,
For me 1.5 and 1.6 perform about the same...1.6 is a little faster.
However, -server yields the surprisingly fast results that you are
seeing
under 1.6 and -client yields the slow results that you are seeing
under
1.5.
It still doesn't explain why it's so fast...but it's another data
point.
I'm using an ancient computer with Linux.
-Erik
On Nov 30, 2007 5:49 PM, David Pollak [EMAIL PROTECTED]
wrote:
I've got the following Scala code:
object Foo {
def main(argv: Array[String]) {
var bits = 0L
val start = System.currentTimeMillis()
var n = 21
// var n = 21L // makes things very slow
while (n 0) {
bits = bits ^ (1 5)
n = n - 1
}
System.out.println(bits)
val end = System.currentTimeMillis()
System.out.println (end-start)
}
}
I'm enclosing the source and the bytecode.
There are 2B iterations.
On my Core 2 Quad running JDK 1.6 (32 bit), the code takes 2 ms to
run.
On my Mac Book Pro (Core Duo, JDK 1.5) it takes 6,600 ms.
The run time on the Mac seems more reasonable. What's going on?
--
lift, the secure, simple, powerful web framework http://
liftweb.net
Collaborative Task Management http://much4.us
--
http://erikengbrecht.blogspot.com/
http://liftweb.net
Collaborative Task Management http://much4.us
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~--~~~~--~~--~--~---
Re: A HotSpot oddity
I think I've figured out what's going on. I can't figure out how to
get sufficient debug information out of the server hotspot to verify
this, but it seems to make sense and performing the translation
manually produces comparable speedups in the client VM.
class Foo{
public static void main(String[] args){
long bits = 0L;
long start = System.currentTimeMillis();
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
System.out.println(bits);
long end = System.currentTimeMillis();
System.out.println(end-start);
}
Unroll this loop by a factor of 2. So
while (n 0) {
bits ^= (1 5);
n--;
}
becomes
while (n 1) {
bits ^= (1 5);
n--;
bits ^= (1 5);
n--;
}
if (n == 1){
bits ^= (1 5);
n--;
}
Now we can reorder the unrolled loop as
while (n 1) {
bits ^= (1 5) ^= (1 5);
n--;
n--;
}
But
bits ^= (1 5) ^= (1 5)
is the same as
bits ^= ( (1 5) ^ (1 5) )
Which is the same as
bits ^= 0
Which is bits = bits, a no-op.
So we can remove that calculation from the loop entirely.
So basically the reason the server VM is so freaking fast is that the
loop body is practically empty. :-) It's just the end result of a few
simple throwing away uneccessary work optimisations, nothing magic.
On Dec 1, 2007 1:13 AM, David MacIver [EMAIL PROTECTED] wrote:
For what it's worth, the obvious Java translation does the same thing:
class Foo{
public static void main(String[] args){
long bits = 0L;
long start = System.currentTimeMillis();
int n = 21;
while (n 0) {
bits ^= (1 5);
n--;
}
System.out.println(bits);
long end = System.currentTimeMillis();
System.out.println(end-start);
}
}
So it isn't a quirk of the bytecode scala produces
On Nov 30, 2007 11:18 PM, Erik Engbrecht [EMAIL PROTECTED] wrote:
David,
For me 1.5 and 1.6 perform about the same...1.6 is a little faster.
However, -server yields the surprisingly fast results that you are seeing
under 1.6 and -client yields the slow results that you are seeing under 1.5.
It still doesn't explain why it's so fast...but it's another data point.
I'm using an ancient computer with Linux.
-Erik
On Nov 30, 2007 5:49 PM, David Pollak [EMAIL PROTECTED]
wrote:
I've got the following Scala code:
object Foo {
def main(argv: Array[String]) {
var bits = 0L
val start = System.currentTimeMillis()
var n = 21
// var n = 21L // makes things very slow
while (n 0) {
bits = bits ^ (1 5)
n = n - 1
}
System.out.println(bits)
val end = System.currentTimeMillis()
System.out.println(end-start)
}
}
I'm enclosing the source and the bytecode.
There are 2B iterations.
On my Core 2 Quad running JDK 1.6 (32 bit), the code takes 2 ms to run.
On my Mac Book Pro (Core Duo, JDK 1.5) it takes 6,600 ms.
The run time on the Mac seems more reasonable. What's going on?
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
--
http://erikengbrecht.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups JVM
Languages group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~--~~~~--~~--~--~---
Re: Group prefix on messages
Filter on to:jvm-languages (etc) with gmail working for me for years now. shrug On Nov 30, 2007 10:12 PM, David Pollak [EMAIL PROTECTED] wrote: +1 GMail is easier to deal with if stuff is in the title On 11/30/07, Alex Lam S.L. [EMAIL PROTECTED] wrote: Just my 2 cents: I use jvm-languages@googlegroups.com as the filter criterion, and so far it's been working like a charm. Alex. On Nov 30, 2007 11:35 PM, Fernando Meyer [EMAIL PROTECTED] wrote: Hi, Could someone ( managers ) add the [jvm-languages] as prefix for every message, I think it's better for organization/classification. as well we can quickly spot some interesting message between all those unnecessary emails :) regards -- Fernando Meyer http://fmeyer.org JBoss Rules Core Developer [EMAIL PROTECTED] -- lift, the secure, simple, powerful web framework http://liftweb.net Collaborative Task Management http://much4.us --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
Re: Group prefix on messages
I also think that labels are unnecessary. Richard Warburton On Dec 1, 2007 2:11 PM, Michael Campbell [EMAIL PROTECTED] wrote: Filter on to:jvm-languages (etc) with gmail working for me for years now. shrug On Nov 30, 2007 10:12 PM, David Pollak [EMAIL PROTECTED] wrote: +1 GMail is easier to deal with if stuff is in the title On 11/30/07, Alex Lam S.L. [EMAIL PROTECTED] wrote: Just my 2 cents: I use jvm-languages@googlegroups.com as the filter criterion, and so far it's been working like a charm. Alex. On Nov 30, 2007 11:35 PM, Fernando Meyer [EMAIL PROTECTED] wrote: Hi, Could someone ( managers ) add the [jvm-languages] as prefix for every message, I think it's better for organization/classification. as well we can quickly spot some interesting message between all those unnecessary emails :) regards -- Fernando Meyer http://fmeyer.org JBoss Rules Core Developer [EMAIL PROTECTED] -- lift, the secure, simple, powerful web framework http://liftweb.net Collaborative Task Management http://much4.us --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
Re: A HotSpot oddity
On Dec 1, 2007 4:17 PM, Richard Warburton [EMAIL PROTECTED] wrote: On a 64-bit machine running linux there's no difference between the client and server times. I don't know whether this is because the 64-bit client and server VM optimisations aren't as different as they are in 32-bit mode or whether there's some advantage to 64-bit here (if there is, gcc isn't taking advantage of it, see below). I believe that the 64bit SUN JVM defaults to server mode. The expectation is that 64bit things would be used on a server. I tried it with the -client flag as well. So it may not be a case of default so much as Always runs in server mode. It would definitely explain some of the problems I've seen with Swing on 64-bit VMs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
Re: Group prefix on messages
Daniel Green wrote: For some users in certain environments/clients it is clear that a prefix would provide clarity. Don't make the assumption that everyone is able to use the gmail web interface. So if some will be helped, as many responders to this post have claimed, the question becomes, would titles prefixed by [jvm] degrade quality for users who do not want it? I think a short prefix is acceptable, and the only arguments against it are for space/clutter reasons. For folks that don't filter mail, I know it can be irritating to not have something in the title to visually distinguish. So I'll add a prefix of [jvm-l] to mail ([jvm] seemed a bit too general). - Charlie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
[jvm-l] Re: Group prefix on messages
On Saturday 01 December 2007 14:31, Daniel Green wrote: For some users in certain environments/clients it is clear that a prefix would provide clarity. Don't make the assumption that everyone is able to use the gmail web interface. It has nothing whatsoever to do with GMail. Any even half-way capable mail client can filter on arbitrary header fields, regardless of whether or not they're typically shown in the message display. They are able to accommodate a list identification outside the Subject: header. In fact, if you think about the word itself, it is completely irrelevant to the forum on which any given message is posted. So if some will be helped, as many responders to this post have claimed, the question becomes, would titles prefixed by [jvm] degrade quality for users who do not want it? Of course it would. It's an endlessly repeated piece of entirely redundant information, at least as far as Subject: headers are concerned. While there may be a small fraction of users who subscribe to only a handful of lists, those who subscribe to many naturally create separate folders for each subscription. For these people, adulterated Subject: headers are just that: adulterated; contaminated; befouled. I don't think list administrators should cater to users of impoverished mail clients or to users who cannot figure out how to use the capabilities their mail clients make available to them. Randall Schulz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
[jvm-l] Re: Group prefix on messages
On Dec 1, 2007 3:20 PM, Randall R Schulz [EMAIL PROTECTED] wrote: On Saturday 01 December 2007 14:31, Daniel Green wrote: For some users in certain environments/clients it is clear that a prefix would provide clarity. Don't make the assumption that everyone is able to use the gmail web interface. It has nothing whatsoever to do with GMail. Any even half-way capable mail client can filter on arbitrary header fields, regardless of whether or not they're typically shown in the message display. They are able to accommodate a list identification outside the Subject: header. In fact, if you think about the word itself, it is completely irrelevant to the forum on which any given message is posted. So if some will be helped, as many responders to this post have claimed, the question becomes, would titles prefixed by [jvm] degrade quality for users who do not want it? Of course it would. It's an endlessly repeated piece of entirely redundant information, at least as far as Subject: headers are concerned. While there may be a small fraction of users who subscribe to only a handful of lists, those who subscribe to many naturally create separate folders for each subscription. For these people, adulterated Subject: headers are just that: adulterated; contaminated; befouled. I subscribe to dozens of lists and manage 5. I've also be participating in discussion lists on the Internet since 1989. I've used more than 2 dozen mail and news readers over the years. I've developed my own workflow and my own preferences. I prefer to use GMail for reading discussion groups. It's available in a near uniform format on all my devices (Linux, Mac, Windows, iPhone, eee PC, etc.) It manages conversations very well. I find it better than almost all my mail clients (except perhaps Thunderbird) for managing communications. I am not a fan of putting different communications in different folders. I find that I can monitor different discussions most effectively if they are all in my in-box, but with a small indicator of which group the discussion is part of. I can quickly scan the titles and make the decision to dive deeper or archive. I have tried the different folders for different groups strategy in the past and I don't like it. I wind up delaying my reading of important stuff and the context switch is costly for me. These are my habits and behaviors. They are different from the optimal habits that other people have developed over the years. This does not make me or someone with other habits a better or worse person. If there was universal agreement on the matter, the universal choice with be enforced by discussion group systems. I don't think I'm stupid. I don't think I'm set in my ways as I try different Internet clients on a regular basis and wind up changing every 3 or 4 years. I do think that I'm able to articulate why I have my preferences. Hopefully, we can turn this discussion back to peoples' preferences without a further devolution into ad homenims. I don't think list administrators should cater to users of impoverished mail clients or to users who cannot figure out how to use the capabilities their mail clients make available to them. I know Charlie's been around the block about as many times as I have... and he's generally more diplomatic than I am. I have weighed in with my vote as have others. I expect that Charlie will listen and make an appropriate decision. I endorse and support any decision he makes and I encourage the rest of the list to do the same. Thanks, David Randall Schulz -- lift, the secure, simple, powerful web framework http://liftweb.net Collaborative Task Management http://much4.us --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups JVM Languages group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~--~~~~--~~--~--~---
