Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #60222 > unrolled thread

Astronomy and programming languages

Back to article view | Back to comp.lang.forth

Contents

  Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 09:09 +0000
    Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 04:38 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:45 +0000
        Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:46 -0700
        Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:49 +0000
      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:48 +0000
        Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 13:33 -0700
          Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:34 +0000
          Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:05 -0500
    Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 05:58 -0700
      Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 06:01 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:37 +0000
        Re: Astronomy and programming languages foxaudioresearch@gmail.com - 2017-06-03 07:28 -0700
          Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:31 +0000
        Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:21 -0700
          Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:01 -0700
            Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:09 -0700
            Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:20 -0700
              Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:30 -0700
              Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:43 -0700
                Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:52 +0000
              Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 19:15 -0700
                Re: Astronomy and programming languages mhx@iae.nl - 2017-06-04 00:19 -0700
              Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:39 +0000
    Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 06:57 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:48 +0000
        Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 11:12 -0700
          Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:28 -0700
            Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 06:56 -0700
            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:40 +0000
            Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:10 -0500
              Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:28 -0700
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:20 -0500
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 04:08 -0500
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 02:31 -0700
                    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 03:54 -0700
                      Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 05:00 -0700
                  Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 04:03 -0700
                    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 08:37 -0500
                    Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-09 09:27 -0700
        Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:49 -0500
          Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:11 -0500
            Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-04 17:20 -0700
              Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-07 03:10 -0500
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:41 +0000
                  Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:48 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:25 +0000
                Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-10 00:31 -0700
                  Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:18 +0000
                    Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-16 00:23 -0700
                      Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-16 07:40 +0000
                  Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:21 -0500
                    Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-14 23:36 -0700
        Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:53 -0500
    Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:04 -0700
      Re: Astronomy and programming languages rickman <gnuarm@gmail.com> - 2017-06-03 11:29 -0400
      Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:55 -0700
    Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 09:57 -0700
      Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:35 -0700
      Re: Astronomy and programming languages Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-03 19:44 +0200
    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-03 10:15 -0700
      Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:20 -0700
        Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 07:13 -0700
          Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 08:21 -0700
            Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 09:05 -0700
          Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-06 23:49 -0700
            Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 00:58 -0700
          Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-07 16:05 -0400
            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 20:26 +0000
              Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-07 14:00 -0700
                Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-07 15:46 -0700
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:06 +0000
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:24 -0700
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:27 +0000
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:08 +0000
                  Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 22:26 -0700
                    Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:29 -0700
                    Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
                      Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-08 08:02 -0700
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:26 -0700
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:30 +0000
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:17 -0500
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:37 -0700
                    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:28 -0500
                      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:33 +0000
              Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:46 +0000
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:35 +0000
                  Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-10 02:18 -0500
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 07:54 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 08:00 +0000
                      Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:38 +0000
                        Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
                          Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:03 +0000
                            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 18:17 +0000
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:23 +0000
                            Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:21 +0100
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:24 +0000
                                Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:28 +0100
                                  Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 19:04 +0000
                                    Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:13 +0100
                                      Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:22 +0100
                                        Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 03:11 +0000
                                          Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 07:38 +0000
                                            Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 08:13 +0000
                                              Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:22 +0100
                                          Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:48 +0100
                            Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 13:58 +0000
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-13 02:19 +0000
                  Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 13:16 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
              Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:38 +0000
    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-03 12:23 -0500
    Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:27 -0700
    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:46 +0000
    Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:42 -0700
      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:24 +0000
        Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 15:34 -0700
          Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:55 +0000
    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-10 10:27 -0700
    A Small Challenge (Re: Astronomy and programming languages) Joel Rees <joel.rees@gmail.com> - 2017-06-12 22:20 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Paul Rubin <no.email@nospam.invalid> - 2017-06-12 22:52 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-13 10:04 -0400
      Re: A Small Challenge (Re: Astronomy and programming languages) minforth@arcor.de - 2017-06-13 07:30 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Cecil Bayona <cbayona@cbayona.com> - 2017-06-13 10:52 -0500

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#60629

