I don't know why I thought Java used UTF-8, thank you for the
correction. So yeah, would be interesting to see the tests on C done
with wide char in UTF-16.
On Dec 26, 1:54 am, Glen Stampoultzis wrote:
> On 26 December 2010 03:00, Ivan wrote:
>
> > Would be interesting to see tests done on UTF-8
On 26 December 2010 03:00, Ivan wrote:
> Would be interesting to see tests done on UTF-8 strings as this is the
> only type that Java supports.
>
Do you mean UTF-16?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email
Would be interesting to see tests done on UTF-8 strings as this is the
only type that Java supports.
On a side note, Merry Christmas everyone!
Ivan.
On Dec 25, 4:52 am, Michael Gardner wrote:
> On Dec 24, 2010, at 8:19 PM, David Nolen wrote:
>
> > ((long double) end-start) / 1000.0
>
> I don't th
On Dec 24, 2010, at 8:19 PM, David Nolen wrote:
> ((long double) end-start) / 1000.0
I don't think this math is correct. The units for the values returned by
mach_absolute_time() are CPU-dependent:
http://developer.apple.com/library/mac/#qa/qa2004/qa1398.html
Using gettimeofday() on my 2.0 GHz
On Sat, Dec 25, 2010 at 11:28 AM, David Nolen wrote:
> On Fri, Dec 24, 2010 at 8:19 PM, David Nolen wrote:
>
>> On OS X at least the following program shows identical performance to the
>> JVM using 64 bit integers, ~2000 nanoseconds on my machine. So Clojure is
>> not too far behind.
>>
>
> w/o a
On Fri, Dec 24, 2010 at 8:19 PM, David Nolen wrote:
> On OS X at least the following program shows identical performance to the
> JVM using 64 bit integers, ~2000 nanoseconds on my machine. So Clojure is
> not too far behind.
>
w/o any GCC optimizations of course. With O2, the C is twice as fast
On Fri, Dec 24, 2010 at 7:32 PM, Alan Busby wrote:
> On Fri, Dec 24, 2010 at 7:10 PM, Devrim Baris Acar
> wrote:
>
>> I guess it would be a better guess if you could includethe cpu type/speed
>> for a rough reference...
>
>
> It was on an Intel Xeon E5410 (2.33GHz), though like others have alrea
On Fri, Dec 24, 2010 at 7:10 PM, Devrim Baris Acar wrote:
> I guess it would be a better guess if you could includethe cpu type/speed
> for a rough reference...
It was on an Intel Xeon E5410 (2.33GHz), though like others have already
said there are a number of factors that affect performance. I
I guess it would be a better guess if you could includethe cpu type/speed
for a rough reference...
Devrim Baris Acar
On Fri, Dec 24, 2010 at 09:55, Alan Busby wrote:
> Hi All,
>
>
> On Fri, Dec 24, 2010 at 4:32 PM, Meikel Brandmeyer wrote:
>
> Most interesting is also the relation between t
On Fri, Dec 24, 2010 at 2:55 AM, Alan Busby wrote:
> Hi All,
>
>
> On Fri, Dec 24, 2010 at 4:32 PM, Meikel Brandmeyer wrote:
>
> Most interesting is also the relation between the different versions on
>> the given machine. Just the numbers of one algorithm aren't really
>> comparable, I guess.
Hi All,
On Fri, Dec 24, 2010 at 4:32 PM, Meikel Brandmeyer wrote:
> Most interesting is also the relation between the different versions on the
> given machine. Just the numbers of one algorithm aren't really comparable, I
> guess. (different machine, different load, different phase of moon, wh
Hi,
Am 24.12.2010 um 02:08 schrieb Ken Wesson:
> It's also possible that -server vs. -client is an issue here, also
> running it a few times in a row so JIT will have kicked in. I used
> -server and ran each test a few times until the numbers settled down
> before posting my timings here; I'm not
On Thu, Dec 23, 2010 at 5:10 PM, Sean Corfield wrote:
> On Thu, Dec 23, 2010 at 12:31 PM, Mark Engelberg
> wrote:
>> Any ideas why people are getting such radically different results on
>> their machines? It's hard for library writers to write any kind of
>> optimized code if "optimized" on one
On Thu, Dec 23, 2010 at 12:31 PM, Mark Engelberg
wrote:
> Any ideas why people are getting such radically different results on
> their machines? It's hard for library writers to write any kind of
> optimized code if "optimized" on one machine means "slower" on
> another.
FWIW, I've experienced r
Any ideas why people are getting such radically different results on
their machines? It's hard for library writers to write any kind of
optimized code if "optimized" on one machine means "slower" on
another.
--
You received this message because you are subscribed to the Google
Groups "Clojure" g
On Thu, Dec 23, 2010 at 3:03 PM, Remco van 't Veer wrote:
> On my system it is about 10x faster than the code in the original
> thread. Together with the amount of time saved writing it, it's full
> seconds, maybe even minutes faster! I guess your nanoseconds and are
> not my nanoseconds.. ;)
On 2010/12/23 18:30, Ken Wesson wrote:
> On Thu, Dec 23, 2010 at 3:24 AM, Remco van 't Veer wrote:
>> Simpler and faster:
>>
>> (count (clojure.string/replace s " " ""))
>
> Simpler, yes, but not at all faster:
>
> Time (in nanoseconds): 120485.9396
>
> This is about comparable to the slow, unop
(set! *unchecked-math* true)
(defn count-num-chars ^long [^String s]
(let [l (.length s)
c \space]
(loop [i 0 acc 0]
(if (< i l)
(recur (inc i)
(if (identical? (.charAt s i) c) acc
(inc acc)))
acc
Clojure 1.3.0-master-SNAPSH
On Thu, Dec 23, 2010 at 3:24 AM, Remco van 't Veer wrote:
> Simpler and faster:
>
> (count (clojure.string/replace s " " ""))
Simpler, yes, but not at all faster:
Time (in nanoseconds): 120485.9396
This is about comparable to the slow, unoptimized loop posted at the
start of this thread. Frank
Simpler and faster:
(count (clojure.string/replace s " " ""))
On 2010/12/22 18:52, Rayne wrote:
> I have a piece of code, and I'd like to see how fast it can be.
>
> (defn count-num-chars [^String s]
> (loop [s s acc 0]
> (if (seq s)
> (recur (rest s) (if (= (first s) \space) acc
On Wed, Dec 22, 2010 at 10:19 PM, Rayne wrote:
> private static int countNumChars(String s) {
> int num = s.length();
> for (int i = 0; i < s.length(); i++) {
> if (s.charAt(i) == ' ') {
> num--;
> }
> }
> return num;
private static int countNumChars(String s) {
int num = s.length();
for (int i = 0; i < s.length(); i++) {
if (s.charAt(i) == ' ') {
num--;
}
}
return num;
}
Is one of the fastest I've seen. It runs around 4366.
Wednesday, December 22, 2010, 6:52:01 PM, you wrote:
> On my machine, your reduce example (I actually wrote that myself as my
> first try) runs marginally slower than my loop example. I don't know
> why you're getting such weird numbers. Your areduce example is worst
> of all at 74072 on my machi
On Wed, Dec 22, 2010 at 12:52 PM, Rayne wrote:
> Running it gives me around 137343.295 nanoseconds. I've seen some Java
> algorithms that could run at just under 3000 nanoseconds.
>
What do the Java implementations look like?
(defn count-num-chars [^String s]
(let [l (.length s)
c (in
On my machine, your reduce example (I actually wrote that myself as my
first try) runs marginally slower than my loop example. I don't know
why you're getting such weird numbers. Your areduce example is worst
of all at 74072 on my machine.
On Dec 22, 12:39 pm, David Powell wrote:
> Hi,
>
> > I ha
Hi,
> I have a piece of code, and I'd like to see how fast it can be.
> (defn count-num-chars [^String s]
> (loop [s s acc 0]
> (if (seq s)
> (recur (rest s) (if (= (first s) \space) acc (inc acc)))
> acc)))
I get an average of 46928 for this.
But for the straightforward opti
On Wed, Dec 22, 2010 at 1:19 PM, Rayne wrote:
> chouser wrote a solution earlier. I and a buddy modified it (a very
> little) bit and managed to get it pretty blazing:
>
> ra...@ubuntu:~$ cake run ~/challenge.clj
> Chars outputted: 460
> Time (in nanoseconds): 5768.677
>
> Here is the function:
>
Also, forgot to add an unchecked-int:
(defn count-num-chars [^String s]
(let [len (.length s)
space (int 32)]
(loop [i (int 0), c (int 0)]
(if (< i len)
(recur
(unchecked-inc i)
(if (== (int (.charAt s i)) space)
c
(unchecked-inc
I actually pasted the wrong code here:
(defn count-num-chars [^String s]
(let [len (.length s)
space (int 32)]
(loop [i (int 0), c (int 0)]
(if (< i len)
(recur
(inc i)
(if (== (int (.charAt s i)) space)
c
(unchecked-inc c)))
On Wed, Dec 22, 2010 at 1:22 PM, Ken Wesson wrote:
>
> (defn count-num-chars [^String s]
> (let [l (int (.length s))]
>(loop [i (int 0) acc (int 0)]
> (if (< i l)
>(recur (unchecked-inc i) (if (= (.charAt s i) \space) acc
> (unchecked-inc acc)))
>acc
>
> 15k nsec --
On Wed, Dec 22, 2010 at 12:52 PM, Rayne wrote:
> I have a piece of code, and I'd like to see how fast it can be.
>
> (defn count-num-chars [^String s]
> (loop [s s acc 0]
> (if (seq s)
> (recur (rest s) (if (= (first s) \space) acc (inc acc)))
> acc)))
>
> This is the fastest I've be
chouser wrote a solution earlier. I and a buddy modified it (a very
little) bit and managed to get it pretty blazing:
ra...@ubuntu:~$ cake run ~/challenge.clj
Chars outputted: 460
Time (in nanoseconds): 5768.677
Here is the function:
(defn count-num-chars [^String s]
(let [len (.length s)
Which version of Clojure are you using?
(How to speed that up depends a lot of the version you use)
I would like to see a with a longer run.
Optimised clojure is *asymptotically* nearly as fast as Java.
With under 1000 calls I am not sure the JIT is called.
Best,
Nicolas.
On Wed, Dec 22, 2010
I have a piece of code, and I'd like to see how fast it can be.
(defn count-num-chars [^String s]
(loop [s s acc 0]
(if (seq s)
(recur (rest s) (if (= (first s) \space) acc (inc acc)))
acc)))
This is the fastest I've been able to get it. The function is very
simple. It takes a s
34 matches
Mail list logo