On 6/11/2017 21:13, Alex wrote:
> On 6/11/2017 20:04, Melzzzzz wrote:
>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>> On 6/11/2017 19:24, Melzzzzz wrote:
>>>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>>>> On 6/11/2017 19:03, Melzzzzz wrote:
>>>>>> Heh, non mutable data means non destructive update. That means if you
>>>>>> want to update something, you allocate new block then release old 
>>>>>> one.
>>>>>> Take for example that principle on ZFS or BTRFS. Performance is 
>>>>>> abysmal
>>>>>> for database transactions and VM images ;p
>>>>>
>>>>> No, CoW or log structured file system performance is not abysmal 
>>>>> for dbs
>>>>> or VMs. Do you have any evidence for that?
>>>>>
>>>> Just look it up. You does not have to be Einstein in order to figure
>>>> that out...
>>>>
>>>
>>> I don't think you know what you're talking about. I'm asking you to
>>> justify your assertion.
>>>
>> https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp 
>>
>>
> 
> I have been involved in a lot of benchmarking of filesystems and storage 
> arrays. This is amateur hour stuff.
> 
> One guy on the internet posts up some shit benchmark where he can't even 
> be bothered to describe the test, but he has some nice graphs and blog 
> and a theory and top output *from a completely different system*, and 
> hey presto; it gets used as justification by others, and an entire piece 
> of tech is trashed.
> 

PS, in the interests of fairness, you are about 1/4 right and 3/4s wrong 
  with your generalization.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60633

On 2017-06-11, Alex <alex@rivadpm.com> wrote:
> On 6/11/2017 21:13, Alex wrote:
>> On 6/11/2017 20:04, Melzzzzz wrote:
>>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>>> On 6/11/2017 19:24, Melzzzzz wrote:
>>>>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>>>>> On 6/11/2017 19:03, Melzzzzz wrote:
>>>>>>> Heh, non mutable data means non destructive update. That means if you
>>>>>>> want to update something, you allocate new block then release old 
>>>>>>> one.
>>>>>>> Take for example that principle on ZFS or BTRFS. Performance is 
>>>>>>> abysmal
>>>>>>> for database transactions and VM images ;p
>>>>>>
>>>>>> No, CoW or log structured file system performance is not abysmal 
>>>>>> for dbs
>>>>>> or VMs. Do you have any evidence for that?
>>>>>>
>>>>> Just look it up. You does not have to be Einstein in order to figure
>>>>> that out...
>>>>>
>>>>
>>>> I don't think you know what you're talking about. I'm asking you to
>>>> justify your assertion.
>>>>
>>> https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp 
>>>
>>>
>> 
>> I have been involved in a lot of benchmarking of filesystems and storage 
>> arrays. This is amateur hour stuff.
>> 
>> One guy on the internet posts up some shit benchmark where he can't even 
>> be bothered to describe the test, but he has some nice graphs and blog 
>> and a theory and top output *from a completely different system*, and 
>> hey presto; it gets used as justification by others, and an entire piece 
>> of tech is trashed.
>> 
>
> PS, in the interests of fairness, you are about 1/4 right and 3/4s wrong 
>   with your generalization.
>
In what way I am wrong?
You basically claim that allocating new block then releasing old one when
performing update, have same performance as updating in place?
It is *well known* fact that copy on write file systems have bad
performance regarding VM images and databases. I haven't learned that by
myself. I can't see how 'professional' benchmark can show otherwise...

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#60643

Melzzzzz <Melzzzzz@zzzzz.com> writes:
>You basically claim that allocating new block then releasing old one when
>performing update, have same performance as updating in place?

It can actually be faster, by a lot, because you can write the new
blocks contiguously.  That was the main point of
[ousterhout&douglis89] (the position paper on log-structured file
systems).  Conventional file systems added clustering to gain similar
benefits when writing new files, but random writes to existing blocks
are still slow (on rotating disks due to seeks, on SSDs due to write
amplification).

Of course database implementors knew that and designed their databases
to avoid that problem as far as possible.  That a program optimized
for direct overwriting does not necessarily also perform well on a
copy-on-write file system should be no surprise.

The funny thing is that databases also have their own
not-directly-overwriting implementation of the writes they do (e.g.,
using journaling, maybe also COW), in order to support transactions.
And on SSDs there is another COW layer in the SSD firmware, to deal
with the large block sizes on SSDs.  I wonder how a database and file
system designed for this stack (rather than each designed for a
direct-overwrite substrate) would perform, and how it would perform in
comparison to a database designed to work on raw flash.

@Article{ousterhout&douglis89,
  author =	 {John Ousterhout and Fred Douglis},
  title =	 {Beating the {I/O} Bottleneck: A Case for
                  Log-Structured File Systems},
  journal =	 {Operating Systems Review},
  year =	 {1989},
  volume =	 {23},
  number =	 {1},
  pages =	 {11--28},
  month =	 jan,
  annote =	 {Predicts that I/O (in particular, disk seeks during
                  file access) would become a bottleneck, because the
                  CPUs are becoming faster faster than disk seeks;
                  they were certainly right about the speedups, but
                  the file access bottleneck has not happened in my
                  environment yet (1999); we still have systems with
                  0.08 disks per concurrent user on a 1200~MIPS
                  machine doing software development, whereas the
                  paper predicts requiring 20--80 disks per user on a
                  500~MIPS machine. The paper discusses a number of
                  solutions for these problems: large file caches for
                  eliminating most reads (this happens on our system),
                  write-back caches with battery backup and
                  alternatively, cache logging, and log-structured
                  file systems.  The paper presents log-structured file
                  systems in some depth.}
}

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#60644

On 2017-06-12, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>>You basically claim that allocating new block then releasing old one when
>>performing update, have same performance as updating in place?
>
> It can actually be faster, by a lot, because you can write the new
> blocks contiguously.  That was the main point of
> [ousterhout&douglis89] (the position paper on log-structured file
> systems).  Conventional file systems added clustering to gain similar
> benefits when writing new files, but random writes to existing blocks
> are still slow (on rotating disks due to seeks, on SSDs due to write
> amplification).
>
> Of course database implementors knew that and designed their databases
> to avoid that problem as far as possible.  That a program optimized
> for direct overwriting does not necessarily also perform well on a
> copy-on-write file system should be no surprise.
>
> The funny thing is that databases also have their own
> not-directly-overwriting implementation of the writes they do (e.g.,
> using journaling, maybe also COW), in order to support transactions.
> And on SSDs there is another COW layer in the SSD firmware, to deal
> with the large block sizes on SSDs.  I wonder how a database and file
> system designed for this stack (rather than each designed for a
> direct-overwrite substrate) would perform, and how it would perform in
> comparison to a database designed to work on raw flash.

Heh, I just tried zfs vs ext4 sysbench oltp mariaDB benchmark and in my
surprise on rusty hdd zfs is about 4 time faster on updates ;)
Haven't tried on SSD, but I guess there would be no difference ;)

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#60648

On 6/12/2017 09:13, Melzzzzz wrote:
> On 2017-06-12, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>>> You basically claim that allocating new block then releasing old one when
>>> performing update, have same performance as updating in place?
>>
>> It can actually be faster, by a lot, because you can write the new
>> blocks contiguously.  That was the main point of
>> [ousterhout&douglis89] (the position paper on log-structured file
>> systems).  Conventional file systems added clustering to gain similar
>> benefits when writing new files, but random writes to existing blocks
>> are still slow (on rotating disks due to seeks, on SSDs due to write
>> amplification).
>>
>> Of course database implementors knew that and designed their databases
>> to avoid that problem as far as possible.  That a program optimized
>> for direct overwriting does not necessarily also perform well on a
>> copy-on-write file system should be no surprise.
>>
>> The funny thing is that databases also have their own
>> not-directly-overwriting implementation of the writes they do (e.g.,
>> using journaling, maybe also COW), in order to support transactions.
>> And on SSDs there is another COW layer in the SSD firmware, to deal
>> with the large block sizes on SSDs.  I wonder how a database and file
>> system designed for this stack (rather than each designed for a
>> direct-overwrite substrate) would perform, and how it would perform in
>> comparison to a database designed to work on raw flash.
> 
> Heh, I just tried zfs vs ext4 sysbench oltp mariaDB benchmark and in my
> surprise on rusty hdd zfs is about 4 time faster on updates ;)
> Haven't tried on SSD, but I guess there would be no difference ;)
> 

There we go; we've all learned something. It does bear repeating; 
nothing beats evidence.

My apologies for coming on here perhaps a little too strongly in earlier 
posts.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60649

On 6/12/2017 04:11, Melzzzzz wrote:
> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>> On 6/11/2017 21:13, Alex wrote:
>>> On 6/11/2017 20:04, Melzzzzz wrote:
>>>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>>>> On 6/11/2017 19:24, Melzzzzz wrote:
>>>>>> On 2017-06-11, Alex <alex@rivadpm.com> wrote:
>>>>>>> On 6/11/2017 19:03, Melzzzzz wrote:
>>>>>>>> Heh, non mutable data means non destructive update. That means if you
>>>>>>>> want to update something, you allocate new block then release old
>>>>>>>> one.
>>>>>>>> Take for example that principle on ZFS or BTRFS. Performance is
>>>>>>>> abysmal
>>>>>>>> for database transactions and VM images ;p
>>>>>>>
>>>>>>> No, CoW or log structured file system performance is not abysmal
>>>>>>> for dbs
>>>>>>> or VMs. Do you have any evidence for that?
>>>>>>>
>>>>>> Just look it up. You does not have to be Einstein in order to figure
>>>>>> that out...
>>>>>>
>>>>>
>>>>> I don't think you know what you're talking about. I'm asking you to
>>>>> justify your assertion.
>>>>>
>>>> https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp
>>>>
>>>>
>>>
>>> I have been involved in a lot of benchmarking of filesystems and storage
>>> arrays. This is amateur hour stuff.
>>>
>>> One guy on the internet posts up some shit benchmark where he can't even
>>> be bothered to describe the test, but he has some nice graphs and blog
>>> and a theory and top output *from a completely different system*, and
>>> hey presto; it gets used as justification by others, and an entire piece
>>> of tech is trashed.
>>>
>>
>> PS, in the interests of fairness, you are about 1/4 right and 3/4s wrong
>>    with your generalization.
>>
> In what way I am wrong?
> You basically claim that allocating new block then releasing old one when
> performing update, have same performance as updating in place?
> It is *well known* fact that copy on write file systems have bad
> performance regarding VM images and databases. I haven't learned that by
> myself. I can't see how 'professional' benchmark can show otherwise...
> 

The bit where you're (almost) right is in reference to btrfs. Its design 
criteria did not appear to specifically include good performance for 
random I/O; it focussed on reliability, fault tolerance and easy admin. 
I would agree that it is (from my perspective as someone who follows 
theses things) still a little immature 
https://btrfs.wiki.kernel.org/index.php/Gotchas.

ZFS is a completely different filesystem design from btrfs. There are 
benchmarks of this and other CoW/logstruct file systems at SPC 
(http://www.storageperformance.org/home/). Some CoW/logstruct file 
systems also support traditional block access over iSCSI or fibre 
channel; notably NetApp systems (disclosure: that's where I work).

These systems regularly beat equivalent traditional systems in both 
random and sequential I/O performance. So allocating a new block then 
releasing old one when performing updates can have far superior 
performance to updating in place (and that's true of both traditional 
spinning disk and SSD).

The link you pointed to shows why amateur benchmarking can go horribly 
wrong; first, it fails to even document what hardware was used, and what 
OS, what mount options, and so on. Second, it appears (but I can't tell 
exactly, since there's so little detail) that perhaps the "ssd" option 
was selected for the test. That is just going to ruin the performance 
straight out of the box. It is, to be frank, little more than a hatchet 
job, and if I was a btrfs developer, I'd be seriously annoyed.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60658

Melzzzzz <Melzzzzz@zzzzz.com> writes:
>That also means that array update is O(n) and arrays are naturaly not
>prefered data structure in such langauges, rather linked lists.

For a random-access data structure where you want to simulate a
single-element update, the preferred data structure is a tree;
accesses and simulated updates have O(ln n) complexity.

However, in general you will tend to write the code in such languages
in a way that avoids the need for updates.  And maybe avoid writing
software that really needs updates (or encapsulate the updates in
monads).

>I understand that threading is much simpler if
>there is no shared data

That's the propaganda, and I have read it many years ago, and then
heard a talk (at IIRC CC'92 or CC'94) about the problems of
parallelizing the implementation of a lazy functional language (not
sure if it was Haskell or one of its precursors).  The problem was
that you want to evaluate each call only once, meaning that each call
is a potential synchronization point.

They may have solved this problem in the meantime, and eager
functional languages don't have this particular problem anyway, but it
shows that just because at the high level there appears to be easy
parallelism, the devil of making use of it is in the details.

 And other than the high-level claims that I had heard already 25
years ago, and the stuff about Erlang (which has programmer-visible
threads AFAIK), I have not come across any success stories about
auto-parallelization of functional languages.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#60674

On 2017-06-12, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>>That also means that array update is O(n) and arrays are naturaly not
>>prefered data structure in such langauges, rather linked lists.
>
> For a random-access data structure where you want to simulate a
> single-element update, the preferred data structure is a tree;
> accesses and simulated updates have O(ln n) complexity.

Yep. But I haven't seen trees, rather lists. eg Haskell, Idris, Clean.
Trees are like library implemented while lists are built into language.
Implementing balanced tree in Haskell is a breeze ;)

>
> However, in general you will tend to write the code in such languages
> in a way that avoids the need for updates.  And maybe avoid writing
> software that really needs updates (or encapsulate the updates in
> monads).

That's right. Haskell has mutable arrays and IORef, alright, though. 

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#60555

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>Anton Ertl wrote:
>
>> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>> > "It is practically impossible to teach good programming style to 
>> > students that have had prior exposure to Basic; as potential 
>> > programmers they are mentally mutilated beyond hope of 
>> > regeneration." -- Edsger Dijkstra
>> 
>> Dijkstra did some cool stuff and also wrote some nonsense.
>> Unfortunately, his nonsense is quoted much more often than his cool
>> stuff.
>
>So, do you condider this "nonsense" or "good stuff"?

Nonsense.  Do you really need to ask?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#60618

Anton Ertl wrote:

> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
> > Anton Ertl wrote:
> > 
> >> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
> >> > "It is practically impossible to teach good programming style to 
> >> > students that have had prior exposure to Basic; as potential 
> >> > programmers they are mentally mutilated beyond hope of 
> >> > regeneration." -- Edsger Dijkstra
> >> 
> >> Dijkstra did some cool stuff and also wrote some nonsense.
> >> Unfortunately, his nonsense is quoted much more often than his cool
> >> stuff.
> > 
> > So, do you condider this "nonsense" or "good stuff"?
> 
> Nonsense.  Do you really need to ask?

I just wanted to be sure I understood you correctly.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"It was the experience of mystery -- even if mixed with fear -- 
 that engendered religion."
 -- Albert Einstein (1879-1955)

[toc] | [prev] | [next] | [standalone]

#60467

On Wed, 7 Jun 2017 20:26:32 +0000 (UTC)
"Rudy Velthuis" <newsgroups@rvelthuis.de> wrote:

> "It is practically impossible to teach good programming style to 
>  students that have had prior exposure to Basic; as potential 
>  programmers they are mentally mutilated beyond hope of 
>  regeneration." -- Edsger Dijkstra
> 

That's not true.  I used Dijkstra's structured programming concepts
with BASIC.  It was what kept my code from becoming spaghetti code.  Of
course, that can't be said of other BASIC programmers ...  I saw
another programmers' BASIC code turn into spaghetti code.


Rod Pemberton
-- 
The Paris Agreement is irrelevant. A carbon tax is futile. The only
solution is technology. Please tell Elon Musk that he is not being a
technology visionary.

[toc] | [prev] | [next] | [standalone]

#60517

Rod Pemberton wrote:

> On Wed, 7 Jun 2017 20:26:32 +0000 (UTC)
> "Rudy Velthuis" <newsgroups@rvelthuis.de> wrote:
> 
> > "It is practically impossible to teach good programming style to 
> >  students that have had prior exposure to Basic; as potential 
> >  programmers they are mentally mutilated beyond hope of 
> >  regeneration." -- Edsger Dijkstra
> 
> That's not true.  I used Dijkstra's structured programming concepts
> with BASIC.  It was what kept my code from becoming spaghetti code.

Hey, he said it, not me. I guess if he could read what you did, he
would rotate in his grave. ;-)

While I personally started with ZXBASIC, BBC Basic and have used Visual
Basic and VB.NET, I don't think it mentally mutilated me beyond hope of
regeneration. <g>

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I was raised in the Jewish tradition, taught never to marry a
 Gentile woman, shave on a Saturday night and, most especially, 
 never to shave a Gentile woman on a Saturday night." 
 -- Woody Allen.

[toc] | [prev] | [next] | [standalone]

#60241

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> So, while the positions that are often called the Forth philosophy
> have their virtues in some contexts, they are probably a major
> contributor for Forth's decline in astronomy.

Possibly so, yes.

> Some want to make us believe that the reason for the lack of
> popularity of Forth is the lack of a marketing campaign by a big
> corporation, but if that was the case, astronomers would be
> programming in PL/I, not Python.  Also, it's pretty hard to wean
> programmers off their favourite language, and network effects make it
> easy for a language to stay in a field where it is strong.  Forth
> obviously dropped the ball in astronomy.

There's nothing obvious about that.  It's equally likely IMO that the
needs of the practitioners changed.

> Anyway, my conclusions: The positions that are usually presented as
> Forth philosophy are not beneficial in every case, so we should not
> treat them as absolutes. 

We perhaps shouldn't treat anything as an absolute.  However, while
Python is deservably one of the most successful scripting languages
and deserves to be it doesn't follow that because Feature X works well
for Python it would work for Forth.

> And some of the things that are often maligned here, in particular,
> libraries, are actually helpful in many cases.

An appropriate library is always helpful.

Andrew.

[toc] | [prev] | [next] | [standalone]

#60242

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The interesting thing for Forthers context is that Forth used to be
> very strong in astronomy.  

AAUI Forth was strong at spacecraft and telescope control, i.e.  low
level hardware control tasks for which Forth is still strong today.  The
Python program mentioned was being used for data analysis which I don't
think was ever a Forth strong spot.  


> * [Python] works nicely with other languages such as C and Fortran,
>   rather than doing everything yourself because you can do it better.

The CPython C API is actually rather a pain, though you can use it if
you have to.  Libraries like numpy/scipy do that (a lot of work goes
into them) but if I want to mix C and Python, I usually do it as
separate programs, i.e. a Python script as a control wrapper, that
launches C programs as it goes along.

[toc] | [prev] | [next] | [standalone]

#60246

Anton Ertl wrote:

> * it has a "battries included" philopsophy of providing all sorts of
>   extras rather than minimalism that worries about kilobytes on a
>   gigabyte machine.

Exactly. Sure, one can overdo it in the other direction as well, but
worrying about every byte or nano-second is seldom necessary.
 
> * there is a huge number of third-party libraries that can be and are
>   used, even though they are 'full of inefficient code to take care of
>   all possible cases, etc.'

I know that is the philosophy of some here, but ISTM that it is
completely wrong. A good library is not like that at all. A well
written library that is used by many will get better because of
feedback from those who use it.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"This isn't life in the fast lane, it's life in the oncoming traffic."
 -- Terry Pratchett

[toc] | [prev] | [next] | [standalone]

#60253

Wisdom from this thread:

- some say Forth is unpopular because it isn't being marketed. That's
  wrong because Python is popular.

- Forth doesn't have the popularity it had in telescope-control days
  because, like, some Forths are 64-bit and some are 32-bit and woah
  not all ANS code is immediately portable like it was back in
  telescope-control days. No popular language has problems like this.

- Forth's advantages don't matter unless you're programming a
  toaster, lol.

- Forth is hard. The Mohs test has it scratching most other languages!
  Can't be helped that Forth is unpopular when only 0.013% of humanity
  is capable of contemplating it without a debilitating seizure.

- people on clf are small-minded bigots who hate libraries just
  because of the color of their code. A language with this community
  is doomed to unpopularity.

Since this is comp.lang.forth.popularity I'll add to the stew:

- the most important part of a 500-piece puzzle is the cover on the
  box that tells you what the goal looks like. Forth is different enough
  that even bright people who are productive in other languages can
  get lost and not know how to get things done with it. The good and
  up-to-date documentation that Forth has however is fairly at the
  level of a glossary, documenting what each piece of the 500-piece
  puzzle looks like. That documentation isn't bad - it's all a Forth
  programmer needs - but it's not sufficient for people we would like
  to be Forth programmers.

- there's a tremendous amount of (very easy, a lot less impressive
  than you'd think) work gone into libraries for other languages that
  allow people to get a lot done, very quickly, without knowing what
  they're doing. Really you might think of these as consumer-level
  applications, but intended for programmers, rather than as
  libraries. Forth could use more of those.

- people will say "oh man, I need to learn <language> right away, so
  that I can use it with <amazing application>!" Forth could use any
   of those.

Rather: you are all staring at the base of the pitcher plant wondering
what's fundamentally wrong with it, that it can't attract flies
eat. You should be looking at the mouth of the plant. If you stared at
Python this way you'd find so many more serious faults that you could
hardly believe anyone uses it for any purpose -- but they don't mind
the faults, or discuss them as mere warts, because they're looking at
the plant from the inside. With the digestive fluids, I mean.

[toc] | [prev] | [next] | [standalone]

#60258

Julian Fondren wrote:

> Wisdom from this thread:
> 
> - some say Forth is unpopular because it isn't being marketed. That's
>   wrong because Python is popular.
> 
> - Forth doesn't have the popularity it had in telescope-control days
>   because, like, some Forths are 64-bit and some are 32-bit and woah
>   not all ANS code is immediately portable like it was back in
>   telescope-control days. No popular language has problems like this.

Python, at least, doesn't have them. Nor do some other popular
languages.


-- 
Rudy Velthuis        http://www.rvelthuis.de

Glyme's Formula For Success: The secret of success is sincerity. 
Once you can fake that, you've got it made.

[toc] | [prev] | [next] | [standalone]

#60259

On Saturday, June 3, 2017 at 5:24:33 PM UTC-5, Rudy Velthuis wrote:
> Julian Fondren wrote:
> 
> > Wisdom from this thread:
> > 
> > - some say Forth is unpopular because it isn't being marketed. That's
> >   wrong because Python is popular.
> > 
> > - Forth doesn't have the popularity it had in telescope-control days
> >   because, like, some Forths are 64-bit and some are 32-bit and woah
> >   not all ANS code is immediately portable like it was back in
> >   telescope-control days. No popular language has problems like this.
> 
> Python, at least, doesn't have them.

https://wiki.gentoo.org/wiki/Project:Python/Implementations
https://github.com/dropbox/pyston/wiki/FAQ

> Nor do some other popular
> languages.

'some' don't? OK. Do any popular languages have this problem?
If the answer is "yes--obviously", it might not be the silver bullet.

[toc] | [prev] | [next] | [standalone]

#60261

Julian Fondren wrote:

> On Saturday, June 3, 2017 at 5:24:33 PM UTC-5, Rudy Velthuis wrote:
> > Julian Fondren wrote:
> > 
> > > Wisdom from this thread:
> > > 
> > > - some say Forth is unpopular because it isn't being marketed.
> > > That's   wrong because Python is popular.
> > > 
> > > - Forth doesn't have the popularity it had in telescope-control
> > > days   because, like, some Forths are 64-bit and some are 32-bit
> > > and woah   not all ANS code is immediately portable like it was
> > > back in   telescope-control days. No popular language has
> > > problems like this.
> > 
> > Python, at least, doesn't have them.
> 
> https://wiki.gentoo.org/wiki/Project:Python/Implementations

I'm not sure what you are trying to tell me with that.

> https://github.com/dropbox/pyston/wiki/FAQ

Nor with that.
 
> > Nor do some other popular languages.
> 
> 'some' don't? OK. Do any popular languages have this problem?

All kinds of popular languages have all kinds of problems. For some,
that includes (lack of) portability.

But ISTM that mainly Forth's syntax prevents it from becoming popular.
For someone not used to it, it is hard to read, unlike, say, Python's.

(note that I don't like Python very much, but it is obviously pretty
popular, these days).
-- 
Rudy Velthuis        http://www.rvelthuis.de

"It was God who made me so beautiful. If I weren't, then I'd be
 a teacher." -- Linda Evangelista.

[toc] | [prev] | [next] | [standalone]

#60571

in a rabbit-semi group someone asked how to implement the following
Arduino code for a rabbit board:

int dirPin = 8;
int stepperPin = 7;
void setup() {
 pinMode(dirPin, OUTPUT);
 pinMode(stepperPin, OUTPUT);
}
 void step(boolean dir,int steps){
 digitalWrite(dirPin,dir);
 delay(50);
 for(int i=0;i<steps;i++){
   digitalWrite(stepperPin, HIGH);
   delayMicroseconds(800);
   digitalWrite(stepperPin, LOW);
   delayMicroseconds(800);
 }
}
void loop(){
 step(true,1600);
 delay(500);
 step(false,1600*5);
 delay(500);
}

This would be a forth equivalent that I would provide in my scripting
forth limbo:

8 const dirPin
7 const stepperPin
: setup
  OUTPUT dirPin pinMode
  OUTPUT stepperPin pinMode
;
: steps ( dir steps -- )
  dir dirPin digitalWrite
  50 delay
  steps for
    HIGH stepperPin digitalWrite
    800 delayMicroseconds
    LOW stepperPin digitalWrite
    800 delayMicroseconds
  next
;
: loop
  true 1600 steps
  500 delay
  false 1600 5 * steps
  500 delay
;

Please note the absence of any DUP DROP etc.
To me, the forth code is *at least* as readable as the
arduino (well... C) counterpart. Even more lite, without
all the parathesis and semicolons.

I renamed 'step' as 'steps'. This is a nice trick when 
coming to forth...

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.forth

csiph-web